Multi-Agent Systems: When One Agent Isn't Enough

"Multi-agent" is the phrase on every AI roadmap right now. Gartner predicts that 33% of enterprise software applications will include agentic AI by 2028, up from less than 1% in 2024. The same Gartner release also predicts that over 40% of agentic AI projects will be cancelled by the end of 2027. In my experience, needless complexity is one of the reasons. Here is how I decide whether a problem needs one agent or several.

What a multi-agent system is

A single agent is a model in a loop with tools: it reads a goal, picks an action, runs a tool, observes the result and repeats. A multi-agent system is several of those loops, each with its own instructions, tools and permissions, coordinated by an orchestrator, a fixed pipeline, or each other.

The important word is "its own." If two "agents" share the same prompt, tools and permissions, you have one agent with extra latency.

When one agent is enough

Most of the agent work I scope ends up as a single agent with good tools. That is the right answer when:

• the task fits in one context window without losing track,
• one set of permissions is appropriate for every step,
• there is no natural checkpoint where a person would want to review an intermediate result,
• the steps are tightly coupled, so splitting would mean passing large amounts of context back and forth.

A support agent that searches documentation, looks up an account and drafts a reply is a single agent. Splitting it into a "search agent", a "lookup agent" and a "writer agent" usually makes it slower and harder to debug without making it better.

When to split into multiple agents

I split when at least one of these is true.

Stages need different permissions

An agent that reads customer emails should not hold the credentials to merge code or issue refunds. Separate agents with separate tool sets are the cleanest way to enforce least privilege.

Stages produce reviewable artifacts

If a stage produces something a person would naturally check, such as a spec, a plan, a set of tickets or a draft contract, it is a good boundary. The artifact becomes the contract between agents and the place to put a human approval step.

Context would overflow

Long, research-heavy work can exceed what one agent can track. Sub-agents can do focused work in their own context and return a short summary. Anthropic notes that in this pattern "the detailed search context remains isolated within sub-agents", while the lead agent focuses on synthesizing and analyzing the results.

Different teams or vendors own the stages

When the agents belong to different organisations, they need a protocol rather than shared code. That is where A2A comes in; see MCP vs A2A.

A worked example: AgentOps

The clearest multi-agent system I have built is AgentOps. A request posted in Slack becomes a Confluence spec, then Jira tickets, then a GitHub pull request, then a live Vercel preview.

It is multi-agent for the reasons above, not for the label:

• One agent per stage, one artifact per agent. Each agent produces the artifact the team already uses, so its job is narrow and its output is easy to review.
• Human approval between stages. Nothing moves forward without a person approving it. The spec is checked before tickets are created, and tickets before code is written. An agent that is wrong early is caught before the mistake spreads into tickets and code.
• Different tools per stage. The spec agent needs Confluence; the coding agent needs the repository. Neither needs the other's access.
• It ends on something people can click. Stakeholders who will never read a pull request can still approve or push back on a running preview.

Orchestration patterns that hold up

Most production systems I see today are pipelines or routers with human checkpoints. Fully autonomous agent teams that negotiate with each other make good demos and fragile products.

Failure modes to design out

• Errors compounding. Each stage trusts the previous one, so a chain of stages is less reliable than any single stage in it: small error rates multiply. Put a check, automated or human, at each artifact boundary.
• Context loss at handoffs. The original request's nuance disappears by stage three. Pass the original request alongside each artifact, not just the previous output.
• Loops. Two agents can bounce a task back and forth indefinitely. Set step limits and a timeout for the whole run.
• Unclear ownership. When the final output is wrong, you need to know which agent made which decision. Log every agent's inputs, outputs and tool calls with a shared run ID.
• Cost surprises. Every agent call costs tokens. Measure cost per completed run from day one.

Testing a multi-agent system

Test each agent alone first, with its own eval set and a reference artifact for each case. Then test the whole pipeline end to end on realistic requests. When an end-to-end case fails, the per-agent tests tell you where. I explain how to set this up in why AI agent projects fail, and the evals that prevent it.

A checklist before you split

• Can I name the artifact each agent produces?
• Does each agent need tools or permissions the others should not have?
• Is there a point where a person would naturally review the work?
• Have I tried a single agent with better tools first?
• Do I log a shared run ID across every agent?

If you cannot answer yes to the first three, start with one agent.

Work with me

I design and build agent systems, from a single well-tooled agent to multi-agent pipelines with human checkpoints. See AI agent development, read the AgentOps case study, or book a scoping call to work out how many agents your problem actually needs.