Multi-Agent Architectures

A single agent operating alone hits hard limits. Context windows fill up. The breadth of specialized knowledge required for a complex task exceeds what any single model can reliably maintain. Some subtasks can be done in parallel, but a single agent must work sequentially. Multi-agent architectures address these limits by distributing work across multiple cooperating agents — each with its own context, specialization, and role. The gains are real, but so are the costs. Knowing when and how to use multi-agent systems is one of the most practically important skills in advanced agent engineering.

Why one agent is not enough

The case for multi-agent systems rests on three structural limitations of single-agent designs.

Context limits. Even with very large context windows, complex tasks accumulate information faster than any window can hold. A research task that requires reading 200 documents, maintaining a structured notes system, drafting multiple sections of a report, and revising based on feedback will exhaust any practical context window. Splitting the task across multiple agents, each operating within its own context window, allows the work to scale without hitting this ceiling.

Specialization. Different subtasks benefit from different system prompt configurations, tool sets, and even different model choices. A "researcher" agent tuned for broad exploration and synthesis performs differently from a "coder" agent tuned for precise, testable code generation. Trying to optimize a single agent's system prompt and tools for both simultaneously produces a mediocre generalist. Specialization lets each agent be excellent at its role.

Parallelism. Many complex tasks have subtasks that are logically independent and can run simultaneously. A single sequential agent must work through them one at a time. A multi-agent system can run independent subtasks in parallel, reducing wall-clock time proportionally. For a task with five independent subtasks, this represents a potential 5x speedup in total execution time.

The orchestrator-subagent pattern

The most common multi-agent architecture is the orchestrator-subagent pattern: a single orchestrator agent that coordinates the overall task, and multiple subagents that handle specific subtasks assigned by the orchestrator.

The orchestrator's responsibilities: receive the high-level task; decompose it into subtasks; assign subtasks to appropriate subagents; collect and integrate results; handle failures and replanning; produce the final output. The subagents' responsibilities: receive a specific, well-scoped subtask; execute it within their specialized context and tool set; return a structured result to the orchestrator.

The key insight is that the orchestrator does not need to understand how each subtask is accomplished — it only needs to know what each subagent is capable of, and what to give them. This separation of concerns is what makes the pattern scalable: you can add new specialized subagents without changing the orchestrator's core logic, as long as the capability interface is well-defined.

Peer-to-peer agent networks

An alternative to the strict orchestrator-subagent hierarchy is a peer-to-peer architecture where agents communicate directly with each other without a central coordinator. Each agent can initiate requests to other agents, respond to requests, and broadcast information to the network.

Peer-to-peer architectures are more flexible but significantly harder to reason about. Without a central coordinator, it becomes difficult to track global task state, avoid duplicate work, detect when the overall task is complete, or diagnose failures. In practice, pure peer-to-peer multi-agent systems are rare in production; most real systems use a hybrid where a loose coordination layer exists even if it is not a full orchestrator.

Specialized agent roles

The most effective multi-agent teams consist of agents with clearly differentiated roles. Common specialized roles and their characteristics:

Parallel task execution and aggregation

One of the most valuable properties of multi-agent architectures is the ability to run independent subtasks in parallel. The implementation pattern is consistent across frameworks: the orchestrator identifies which subtasks are independent (can run without waiting for each other's results), dispatches them simultaneously, and then awaits all results before continuing.

In Python, this typically means using asyncio.gather() to run multiple async agent calls concurrently. The orchestrator sends tasks to multiple subagents, waits for all to complete, then processes the aggregated results. Error handling must account for partial failures: what should the orchestrator do if 3 of 5 parallel subtasks succeed but 2 fail?

Result aggregation is often itself an LLM task: after parallel researcher agents each return their findings, an orchestrator-level synthesis step merges the results into a coherent whole, resolves contradictions, and identifies gaps. This synthesis step is frequently where the real value of a multi-agent research system emerges — the integrated whole is more insightful than any individual part.

Agent communication formats

How agents communicate with each other matters enormously for reliability. Natural language is expressive but ambiguous; structured formats are precise but require schema agreement. The practical approach depends on the complexity of the interface.

For simple task dispatch and result return, structured JSON is usually sufficient and most reliable. The orchestrator sends a JSON object specifying the task, and the subagent returns a JSON result. For complex inter-agent communication — where agents need to express nuanced requests, partial results, or uncertainty — a combination of structured fields and a natural language description field often works well.

The key principle: be explicit about expected output format in the subagent's system prompt. Agents that return results in idiosyncratic formats require the orchestrator to do complex parsing; agents that reliably return structured, predictable formats compose cleanly. Enforce output schemas at the tool layer when possible — if a subagent's output is processed by a function that requires a specific format, validate at the interface before passing it along.

Trust hierarchies between agents

When agents can instruct other agents, the question of trust becomes critical. Should a subagent automatically do whatever the orchestrator tells it? The answer is no — and this has important security implications.

The correct mental model is: each agent in a multi-agent system has its own safety constraints and should maintain them regardless of the instruction source. An orchestrator that asks a subagent to take a dangerous, irreversible action should be refused, just as a human user making the same request would be refused. Legitimate orchestrators do not need to bypass safety measures; requests to do so are a red flag indicating potential compromise of the orchestrator or prompt injection through its inputs.

Design patterns: AutoGen, CrewAI, and Anthropic patterns

Several frameworks have operationalized multi-agent design patterns. Understanding their approaches reveals the design choices you will need to make regardless of which framework you use.

AutoGen's conversation-based approach is natural for tasks where agents need to negotiate, debate, or iterate on solutions together. CrewAI's role-based framing maps well to human team analogies and is easy to explain to non-technical stakeholders. Anthropic's tool-calling pattern treats subagent invocation as just another tool call, which makes it auditable and fits naturally into existing monitoring infrastructure. LangGraph is the most flexible but requires the most explicit design work upfront.

When NOT to use multi-agent systems

Multi-agent architectures add real complexity and cost. They are not always the right answer, and choosing them when a single agent would suffice is one of the most common mistakes in agentic system design.

Specific situations where single-agent is usually better:

• The task fits within a single context window with room to spare
• The task is sequential with no parallelizable subtasks
• The task requires consistent context across all steps (splitting context between agents loses coherence)
• Latency is a critical constraint and the task doesn't benefit from parallelism
• Debugging simplicity is important (multi-agent failures are significantly harder to diagnose)
• The overhead of inter-agent communication exceeds the efficiency gained from specialization