Multi-Agent Orchestration Patterns with A2A
A2A does not dictate an architecture, but the field has converged on a small set of orchestration patterns: the orchestrator (one agent delegates to specialists and assembles results), sequential delegation (each agent's output feeds the next), parallel delegation (independent sub-tasks run at once), and peer handoffs (agents delegate directly to each other, no central coordinator).
They compose freely, because "client" and "remote agent" are roles, not types — any agent can delegate to any other it can discover.
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.
Sequential and 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 do not depend on each other, for speed.
Most real workflows mix both: fan out in parallel where you can, chain sequentially where you must.
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, 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
| 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 | Slower; each step blocks the next |
Match the pattern to the failure you fear,
not to the diagram that looks impressive.
Composing patterns
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 in larger systems
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 test of a good design: can you add a new specialist agent without editing the orchestrator?
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.
- Multi-agent for its own sake — every delegation adds a network hop and usually another model call. Reach for it when specialization or scale earns the overhead.
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, so the whole workflow can be reconstructed after the fact.
Log each task's start, state changes, and result against that id. Adopt the Traceability extension where you can, so traces cross agent boundaries automatically. When something goes wrong three agents deep — and eventually it will — this is the difference between reading the trail and guessing.
Handling partial failure
One specialist failing should not necessarily doom the whole workflow. Decide up front what your orchestrator does when a delegated task fails: retry, fall back to another agent, return a partial result, or abort.
Set timeouts on every delegation. A remote agent can be slow, unavailable, or operated by a team you cannot page. Defensive clients are what keep your system stable when a peer misbehaves.