One agent calling another is useful. The real power appears when you compose many — and a few patterns recur everywhere.
A2A doesn't dictate an architecture, but the field has converged on a small set of orchestration patterns.
The most common is the orchestrator pattern: one agent receives a request and delegates sub-tasks to specialists, then assembles their results. Delegation can be sequential (each result feeds the next) or parallel (independent sub-tasks at once).
You don't always need a center. Because client and remote agent are just roles, agents can also hand off peer-to-peer — letting work flow to whichever agent is best suited, without a bottleneck.
The orchestrator pattern
The most common shape is a single orchestrator agent that receives a request and delegates sub-tasks to specialized remote agents, then assembles their results. The orchestrator holds the plan; the specialists do focused work.
This maps naturally onto A2A: the orchestrator is a client to each specialist, and each specialist is a remote agent exposing its skills. Nothing special is required — it's the base protocol used deliberately.
Sequential vs parallel delegation
- Sequential — the orchestrator delegates step by step, feeding each agent's Artifact into the next. Use it when later work depends on earlier results.
- Parallel — the orchestrator delegates independent sub-tasks at once and gathers results as they complete. Use it when sub-tasks don't depend on each other, for speed.
A worked picture: a user asks for a market report. The orchestrator delegates data-gathering to a research agent and chart-making to a visualization agent — in parallel, since neither needs the other. Both stream to completion. The orchestrator collects two Artifacts and assembles the report.
Peer delegation and handoffs
Not every system needs a central orchestrator. Agents can also delegate peer-to-peer: a support agent hands a billing question directly to a billing agent, which may in turn consult a fraud agent.
Because "client" and "remote agent" are just roles in a single interaction, any agent can delegate to any other it can discover. Handoffs like these let work flow to whichever agent is best suited, without routing everything through one bottleneck.
Choosing a shape
There is no single right architecture, only the one that matches your priorities.
| Priority | Pattern | Trade-off |
|---|---|---|
| Control and observability | Central orchestrator | Concentrates risk in one agent |
| Resilience and flexibility | Peer delegation | Harder to trace end to end |
| Speed on independent work | Parallel fan-out | Needs aggregation and timeout strategy |
| Correctness on dependent work | Sequential delegation | Slower; each step waits on the last |
Match the pattern to the failure you fear.*Control, or resilience — pick deliberately.*
Patterns compose
Real systems rarely use one shape in isolation. A top-level orchestrator might fan out in parallel to several specialists, one of which internally runs a short sequential pipeline of its own, while another hands off peer-to-peer to an agent it discovered at runtime.
The patterns compose because they are all just agents playing client and remote-agent roles. Start with the simplest shape that solves the problem, and layer another only when a concrete need — speed, resilience, or flexibility — calls for it.
Discovery at scale
As the number of agents grows, hard-coding endpoints stops scaling. This is where Agent Cards earn their keep: an orchestrator can select an agent by matching a task to advertised skills rather than by knowing a fixed address.
Registries and directories of A2A agents extend this further, letting systems find capable agents dynamically — the agent equivalent of service discovery in microservices.
The practical test of whether you've done this right: can you add a new specialist agent without editing the orchestrator? If yes, you're delegating by skill. If no, you're hard-coding.
Three anti-patterns
- The god orchestrator — one agent that knows every other agent's internals. It defeats the point; delegate by advertised skill, not by hard-coded knowledge.
- Chatty delegation — bouncing tiny messages back and forth when one well-formed task would do. Each hop adds latency and failure surface.
- Silent fan-out — launching many parallel tasks with no aggregation or timeout strategy, so one slow agent stalls the whole result.
Cost and latency are real
Every delegation adds a network hop and, often, another model call. A workflow that fans across several agents can be slower and costlier than a single one.
Design with that in mind: parallelize independent work, avoid chatty back-and-forth where one well-formed task would do, and ask honestly whether a step truly needs a separate agent or could be a tool call within one.
Multi-agent is a means, not a goal. Reach for it when the specialization or scale earns its overhead — not because it sounds impressive.
Keeping orchestration observable
An orchestrated workflow is only as debuggable as its trail. Because a single request may pass through several agents, attach a correlation identifier at the top and carry it through every delegation.
Log each task's start, state changes, and result against that id. When something goes wrong three agents deep — and eventually it will — this is the difference between reading the trail and guessing.
Frequently asked questions
What is the orchestrator pattern in multi-agent systems?
One agent receives a request and delegates sub-tasks to specialized remote agents, then assembles their results. The orchestrator holds the plan; the specialists do focused work. In A2A the orchestrator is simply a client to each specialist.
When should I use parallel vs sequential delegation?
Parallel when sub-tasks don't depend on each other — it's faster. Sequential when later work needs earlier results. Most real workflows mix both.
Do I always need a central orchestrator?
No. Agents can delegate peer-to-peer, since client and remote agent are roles rather than fixed types. Peer delegation is more resilient and avoids a bottleneck, but it's harder to trace end to end.
How do orchestrators find the right agent?
By matching a task to skills advertised in Agent Cards, rather than by knowing fixed endpoints. Registries extend this further. The test: can you add a new specialist without editing the orchestrator?
Is multi-agent always better than one agent?
No. Every delegation adds a network hop and usually another model call, so multi-agent workflows can be slower and costlier. Reach for it when specialization or scale genuinely earns the overhead.
More in this series
- A2A vs MCP — A2A vs MCP: The Two Protocols Behind Every Serious AI Agent System
- What Is A2A? — What Is the Agent2Agent Protocol? A Complete Introduction to A2A
- The Agent Card — The Agent Card: How AI Agents Discover Each Other
Want to go deeper?
I wrote two guides on this.
A2A Quick-Start — free, 6 pages. The Agent2Agent protocol in 15 minutes: what it is, the five building blocks, the task lifecycle, and where MCP fits.
A2A: The Complete Guide — 42 pages. 15 chapters, 5 appendices. Discovery, security, building your first agent with the SDK, orchestration patterns, extensions and AP2, production and scaling — plus a full worked example of two agents talking and a 30-day adoption path.
Independent educational content. Not affiliated with, endorsed by, or sponsored by Google, the Linux Foundation, Anthropic, or any vendor named. A2A and MCP are evolving specifications — confirm details against the official specification for your target version.
Top comments (0)