Multi-Agent Systems: When One Agent Isn't Enough

A single agent with a clear goal and the right tools can accomplish a lot. But some tasks break the model. The context window fills up before the work is done. The task has parallel subtasks that a single thread cannot handle efficiently. Different parts of the job need radically different expertise. One agent starts to feel like asking a single person to simultaneously design a product, write the code, run the tests, and handle customer support.

Multi-agent systems solve this by distributing the work. Each agent handles a narrow domain, and an orchestrator coordinates them. The result is a system that scales to genuinely complex tasks.

When to Split Into Multiple Agents

The decision to add a second agent should be driven by a real constraint, not by over-engineering. Split when you hit one of these three situations.

Context overflow. The task requires more tokens than a single model call can handle. A multi-agent system lets each agent work on a bounded piece and pass results to the next.

Parallelism. Independent subtasks can run at the same time. A research system might have three agents searching different data sources simultaneously, then a fourth agent synthesizing their outputs.

Specialization. Different subtasks benefit from different system prompts or tool access. A code reviewer agent and a documentation writer agent should not share a system prompt.

The Orchestrator-Worker Pattern

The most reliable multi-agent architecture is the orchestrator-worker pattern. One orchestrator agent receives the high-level task. It breaks the task into subtasks and assigns each to a specialist worker agent. The workers execute their subtasks and return results. The orchestrator synthesizes the results into a final output.

Building It in LangGraph

In LangGraph, the supervisor node calls the orchestrator model and routes the result to the appropriate worker node. Each worker node runs its specialized logic and returns results to a shared state.

from typing import TypedDict
from langgraph.graph import StateGraph, END
from langchain_anthropic import ChatAnthropic
from langchain_core.messages import HumanMessage, SystemMessage

model = ChatAnthropic(model='claude-3-5-sonnet-20241022')

class MultiAgentState(TypedDict):
    task: str
    research: str
    analysis: str
    report: str
    next: str

def supervisor(state: MultiAgentState) -> dict:
    if not state['research']:
        return {'next': 'researcher'}
    if not state['analysis']:
        return {'next': 'analyst'}
    if not state['report']:
        return {'next': 'writer'}
    return {'next': 'FINISH'}

def researcher(state: MultiAgentState) -> dict:
    response = model.invoke([
        SystemMessage(content='You are a research specialist. Find key facts about the given topic.'),
        HumanMessage(content=state['task'])
    ])
    return {'research': response.content}

def analyst(state: MultiAgentState) -> dict:
    response = model.invoke([
        SystemMessage(content='You are a data analyst. Identify patterns and key insights.'),
        HumanMessage(content=f'Analyze this research: {state["research"]}')
    ])
    return {'analysis': response.content}

def writer(state: MultiAgentState) -> dict:
    response = model.invoke([
        SystemMessage(content='You are a technical writer. Produce a clear, structured report.'),
        HumanMessage(content=f'Write a report. Research: {state["research"]} Analysis: {state["analysis"]}')
    ])
    return {'report': response.content}

graph = StateGraph(MultiAgentState)
for name, fn in [('supervisor', supervisor), ('researcher', researcher), ('analyst', analyst), ('writer', writer)]:
    graph.add_node(name, fn)

graph.set_entry_point('supervisor')
graph.add_conditional_edges(
    'supervisor',
    lambda s: s['next'],
    {'researcher': 'researcher', 'analyst': 'analyst', 'writer': 'writer', 'FINISH': END}
)
for worker in ['researcher', 'analyst', 'writer']:
    graph.add_edge(worker, 'supervisor')

app = graph.compile()

Pitfalls to Avoid

The biggest mistake in multi-agent systems is over-orchestration. If the orchestrator needs a dozen routing decisions for a task that could be done in one chain, you have added complexity without benefit. Start with one agent, add a second only when a specific constraint forces you, and never add a third until the second is proven out.

Keep your shared state schema tight. A bloated state object with dozens of fields becomes hard to reason about. Each agent should read only the fields it needs and write only the fields it produces.