Agent Orchestration: A Practical Guide (2026)

Once you've decided multi-agent is the right shape (and the multi-agent guide covers the cases where it isn't), the next question is how the agents coordinate. There are four orchestration patterns that recur in production, and the protocol choice (A2A, LangGraph, OpenAI Swarm, raw HTTP) is largely downstream of which pattern fits your problem.

This guide covers the four patterns, the three protocols, and the rule that usually picks one. Full treatment in Chapters 3-4 of A2A in Production.

Pattern 1: router

One agent receives the request, decides which specialist should handle it, dispatches, returns the specialist's result.

• Shape: request -> router -> specialist -> response.
• Strength: simple. The routing decision is the only multi-agent surface.
• Weakness: routing accuracy is everything. A router that picks wrong is a system that does the wrong work confidently.
• Right for: a small set of well-differentiated specialists. A customer-support intake agent that routes to billing vs technical vs sales is the canonical example.
• Wrong for: work that needs cross-specialist coordination.

Pattern 2: supervisor

One agent owns the task end-to-end. It plans, decomposes, dispatches subtasks to specialists, integrates results, decides next steps.

• Shape: request -> supervisor (plans) -> [specialist 1, specialist 2, ...] -> supervisor (integrates) -> response.
• Strength: handles complex multi-step work. The supervisor sees the whole arc.
• Weakness: the supervisor is a single point of failure and bottleneck. Its context fills up faster than any specialist's.
• Right for: tasks that benefit from plan-then-execute. Research tasks, multi-step debugging, anything where the path isn't known in advance.
• Wrong for: embarrassingly parallel work (use swarm) or workflows where the path is fixed (use a pipeline, not agents).

Pattern 3: swarm

Multiple agents work in parallel on independent subtasks; an aggregator combines results. No central orchestrator after the initial dispatch.

• Shape: request -> dispatch -> [agent 1 || agent 2 || ...] -> aggregator -> response.
• Strength: wall-clock latency stays low even as you add specialists.
• Weakness: requires the work to actually be independent. If specialist 2 needs specialist 1's output, you're back to supervisor.
• Right for: "fetch from three sources and combine," parallel reviews, multi-perspective analysis.
• Wrong for: sequential workflows.

Pattern 4: blackboard

Agents read from and write to a shared workspace. The next agent to act picks up wherever the previous agent left off. Coordination is via the shared state, not via a central orchestrator.

• Shape: agents <-> shared workspace.
• Strength: emergent coordination; flexible to changing topology; resilient to agent failure (just restart).
• Weakness: race conditions; ordering issues; very hard to debug; the shared state becomes the bottleneck.
• Right for: exploratory or research workflows where the shape emerges from the interaction.
• Wrong for: anything requiring strong ordering guarantees or deterministic behavior.

The three protocols

A2A (Google-authored)

The first attempt at a standardized agent-to-agent protocol. Cards (capability descriptions), tasks (the work unit), and messaging primitives. Best when you want cross-organization interop and the other side speaks it.

LangGraph hand-offs

An orchestration framework, not a protocol. Agents are nodes in a graph; hand-offs are edges. Best when you're inside the LangChain ecosystem and want to keep state management batteries-included.

OpenAI Swarm

A lightweight pattern (not really a protocol) for agent hand-offs. Best when you're already using OpenAI's tools and want the minimum surface.

Raw HTTP

Agents talk over JSON-over-HTTP with whatever shape you define. Most production multi-agent systems start here. Best when you want full control and don't need cross-org interop.

How to pick

The decision order:

1. Pick the pattern that fits the work (router/supervisor/swarm/blackboard).
2. Pick the protocol that fits the pattern + your interop needs.
3. Resist composing patterns until you've measured what's actually slow.

Patterns compose -- a supervisor whose specialists are themselves routers, for example -- but compositions multiply the failure surface. Start with one pattern; add composition only when measurement says you need it.

Want the full treatment?

A2A in Production Chapters 3-4 cover the four patterns with worked examples, the protocol comparison with the spec-vs-pattern distinction, and the "when not to use A2A" cases that often turn out to be the right answer.

Published by Yaw Labs.

Related

• A2A in Production -- the book.
• Multi-Agent Systems: A Practical Guide
• Agent Auth Across Boundaries
• Federated Memory