Multi-agent systems are having a moment. Every framework has a multi-agent story. Every conference talk shows an elaborate pipeline of specialised agents working in concert. The impression is that multi-agent is simply better than single-agent. It is not.
Multi-agent is a specific architectural choice that makes sense for specific problems. Used carelessly it adds complexity, cost, and failure modes without a corresponding benefit.
What a Multi-Agent System Actually Is
A multi-agent system is two or more agents that communicate to complete a task. Communication can be:
- ▸Sequential: Agent A produces output, Agent B consumes it
- ▸Parallel: Multiple agents work simultaneously, results are merged
- ▸Hierarchical: A supervisor agent delegates tasks to worker agents
- ▸Collaborative: Agents review and critique each other's work
The key distinction from a chain or pipeline: each agent has its own context window, its own tools, and makes its own decisions about what to do next. They are not just functions — they are autonomous reasoners.
When Single Agent Is Enough
Most tasks that feel like they need multiple agents can be handled by one agent with well-defined tools.
A single agent can:
- ▸Use multiple tools in sequence or in any order it decides
- ▸Maintain conversation history across multiple steps
- ▸Self-critique and revise its own output if given an instruction to do so
- ▸Delegate sub-tasks by calling specialised tools (which can themselves call APIs, run code, search databases)
If your agent can complete the task within its context window, and its failure modes are acceptable, you do not need multiple agents.
The practical threshold: if a task takes more than 20-30 LLM calls in a single context, or requires information that cannot fit in one context window, consider multi-agent.
When Multi-Agent Wins
1. The task decomposes naturally into parallel workstreams
A market research task might involve simultaneously: searching for competitors, analysing pricing pages, reading product reviews, and checking job postings for technology signals. These are independent — one agent can do all four sequentially, but four parallel agents finish in one-quarter the time.
Supervisor Agent
├── Agent A: competitor search (web)
├── Agent B: pricing analysis (scraping)
├── Agent C: review sentiment (API)
└── Agent D: hiring signals (job boards)
→ Supervisor synthesises all four results
2. Specialisation genuinely helps
Different parts of a task benefit from different system prompts, tools, or even different models. A code generation agent needs different instructions than a code review agent. A creative writing agent should run at higher temperature than a fact-checking agent.
# LangGraph: different models for different roles writer = ChatOpenAI(model="gpt-4o", temperature=0.8) # creative reviewer = ChatOpenAI(model="gpt-4o", temperature=0.1) # precise fact_checker = ChatOpenAI(model="gpt-4o-mini", temperature=0) # fast, cheap
3. The task exceeds a single context window
Analysing a 200-page contract, processing a codebase, or researching a topic across hundreds of documents cannot fit in one context window. Multiple agents can each handle a subset, with a synthesiser combining their findings.
4. Quality improves through adversarial review
Having one agent generate a plan and a second agent critique it — before a third executes it — catches errors that a single agent misses in self-review. The different context (starting fresh, only seeing the output) changes what the reviewing agent notices.
The Real Costs
Latency: Each agent adds at least one LLM call. A 5-agent sequential pipeline that each take 3 seconds = 15 seconds minimum. Parallel execution helps but adds coordination complexity.
Cost: Multi-agent multiplies your token usage. A supervisor agent that summarises results for worker agents, then re-reads those summaries — you are paying for that context multiple times.
Debugging: When a single-agent system gives a wrong answer, you read one chain of reasoning. When a multi-agent system fails, the error could be in the supervisor's delegation, any worker's execution, or the synthesis step. Tracing is significantly harder.
Reliability: Each agent call can fail. With 5 agents, you have 5 failure points. Error handling, retries, and graceful degradation are more complex.
The Decision Framework
Does the task naturally split into parallel independent workstreams?
Yes → Multi-agent (parallel execution pattern)
No → Single agent
Does the task exceed the context window of a single agent?
Yes → Multi-agent (divide and conquer)
No → Single agent
Does quality require adversarial review (generate + critique)?
Yes → Two agents (generator + reviewer)
No → Single agent with self-review instruction
Do different parts of the task need meaningfully different model configs?
Yes → Multi-agent with specialised configs
No → Single agent with different tools
Starting Point in Code
If you decide multi-agent is warranted, LangGraph is the cleanest framework for it:
from langgraph.graph import StateGraph, END from typing import TypedDict, List class ResearchState(TypedDict): query: str web_results: str wiki_results: str final_answer: str def web_search_agent(state: ResearchState) -> ResearchState: # searches web, returns results return {"web_results": search(state["query"])} def wiki_agent(state: ResearchState) -> ResearchState: # searches Wikipedia, returns results return {"wiki_results": wiki_lookup(state["query"])} def synthesis_agent(state: ResearchState) -> ResearchState: # combines both results into final answer context = state["web_results"] + "\n" + state["wiki_results"] return {"final_answer": synthesise(context, state["query"])} # Build the graph graph = StateGraph(ResearchState) graph.add_node("web_search", web_search_agent) graph.add_node("wiki", wiki_agent) graph.add_node("synthesise", synthesis_agent) graph.set_entry_point("web_search") graph.add_edge("web_search", "wiki") # sequential graph.add_edge("wiki", "synthesise") graph.add_edge("synthesise", END) app = graph.compile() result = app.invoke({"query": "What is LangGraph used for?"})
The Bottom Line
Single agent is simpler, cheaper, and easier to debug. It is the right default. Reach for multi-agent when you have a concrete reason: parallel workloads, context limits, genuine specialisation, or adversarial quality improvement.
The best multi-agent systems feel inevitable — the task could not be done well any other way. If you cannot articulate why multiple agents are necessary, you probably do not need them yet.