You’ve probably seen the demo. A planner agent, a researcher agent, a coder agent, a reviewer agent and a manager agent, all passing messages to each other on a nice dashboard. It looks like a small company at work. And you’ve already used something like it yourself, every time Claude Code or Copilot started a subagent to explore your repo.
So here’s the question I want you to sit with first. Do you actually need more than one agent?
Most of the time, you don’t. Back in 05a we said start with the simplest thing that works. A function, then one model call, then a workflow, then one agent with tools. Every box you add to that demo is another model call, another prompt to maintain and another place for things to go wrong. One agent with good tools and a well-managed context goes a long way.
So when does splitting help? I use four questions.
Is the work genuinely parallel? If you need to look into five independent things, five agents can do it at once and each reads only its own part. Would one context overflow? If a single agent would have to hold too much, splitting keeps each one focused. Do the parts need different permissions? An agent that reads customer emails shouldn’t be the same one that can issue refunds. And is part of the work owned by someone else, another team or another company, who runs their own agent?
If none of these is true, keep one agent. You know this argument from monoliths and microservices. You split a service when there’s a real boundary, like scale, ownership or security. Small services looking tidy on a diagram is no reason. Agents are the same.
The comparison stops in one place. Two services talk through a contract you wrote. When one agent hands work to another, a model reads another model’s text, so a wrong or planted sentence in one output can carry into the next agent.
Add another agent only when it creates a real boundary.
The common patterns
Once you do split, a few shapes keep coming up. Some will look familiar from the workflow patterns in 05a. The difference is that each box here is a whole agent with its own loop.
| Pattern | In plain words | Helps when |
|---|---|---|
| Orchestrator and workers | a lead agent breaks the job up, hands pieces to workers, and puts the answers together | you can’t know the subtasks in advance |
| Handoff | one agent passes the whole conversation to another and steps out | the request moves to a different specialist, like triage to billing |
| Parallel fan-out | many agents work on independent pieces at the same time, and the results are merged | the pieces really don’t depend on each other |
| Critic | one agent produces, another checks it against clear criteria and sends it back | you can say what good looks like |
Anthropic’s research feature in Claude is a good real example of the first one. They describe a lead agent that plans the research and starts subagents that search in parallel, then combines what they find. The OpenAI Agents SDK makes the handoff idea explicit. A handoff transfers control, and the receiving agent takes over the conversation. If you only want a specialist’s answer without giving up the conversation, the SDK suggests calling that agent as a tool instead.
How does a lead agent turn one task into one answer?
What it costs
Now the bill. In the same write-up, Anthropic says agents typically use about four times more tokens than chat, and their multi-agent system about fifteen times more. They’re clear that this only pays off for tasks valuable enough to justify it.
Latency adds up too. An orchestrator plans, waits for the workers, then combines. A chain of handoffs is a chain of round trips.
And debugging gets harder. Each agent is non-deterministic, so two runs with the same input can take different paths. When the final answer is wrong, which agent got it wrong? Every handoff is also a lossy summary, the same problem we saw with subagents in 04c, now at every boundary. Anthropic also says plainly that tasks where all agents need the same context, or where there are many dependencies between agents, are a poor fit, and that most coding tasks have fewer truly parallel parts than research does.
So when shouldn’t you use it? When the steps depend tightly on each other. When everyone needs the same context anyway. When one agent with a bigger toolset would do. And when you can’t yet trace and test a single agent properly, because adding more will only hide the problem.
How this differs from subagents in 04c
In 04c, the subagent was about keeping your main context clean. It all happened inside one product, one harness, one owner.
This article is about something wider. Separate agents, possibly built by different teams on different frameworks, or run by a vendor you don’t control. Your support agent asks a partner’s shipping agent where a parcel is. Now you need to discover what the other agent can do, send it work, follow a long-running task, and decide whether to trust what comes back. That’s where protocols start to matter.
The protocols, briefly
You already know one. MCP, from 04b, connects an agent to tools and data. It’s agent-to-tool.
A2A, the Agent2Agent protocol, connects agents to other agents. Google started it and it’s now a Linux Foundation project. At its one-year mark in April 2026, the Linux Foundation said more than 150 organizations support it and it’s built into the agent platforms of Google Cloud, Microsoft and AWS. Two ideas are worth knowing. An agent publishes an agent card, a JSON document describing what it can do, where its endpoint is and how to authenticate. If you’ve used service discovery or an OpenAPI spec, it plays a similar role. And the other agent stays opaque. You send it a task and get results back, without seeing its memory, tools or prompts. That’s exactly what you want across a company boundary.
AG-UI covers the third side, the agent talking to the user’s screen. As of October 2026, its docs describe it as an open, event-based protocol that streams events like messages, tool calls and state updates between an agent backend and a frontend. It’s the streaming idea from 02b, standardised. It came out of CopilotKit’s work with LangChain and CrewAI, and its docs list support in frameworks such as Microsoft Agent Framework and Google’s ADK.
Protocols are not interchangeable; each one solves a different boundary.
If all your agents live in one codebase and one process, you probably need none of these. A function call is a fine protocol. Reach for A2A when an agent sits behind a real boundary.
Trust between agents
Once agents talk to agents, a new question appears. Whose authority is this agent acting on? If your agent calls another with its own powerful service account, the user’s permissions have quietly disappeared somewhere in the chain. I wrote about passing the user’s identity down instead in The Confused Deputy Is In Your Agent Right Now, and about whether controls still hold when you stack them together in Twelve Governance Patterns On One Agent: Do They Compose?.
Next, we treat all of this as what it really is, a distributed system, with boundaries, retries and failures.
