AI & Development
When does one AI agent become two? The principles behind multi-agent pipeline design - when to split, how to design handoffs, and the failure modes to avoid.
The natural first question when designing an AI workflow is: how many agents do I need? The natural first answer is: as few as possible. A single, well-specified agent that handles a complete task is simpler to build, simpler to debug, and simpler to maintain than a pipeline of coordinating agents. Start with one agent. Add a second only when you have a specific reason that a single agent cannot handle the scope.
The clearest signal that a task needs multiple agents is when it requires two or more types of expertise that actively conflict in how they should approach the work.
Consider a content workflow: writing a blog post and optimizing it for search. Writing and SEO optimization are not the same kind of expertise. Writing requires editorial judgment - voice, structure, argument, narrative. SEO optimization requires technical compliance - character counts, schema markup, internal link structure, sitemap updates. An agent that tries to do both simultaneously will either write in a way that feels like SEO optimization (stilted, keyword-stuffed, structured for algorithms rather than readers) or optimize in a way that undermines the writing (breaking up content structures that serve the reader to fit a snippet format that serves the algorithm).
Separating these into two agents - one that writes and one that optimizes - allows each agent to be specialized without compromise. The writing agent writes without worrying about schema markup. The SEO agent validates and enriches without rewriting the editorial content. The pipeline produces better output than either agent could produce alone, because each agent is operating in its domain of competence.
Multi-agent pipelines coordinate in three basic patterns. Understanding which pattern fits your task determines how you design the agents and the handoffs between them.
Sequential pipeline: Agent A completes its task and passes output to Agent B, which completes its task and optionally passes to Agent C. The output of each agent is the input of the next. This is the most common pattern and the easiest to reason about. The content pipeline (writer → SEO agent) is a sequential pipeline.
Parallel pipeline: Multiple agents work on different parts of a task simultaneously, and their outputs are combined. A research pipeline might run a web search agent, a codebase analysis agent, and a documentation reader agent in parallel, then synthesize their findings. Parallel pipelines are faster for tasks with independent subtasks but require a synthesis step at the end.
Supervisor-worker pipeline: A supervisor agent breaks a complex task into subtasks and delegates each subtask to a specialized worker agent, then reviews and integrates the results. This pattern scales to complex tasks but introduces the most coordination overhead. The supervisor agent must understand the full task well enough to decompose it correctly, which requires its own careful specification.
The handoff between agents is where multi-agent pipelines most commonly fail. If Agent A's output is ambiguous, inconsistent, or informal, Agent B must interpret it - and interpretation introduces errors. If Agent B does not know exactly what Agent A is expected to produce, it may wait for information that will never arrive or proceed without information it needs.
Good handoff design has three requirements:
A defined output format for the sending agent. Agent A must always produce its handoff in a specific, consistent format. This format should be specified explicitly in Agent A's system prompt. "After completing the post, produce a structured handoff block with the following fields: slug, publishedAt, seo.title, seo.description, category, tags, and a list of files created." The sending agent's system prompt defines the format; the receiving agent's system prompt defines how to interpret it.
A defined input expectation for the receiving agent. Agent B must know what it is receiving and what to do with it. Agent B's system prompt should describe the format it expects from the handoff and what to do if the handoff is malformed or incomplete. An agent that receives incomplete input and silently proceeds with assumptions produces errors that are difficult to trace back to the actual problem (the incomplete handoff).
An explicit termination signal. Agent A must signal clearly when it has finished and the handoff is complete. Without a termination signal, Agent B may start before Agent A is done, or never start because it cannot tell when to begin. In a sequential pipeline, the termination signal is typically the production of the structured handoff block. In a parallel pipeline, it is the completion of each parallel branch before synthesis begins.
In a multi-agent pipeline, each agent must have clear, non-overlapping scope. If two agents can both modify the same file, a conflict is possible. If two agents both believe they are responsible for the same decision, they may produce contradictory outputs that the receiving system or developer must manually resolve.
Scope isolation is enforced by tool access. If the writing agent does not have access to sitemap.xml, it cannot modify it - even if its system prompt does not explicitly say not to. Restricting tool access is more reliable than instructing agents to stay within their scope, because tool restrictions are enforced by the system rather than by the model's compliance.
Document the scope boundaries explicitly in each agent's system prompt, even if the tool restrictions also enforce them. "This agent does not modify sitemap.xml or any SEO configuration files. Those belong to the SEO agent." Explicit documentation of scope boundaries helps when an agent encounters an edge case at the boundary - it knows to defer rather than improvise.
When a multi-agent pipeline produces wrong output, the first diagnostic question is: at which stage did it go wrong? A pipeline where Agent B produces bad output might have a problem in Agent B's instructions - or it might have received bad input from Agent A and executed correctly on bad input. These are different problems with different solutions.
The most reliable debugging approach is logging the handoff between agents. If you can inspect what Agent A produced and what Agent B received, you can isolate where the error was introduced. Pipelines that do not log their handoffs are significantly harder to debug because the error may be invisible inside the pipeline.
More agents means more complexity. The case for using multiple agents should be a specific, identified failure of a single-agent approach - not a general preference for modularity. If a single, well-specified agent can handle the full scope of a task, use one agent. The overhead of designing handoffs, managing scope isolation, and debugging cross-agent failures is only justified when the task genuinely requires it.