Concurrent AI Agents: The Antidote to the Agentic Waterfall Anti-Pattern
Agentic Waterfall Anti-Pattern: AI Systems Inherit the Way We Learned to Work
Software systems do not emerge in isolation. They reflect the way their creators understand work.
For decades, organizations were built around sequential coordination. One person completed a task and handed the result to the next person. Managers divided complex work into stages, assigned responsibility for each stage, and waited for every dependency to be resolved before the process could continue.
The waterfall model was not merely a software development methodology. It reflected a broader way of thinking about productivity: define the plan, divide the work, complete each stage, and move forward through a predictable sequence.
Even after software teams adopted agile methods, many of these assumptions remained. Work was still represented as tickets moving through columns, tasks waiting for approval, and people being blocked by dependencies outside their control.
We are now reproducing the same model in AI systems.
The Agentic Waterfall Anti-Pattern
Today’s multi-agent systems are sequential by nature. One agent waits for another before it can start. Even when several agents run in parallel, the workflow remains blocked until they all finish and their results are merged.
This is the Agentic Waterfall anti-pattern: agents are placed inside a hardcoded sequence of dependencies and handoffs.
A researcher produces a result before a writer can begin. The writer finishes before a reviewer can inspect the output. The reviewer returns feedback, and the entire chain starts moving again.
The implementation may contain multiple agents, but operationally, it behaves like a traditional workflow engine.
Even graph-based systems frequently reproduce the same limitation. Several branches may execute simultaneously, but the workflow eventually reaches a join where every branch must finish before anything else can happen.
Parallel execution is not necessarily concurrency.
The system may run several operations at once, but its participants are still coordinated through blocking dependencies defined in advance.
The Operational Layer Reveals the Bottlenecks
At the diagram level, an agentic workflow can look sophisticated. It may contain routers, planners, specialists, evaluators, retry loops, and parallel branches.
The limitations become visible at the operational layer.
What happens when one agent discovers something that another agent should know immediately?
What happens when an external event changes the situation while the workflow is still running?
What happens when one branch finishes early and could continue producing value without waiting for the rest of the system?
What happens when a new agent needs to join a process that has already started?
In sequential architectures, these situations usually require another edge, callback, condition, polling mechanism, or orchestration rule. Every new interaction increases the number of dependencies the developer must predict and encode.
The workflow becomes increasingly difficult to extend because collaboration is represented as a predefined sequence rather than something that can emerge dynamically during execution.
This wastes execution time and tokens, makes systems difficult to extend, and leaves them poorly equipped to recover when something unexpected happens outside the happy path.
The deeper problem is not that the workflow was designed incorrectly. The problem is that the workflow itself is responsible for coordinating every participant.
Agents Should Not Be Digital Assembly-Line Workers
AI agents are often described as autonomous, but autonomy is limited when every action depends on permission from a central workflow.
An agent that can reason independently but must wait for the previous node to finish is not operationally autonomous. It is an intelligent worker standing on a digital assembly line.
Human organizations experience the same problem.
A capable person becomes ineffective when every decision requires approval, every task depends on a handoff, and every unexpected situation must be escalated through a fixed hierarchy.
Personal development often means learning to operate with greater agency: recognizing what can be done independently, communicating relevant information early, responding to changing circumstances, and waiting only when waiting is genuinely necessary.
Multi-agent systems need to make the same transition.
Instead of asking only:
What step comes next?
We should also ask:
What can each participant do now, based on what it currently knows?
That change in perspective moves us from workflow execution toward an environment in which agents can perceive events, make decisions, communicate, and act independently.
Non-Blocking Agents Are the Prerequisite
Escaping the Agentic Waterfall anti-pattern requires more than adding parallel branches to an existing graph.
The prerequisite is non-blocking agents.
A non-blocking agent should be able to continue operating without waiting for the entire system to reach a synchronization point. It should react to relevant events as they occur, publish information that may be useful to others, and pause only when it genuinely depends on unavailable information.
This also requires frameworks that introduce techniques for working with concurrent AI agents.
Developers need ways to model:
- independent agent execution,
- event-driven communication,
- selective synchronization,
- dynamic participation,
- shared and private context,
- coordination without central orchestration,
- and recovery when the environment changes unexpectedly.
Without these capabilities, developers are forced back into hardcoded workflows, regardless of how intelligent the individual agents may be.
Building Mozaik
We are building Mozaik, a TypeScript runtime for concurrent AI agents.
Its event-driven architecture allows agents to work independently without blocking the entire system—similar to an operating system running many programs at once.
An operating system does not define one enormous workflow describing every interaction between every program. It provides an environment in which independent processes can execute, communicate, wait for resources, and respond to events.
Mozaik applies a similar principle to multi-agent systems.
Instead of placing agents inside a fixed chain of handoffs, agents participate in a shared environment. They can react to semantic events, perform work concurrently, and communicate information without requiring the entire system to stop and reorganize itself.
Blocking still exists, but it happens at the smallest necessary level.
An agent may wait for a specific result without blocking unrelated agents. A process may synchronize two participants without forcing every participant in the environment to wait. New behavior can be introduced through events and rules rather than by rebuilding the entire workflow graph.
From Parallel Workflows to Concurrent Systems
Concurrency is not simply a performance optimization.
It changes what kinds of systems can be built.
Because waiting happens only where it is actually required, concurrency unlocks a new class of multi-agent systems designed for:
- high-speed execution,
- agent interoperability,
- intelligent communication,
- dynamic coordination,
- and resilience outside the predefined happy path.
The transition resembles a broader shift in how people and organizations develop.
At first, progress comes from following a reliable sequence. As complexity increases, growth requires greater independence, better communication, and the ability to adapt without waiting for someone to redesign the entire plan.
AI agents are reaching the same point.
The next generation of multi-agent systems will not be created by adding more agents to increasingly complicated workflows. It will come from giving agents an environment in which they can operate concurrently, coordinate intelligently, and wait only when waiting is necessary.
The future of agentic systems is not a faster assembly line.
It is a system of independent participants working together in real time.
With tools and technology we already have, we can build much more valuable systems than most projects today. We can write software that is a pleasure to use and a pleasure to work on; software that doesn't box us in as it grows, but creates new opportunities and continues to add value for its owners.