Five communication patterns between AI agents
A single agent has one context window. The moment you need more than that - more roles, more parallelism, more steps - agents have to talk. How they talk is the whole design.
Every multi-agent system is really a decision about how context moves. An LLM only knows what is in its context window, so the topology you choose decides what each agent can see, what it can forget, and where the system breaks. Five patterns cover almost everything in production today - most real systems combine two or three.
The recurring trade-off: more agents = more parallelism and specialization, but more tokens, more latency, and more places for context to get lost in translation.
Sequential
Agents are arranged in a line: each one does its step, then hands its output to the next. A research agent finds sources, a writer drafts from them, an editor polishes. Simple, predictable, and easy to debug - you can read the trace top to bottom.
Context accumulates down the chain. Each agent typically receives only the previous agent’s output, not the full history - so early detail is lost unless you deliberately pass it along. Cheap on tokens, but a mistake early on propagates silently to the end.
Orchestrator–worker
A lead agent owns the goal. It breaks the task into subtasks, delegates each to a specialized worker, then synthesizes their results into one answer. The workers never talk to each other - all coordination flows through the orchestrator.
The orchestrator holds the master context; workers get only the slice they need. This keeps each worker’s window small and focused, but the orchestrator can become a bottleneck - and whatever it fails to pass down, the workers simply can’t know.
Parallel
The same input is sent to several agents at once - different models, different prompts, or different perspectives - and their outputs are merged by an aggregator. Think three reviewers grading a document simultaneously, then a judge reconciling them.
Every branch starts from the same shared context, in parallel. Fast, and great for cross-checking, but nothing is shared between branches mid-flight - and the aggregator has to fit all results into one window, which can get expensive at the merge step.
Hierarchical
Orchestration nested several levels deep: a top agent delegates to mid-level managers, who each run their own teams of workers. It mirrors a real org chart and lets you scale to large, multi-stage problems without any one agent holding everything.
Context is scoped by level - each manager holds only its branch’s picture, summarized up and down the tree. This contains complexity beautifully, but every summary hop loses fidelity, so detail from a leaf rarely survives intact to the top.
Network
Agents communicate many-to-many - either broadcasting in a shared "group chat" or reading and writing to a common blackboard / shared memory. There is no fixed leader; agents pick up work, react to each other, and converge through discussion or a stopping rule.
Context is shared and emergent - the blackboard is the common memory every agent can see. Maximally flexible, but the shared space grows fast, conversations can loop, and without firm termination rules the system can talk itself in circles and burn tokens.
So which one?
Start with the simplest topology that fits the work, and only add agents when a single context window genuinely can't hold the job. A clean rule of thumb:
And whatever the shape: budget context like money. Every hop between agents is a chance to summarize, compress, or lose the thread. The systems that hold up in production are the ones that decide, deliberately, what each agent is allowed to forget.