The Three Ways People Build AI Agent Systems: From Fixed Workflows to Concurrent CollectivesStar on GitHub↗

The Three Ways People Build AI Agent Systems: From Fixed Workflows to Concurrent Collectives<br>Every AI agent system I have seen in production — ours included — is built one of three ways. Most teams don’t choose consciously. They inherit the first way from the framework they installed, discover its ceiling, graduate to the second, and only hit the third when the second one fails them in a way they can name.<br>Last week one of our own agents died mid-thought because part of our system was still secretly living in the first way. This post is the taxonomy, and that story.<br>Way one: the Agentic Waterfall<br>The first system everyone builds is a chain. Agent A analyzes, hands off to Agent B, which reasons, hands off to Agent C, which writes. Done. Every framework tutorial teaches this shape because it is the easiest thing to draw.<br>WAY ONE — THE AGENTIC WATERFALLAgent Aanalyze — runningAgent Breason — waitingAgent Cwrite — waitingdoneOne agent works. Everyone else waits their turn.The dependency chain becomes the architecture.The problem is not that chains are simple. The problem is that the dependency chain becomes the architecture. Every new capability adds another handoff, another wait, another failure point. Want a reviewer? Insert it between B and C, and now everything downstream of B waits on it. Want a researcher? Another link, another serialization point.<br>Four costs show up on every invoice:<br>Execution time. Every handoff is a synchronization barrier. The system is as slow as the sum of its links.<br>Token waste. Context gets re-fetched and re-explained at every hop, because each agent starts cold.<br>Rigidity. Adding an agent means redesigning the sequence. The org chart is welded into the code.<br>Fragile recovery. When something unexpected happens mid-chain, there is no place to put that knowledge except “throw and restart.”<br>We call this the Agentic Waterfall, and like its namesake it isn’t wrong for small, known, linear work. It is wrong the moment the work stops being linear — which is the moment the work becomes interesting.<br>Way two: the Parallel Graph<br>The obvious fix is to fan out. Run the backend agent, the frontend agent, and the test agent at the same time; join their results; continue. This is the DAG stage — workflow graphs, fan-out/fan-in, Promise.all with extra steps.<br>It genuinely helps. It is also where most mature teams are stuck today, because of a subtle property that took us a long time to articulate:<br>The branches are parallel. The system is not.<br>WAY TWO — THE PARALLEL GRAPHBackend agentslow — runningFrontend agentdone — waitingTests agentdone — waitingwait for allthe slowest sets the paceNext stepcannot start yetThe branches are parallel. The system is not.Nothing inside a branch can influence a sibling before the join.Every join is a wait-for-all barrier. The slow branch sets the pace; the fast branches sit idle at the merge; and nothing that happens inside a branch can influence a sibling, because the only communication channel is the join point at the end. A test agent that spots a fatal problem in the first ten seconds has no way to tell the backend agent to stop wasting tokens — they will meet at the barrier, later, when the money is already spent.<br>The graph also has to be drawn before the work starts. That is fine when you know the work. It fails precisely on the work that gets discovered while doing — and discovered work is what agents are for.<br>Way three: the Event-Driven Collective<br>The third way stops modeling execution paths and starts modeling the environment where agents operate . Agents become participants in a shared runtime. They emit semantic events — “story S1 merged”, “verification failed”, “I discovered work nobody planned” — and they subscribe to what they care about. Nobody hands off to anybody. Progress continues while agents think, and the system waits only where waiting is real : a story that needs another story’s files genuinely waits for the merge; everything else flows.<br>WAY THREE — THE EVENT-DRIVEN COLLECTIVEPlannerplanning fragment 3Agent Bwriting codeAgent CverifyingCriticreviewing a turnIntegratormerging a storySEMANTIC EVENT STREAMEveryone is working. The system waits only where waiting is real.Coordination logic stops being branches hardcoded into a workflow and becomes rules about situations: when a user message arrives and capacity is available, then run inference. Budgets, failures, and surprises become reusable system rules instead of special cases sprinkled through a graph.<br>Like an operating system running many programs at once — that is the mental model. Not a diagram of steps; a place where work happens.<br>The story of a planner that died mid-thought<br>Here is why I am writing this now instead of any other week.<br>Our agent, baro, runs a collective of coding agents against real repositories. The executors have lived in way three for months: they run concurrently,...