When people talk about continuous improvement, we almost always imagine big projects: redesigning an entire process, buying new technology, or restructuring a department. But the Kaizen philosophy stems from a different idea—one that is almost uncomfortably simple: the most sustainable improvement almost never comes from a massive change, but rather from many small, continuous adjustments made by the people who execute the process every single day.

The word Kaizen, coming from Japanese, literally means “change for the better.” Yet its true value isn’t philosophical; it’s practical: it shifts who has the right to suggest an improvement. In many organizations, process improvement is “the job of the engineers” or “the quality department.” Kaizen flips that logic on its head: the person who best understands the real problems of a task is the one doing it every day, not the one auditing it once a month.

I have seen this up close: the difference between an operator who reports a problem and waits for someone else to fix it, versus an operator who proposes (and tests) a simple tweak because they feel empowered to do so. That second scenario doesn’t just happen on its own. It requires the organization to genuinely listen to small suggestions, not just major initiatives with allocated budgets.

There are three key Kaizen principles that I find particularly applicable to any team, regardless of the industry:

1. Small doesn’t mean insignificant. Eliminating an unnecessary step in a repetitive task might seem trivial, but if that task is performed 50 times a day, the cumulative savings easily outperform much more high-profile projects.
2. Change is tested by those who live it. An improvement imposed from above, without validation from the person executing the process, runs a much higher risk of failing over time than one proposed and tested by the team itself.
3. Continuous improvement is a habit, not an event. It’s not a once-a-year brainstorming workshop; it’s about making the question “Can this be done a little better?” a natural part of the daily work routine.

The curious thing is that these ideas sound simple—almost like common sense—and yet they are among the hardest to truly embed into a company culture. It is far easier to purchase a new tool or methodology than it is to build an environment where an entire team feels confident (and has the time) to suggest small improvements on a ongoing basis.

Does your organization make real room for this kind of progress, or is continuous improvement still confined to large-scale projects?

-Javier Rodríguez

When an editor hits publish, from where they sit, just one thing happened. However underneath it’s seven or eight, and at least two can’t be taken back.

On a mature platform: purge the CDN, reindex search, fire a partner webhook, notify subscribers, push to social accounts, update a partner feed, emit an analytics event.

In Drupal a competent team can easily grep the hooks and event subscribers, read the ECA models etc, and have an inventory in a week as a wiki page. What an agent needs though is a declared catalogue: operations with typed inputs, known authorization, and a receipt on the way out.

As Scott Falconer puts it in the Outside AI roadmap: what’s missing is declaration, not governance. The permission system already works; authorization attaches to the operation, not the entry point. Operations beyond entity CRUD aren’t declared anywhere an agent can find them. For authorization that’s right but knowing an agent may run an operation doesn’t tell you which runs a human should look at.

Meta’s Agents Rule of Two, after Simon Willison‘s lethal trifecta says that an agent holding untrusted input, private data and the ability to change state within a session shouldn’t run autonomously. It needs human approval or another reliable means of validation. Because agents produce thousands of changes where a team produced a handful you need a second axis, not a substitute. The trifecta says which agents need supervision, something else has to say which of their calls do. Reversibility is the obvious candidate, however it’s not a clean yes or no. A reindex is re-runnable, yet while the rebuild happens the wrong results are served. The undo exists but the damage happened anyway. A usable class needs a mechanism, a window and the residue.

So placement is the real issue. Reversibility appears in the roadmap (stage four, where revisions make a change reversible), but that’s verification, after the fact. A gate needs it before, at dispatch. And it can’t be a static label, because deleting a node with revision retention on is a different class of action than the same call with it off. It depends on runtime config and the arguments of the call, which is why it isn’t a permission, and why declaring it is harder than declaring types.

Which also means the catalogue can’t enforce it. A field the agent reads is documentation, not a gate, and under injection the agent is the last actor you’d ask whether it should proceed. The check has to fire where entity access already fires — in the layer that runs the operation, evaluated against the arguments actually passed.

So a question for anyone working on this. If reversibility class belongs anywhere, does it belong in the Tool API declaration alongside typed inputs and authorization or somewhere else entirely?

Sources and further reading, for anyone who wants to dig in or get involved:

• Scott Falconer, “Outside AI — The State of Agent Experience in Drupal” https://www.drupal.org/about/ai/initiatives/blog/outside-ai-the-state-of-agent-experience-in-drupal
• Simon Willison on the lethal trifecta: https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/
• Meta’s Agents Rule of Two: https://ai.meta.com/blog/practical-ai-agent-security/
• If you’re actually running agents against Drupal, the Outside AI workstream has asked for real workflows, see the meta issue or the #ai-initiative channel in Drupal Slack.

-M. García

It is a common misconception that the QA role is limited to “finding bugs at the end of development.” After three years of experience across different areas of Quality Engineering, I have proven that our work is actually the common thread ensuring a project’s success from inception to launch.

Throughout my career, I have experienced validation from three distinct perspectives, each teaching me why testing is non-negotiable:

1. The Power of Consistency and Maintenance

During my time working with major clients like SEAT, I learned that in highly organized environments, the real challenge isn’t just creating tests—it’s keeping them alive.

• The Takeaway: An outdated test is just as dangerous as no test at all. Ensuring existing tests remain functional while designing new ones for upcoming features is what allows a product to scale securely without breaking what already works.

2. From Paper to Prototype: Alignment and System Testing

When I shifted my focus to System Testing, the game changed. This is where I learned the critical importance of “Phase Zero”: receiving a prototype, analyzing specifications, and, most crucially, ensuring that we and the client are 100% aligned before production begins.

• The Takeaway: Physical testing demands precision and versatility. I moved into manual and industrial validation, operating equipment such as dataloggers, thermal cameras, centrifugal pumps, and climate chambers/ovens. Furthermore, I realized the immense value of automation by programming and controlling systems to execute long-duration or fatigue tests that would be impossible to perform manually.

3. Versatility in Software Validation

In my most recent role, focusing on the company’s proprietary software product, I have seen how validation must be fluid and adapt to the context.

• The Takeaway: Tackling a greenfield product from scratch is entirely different from validating an upgraded version with new features, or running regression tests to ensure recent changes haven’t disrupted the system’s core. A QA’s adaptability directly dictates how agilely a company can ship improvements to the market.

In conclusion: Testing is not a bottleneck; it is a confidence accelerator. It ensures that what the client envisioned is what gets built, that what is built withstands the real world, and that the software controlling it evolves without a hitch.

–JM. Flores

Until now, AI-driven automation has focused on creating specialized “assistants”: a chatbot for customer service, a model that generates reports, another one that classifies data. But what if, instead of a single assistant, you could orchestrate an entire team of AI specialists that assign work among themselves, collaborate, and make sequential decisions without human intervention? This is no longer science fiction: it’s called Agentic AI, and it’s redefining what an automated process truly means.

---

1. The Conceptual Leap: From Tool to Agent

The key lies in agency. An AI agent doesn’t just execute an instruction—it perceives its environment (data, outputs from other agents, triggers), defines a goal, and takes actions to achieve it.

Think of the difference between a grammar-checking tool and a professional editor who decides to rewrite a paragraph for greater impact. That’s the shift from tool to agent.

---

2. The Power Is in the Orchestration: A Multi-Agent Flow in Action

This emerges when several agents, each with a specific role, work together. Here’s a concrete example of what could be implemented in process automation:

• Agent 1 (Researcher): Monitors news sources and market alerts. Detects a headline relevant to a client.
• Agent 2 (Analyst): Takes that headline, cross-references internal client data, and generates a brief impact assessment.
• Agent 3 (Strategist): Based on that assessment, decides on the best action: prepare a tailored proposal? Alert an executive? Choose the right path.
• Agent 4 (Executor): Carries out the action: drafts a personalized email, schedules a notification, or creates a task for a human.

This workflow—which once took hours or days of back‑and‑forth—now executes autonomously in minutes, 24/7, thanks to agent orchestration.

---

3. Why This Excites Us: Key Benefits

• Complex Problem Solving: Breaks down solutions into manageable steps, mirroring team-based reasoning.
• Fault Tolerance and Adaptability: If one agent fails to reach a goal, the flow can reroute, request help, or ask for additional data (from another agent or a human).
• Next-Level Efficiency: It doesn’t automate isolated tasks—it automates full cognitive processes. This frees human talent for oversight, creativity, and exception handling.

---

4. How to Start Exploring (Without the Hype Trap)

Building these flows requires a mindset shift. Based on our learning so far, a good starting point is:

• Map an existing process clearly, identifying decisions and branching paths.
• Define clear “roles”: What will each agent do? Specialization is essential.
• Establish a communication protocol: How will data and information be exchanged? (APIs, structured messages, specific formats, etc.)
• Keep humans in the loop: Design checkpoints and supervision moments. Human judgment should remain the ultimate authority.

Agentic AI is not about replacing jobs—it’s about amplifying organizational capabilities so they become more proactive, resilient, and intelligent. We are moving from being tool users to becoming architects of autonomous digital ecosystems.

---

Let me ask you:

• What process in your area do you think would benefit from having an “AI team” working in the background?
• Have you explored tools like Autogen, CrewAI, or any other agent orchestrators using LLMs?

I’d love to read your insights and experiences in the comments.

---

Ricardo F.
Passionate about the practical application of AI to transform business processes. Currently exploring the potential of multi‑agent workflows as QA Automation at Oxigent Technologies.

While working as a CE with a system based on an Event‑Driven Architecture (EDA) pattern, I wanted to evaluate the possibility of using this architecture in more everyday tasks. For this case, I chose a control and attendance system that could be used during dog‑walking days organized by an animal shelter located in San Antonio de Benagéber, Valencia, Spain.

The main idea is to assist in coordinating the walks so that volunteers always know—visually and intuitively—which dogs have gone out, which dogs are currently walking, and any other necessary information to ensure the day runs smoothly.

Basically, the system consists of an entry point that triggers an event. The system then analyzes whether it is an entry or exit event and displays it on a dashboard. Later on, we will go deeper and—if possible—make it more complex. For example, adding the ability to obtain metrics about the walking days and the dogs, or adding warning indicators in case two reactive dogs might go out at the same time.

---

Solution Architecture (General Overview)

Ingestion (Producers):

A single API receives all events (QR, NFC, AI).

Routing (Event Bus):

An event bus classifies and distributes the events.

Logic (Consumers):

A “brain” function processes “Entry” and “Exit” events.

State (Database):

A database stores the current state (INSIDE/OUTSIDE) and timestamps.

Visualization (Dashboard):

The dashboard updates in real time.

---

1. Ingestion: Amazon API Gateway

To prevent the mobile app (used for QR/NFC) or the AI model from connecting directly to the logic layer, I use a single, secure, and scalable entry point.

• Service: Amazon API Gateway
• How it works:
  A REST API is created (e.g., POST /events).
  All devices send a simple JSON payload to this endpoint.

---

2. Routing: Amazon EventBridge

API Gateway performs no computation. Its only task is to pass the event on to the central event bus.

• Service: Amazon EventBridge
• How it works:
  API Gateway places the event into EventBridge.
  EventBridge evaluates the event and decides where to send it based on Rules.

---

3. Logic and State: AWS Lambda + Amazon DynamoDB

This is where the magic happens. EventBridge forwards all events to a “brain” function that maintains the dogs’ state.

• Services: AWS Lambda and Amazon DynamoDB
• Database (DynamoDB):
  A table called EstadoPerros is created.
• Function (Lambda):
  A Lambda function called ProcesarMovimientoPerro is created.
  EventBridge triggers it every time an event arrives.

Lambda Logic:

• IF the event action is "SALIDA" (Exit):
  Process the dog as “going out.”
• IF the event action is "ENTRADA" (Entry):
  Process the dog as “coming back.”

---

4. Visualization: Real‑Time Dashboard

The dashboard must receive changes instantly, without a page refresh.

• Services: AWS AppSync or AWS IoT Core (WebSockets)
• How it works (with AppSync):
  1. EventBridge has a second rule:
     “If an event contains nuevo_estado…”
  2. The target of this rule is AppSync.
  3. The dashboard uses the AppSync client library to subscribe to updates.
  4. When AppSync receives an event like:
     {"id_perro": "p-001", "nuevo_estado": "FUERA"}
     it sends it via WebSocket to all connected dashboards.
  5. The dashboard updates the icon for p-001 to “OUTSIDE” in real time.

---

5. Total Time Calculation

To track information for the day:

• tiempo_paseo_total_hoy is already being calculated and stored in DynamoDB each time a dog returns from a walk.
• When the dashboard loads for the first time, it simply queries DynamoDB (via API Gateway) to retrieve the current state and total time for all dogs.

---

Additional Task: Daily Reset

I need a way to reset the tiempo_paseo_total_hoy counter to 0 every day.

• Service: Amazon EventBridge Scheduler
• How it works:
  A scheduled rule (“cron job”) is created to run every day at midnight.
  The target is a new Lambda function (ResetContadoresDiarios) that scans the DynamoDB table and sets tiempo_paseo_total_hoy = 0 for all dogs.

---

Implementation Notes

Whenever possible, I will use IaC (Terraform) for implementation and commit the code to my GitHub account.

---

Thanks to Oxigent Technologies for providing the resources for this POC.
Thanks for reading this far, and I welcome all suggestions!

Martin P.