{"slug": "the-three-ways-people-build-ai-agent-systems", "title": "The three ways people build AI agent systems", "summary": "A new taxonomy from an unnamed engineering team identifies three ways AI agent systems are built in production: the Agentic Waterfall, the Parallel Graph, and the Event-Driven Collective. The post argues that most teams start with the waterfall, hit its ceiling, move to the parallel graph, and only reach the event-driven model when the second fails. The author recounts an incident where their own agent died mid-thought due to reliance on the first approach.", "body_md": "The Three Ways People Build AI Agent Systems: From Fixed Workflows to Concurrent Collectives\nEvery 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.\nLast 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.\nWay one: the Agentic Waterfall\nThe 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.\nWAY ONE — THE AGENTIC WATERFALL\nAgent A\nanalyze — running\nAgent B\nreason — waiting\nAgent C\nwrite — waiting\ndone\nOne agent works. Everyone else waits their turn.\nThe dependency chain becomes the architecture.\nThe problem is not that chains are simple. The problem is that\n \nthe dependency chain becomes the architecture.\n 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.\nFour costs show up on every invoice:\nExecution time.\n Every handoff is a synchronization barrier. The system is as slow as the sum of its links.\nToken waste.\n Context gets re-fetched and re-explained at every hop, because each agent starts cold.\nRigidity.\n Adding an agent means redesigning the sequence. The org chart is welded into the code.\nFragile recovery.\n When something unexpected happens mid-chain, there is no place to put that knowledge except “throw and restart.”\nWe 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.\nWay two: the Parallel Graph\nThe 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,\n \nPromise.all\n with extra steps.\nIt 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:\nThe branches are parallel. The system is not.\nWAY TWO — THE PARALLEL GRAPH\nBackend agent\nslow — running\nFrontend agent\ndone — waiting\nTests agent\ndone — waiting\nwait for all\nthe slowest sets the pace\nNext step\ncannot start yet\nThe branches are parallel. The system is not.\nNothing inside a branch can influence a sibling before the join.\nEvery 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\n \ninside\n 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.\nThe 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\n \ndiscovered\n while doing — and discovered work is what agents are for.\nWay three: the Event-Driven Collective\nThe third way stops modeling execution paths and starts modeling\n \nthe environment where agents operate\n. 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\n \nonly where waiting is real\n: a story that needs another story’s files genuinely waits for the merge; everything else flows.\nWAY THREE — THE EVENT-DRIVEN COLLECTIVE\nPlanner\nplanning fragment 3\nAgent B\nwriting code\nAgent C\nverifying\nCritic\nreviewing a turn\nIntegrator\nmerging a story\nSEMANTIC EVENT STREAM\nEveryone is working. The system waits only where waiting is real.\nCoordination logic stops being branches hardcoded into a workflow and becomes rules about situations: \nwhen\n a user message arrives\n \nand\n capacity is available, \nthen\n run inference. Budgets, failures, and surprises become reusable system rules instead of special cases sprinkled through a graph.\nLike an operating system running many programs at once — that is the mental model. Not a diagram of steps; a place where work happens.\nThe story of a planner that died mid-thought\nHere is why I am writing this now instead of any other week.\nOur agent,\n \nbaro\n, runs a collective of coding agents against real repositories. The executors have lived in way three for months: they run concurrently, exchange events, learn about each other’s merges while working. But the \nplanner\n — the agent that decomposes the goal into stories — was still architecturally a waterfall citizen: a separate process at the end of a one-way pipe, publishing plan fragments downstream, hearing nothing back.\nTwo things followed, and we measured both.\nFirst, the fragile-recovery cost. Because the planner was outside the runtime, the host supervised it the only way you can supervise a black box: a wall-clock timeout. Eight minutes into a productive planning session — moments after it had \npublished a fragment\n, the clearest possible proof of life — the watchdog killed it. The timeout had already been raised once, for the same reason, and the comment in the code admitted it. That is what “fragile recovery” looks like from the inside: when a component can’t tell you it is alive, you end up guessing, and every guess eventually kills someone innocent.\nSecond, the communication cost. The planner’s publish call returned a receipt computed \nby its own process\n — a polite local echo, not the runtime’s actual admission. When the host pruned a dependency edge the planner had imagined, that fact went to a log file nobody reads. Stories ran, merged, failed; the planner planned on, blind, against a repository state that no longer existed.\nSo we moved it into the collective. The planner is now a participant on the same event bus as everything it plans for. When it publishes a fragment, the receipt it gets is the runtime’s real answer — graph version, admitted stories, and exactly which dependency edges were pruned and why. While it plans the next fragment, execution news streams to it live: this story merged, that one failed twice, this one is blocked. And its supervision changed from “how long have you been running” to “how long have you been\n \nsilent\n” — output resets the clock, so an agent that is visibly working can never be killed by an arbitrary stopwatch, while a genuinely hung one still dies fast.\nThe planner did not get smarter. Its \nsituation\n got smarter. That is the whole thesis of way three in one sentence.\nThe third way contains the first two\nOne thing this taxonomy is \nnot\n: three competing tools where you pick a side.\nA chain is a degenerate collective — one where every agent subscribes to exactly one event, “my predecessor finished,” and nothing else. A graph is a collective where the joins happen to be real and known in advance. An event-driven runtime expresses both, literally, as rules: \nwhen S1 merges, start S2\n is a waterfall;\n \nwhen all three branches report, synthesize\n is a fan-in. Nothing about way three forbids sequence. It removes the\n \nobligation\n to sequence — the assumption, baked into ways one and two, that everything must block because \nsome\n \nthings must.\nWe see this daily in our own runs. Inside a single execution, a foundation story and its dependent run as a pure chain, six independent module migrations run as a graph, and the agents narrating discoveries to each other are the full collective — one runtime, one set of rules, three shapes coexisting because each part of the work got exactly the coupling it needed.\nSo if you are on way one or way two today, the migration is not a rewrite. Your workflow is already a valid program in the third model — just an implicit one. Making it explicit is what buys you the option to \nstop\n blocking, one barrier at a time, wherever the work turns out not to need it.\nChoosing consciously\nThe honest version of the advice is not “always build way three.” It is:\nIf the work is known, small, and linear — a chain is fine. Ship it.\nIf the work is known and parallelizable — a graph buys real speed. Take it, and accept that the joins are your ceiling.\nIf the work is \ndiscovered while doing\n — if agents will learn things mid-flight that should change what other agents do — then chains and graphs will both fail you at the same place: the moment reality diverges from the diagram. That is when you need an environment, not a workflow.\nAnd here is the claim we are prepared to defend:\n \nwe will never reach truly intelligent systems without real concurrency\n \n— a runtime where agents discover, react, communicate, and adapt\n \nwhile the work is happening\n, not between predefined steps. Intelligence is not a property of a single model call; it is a property of a system that can change its mind mid-flight. A chain cannot change its mind. A graph can only change its mind at a barrier. Every intelligent system we know of — a team, a market, an organism — runs concurrently, notices things while acting, and re-plans without stopping the world. Agent systems will be no different.\nWe built\n \nMozaik\n, our open-source TypeScript runtime, because we kept hitting that third case. The planner story above is just the latest component to make the move — and the pattern of the migration was the same as every one before it: find the one-way pipe, find the stopwatch, replace both with participation.\nThe dependency chain is not the architecture. The environment is.\nMiodrag Todorović\nCo-founder @ JigJoy\nMy passion is to tell the world the stories about the beautiful stuff we have built.\nWith 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.\nNewsletter\nFor developers who want to learn how to build self-organizing agents.\nWe're organizing a hackathon\nWe're organizing a hackathon — compete using the Mozaik framework.", "url": "https://wpnews.pro/news/the-three-ways-people-build-ai-agent-systems", "canonical_source": "https://mozaik.jigjoy.ai/blog/the-three-ways-people-build-ai-agent-systems", "published_at": "2026-08-14 13:22:04+00:00", "updated_at": "2026-08-14 13:43:24.890267+00:00", "lang": "en", "topics": ["artificial-intelligence", "ai-agents"], "entities": [], "alternates": {"html": "https://wpnews.pro/news/the-three-ways-people-build-ai-agent-systems", "markdown": "https://wpnews.pro/news/the-three-ways-people-build-ai-agent-systems.md", "text": "https://wpnews.pro/news/the-three-ways-people-build-ai-agent-systems.txt", "jsonld": "https://wpnews.pro/news/the-three-ways-people-build-ai-agent-systems.jsonld"}}