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

Every agent so far in this series has had one job and a handful of tools. Real workflows are rarely that clean — "research this topic, then write a summary" is really two different skills wearing one trench coat. Multi-agent systems are the answer, and the core idea is simpler than the name suggests: instead of one agent trying to do everything, you split the work across a few focused agents that hand off to each other.

Why one giant agent tends to struggle

Give a single Claude agent thirty tools and a system prompt covering research, writing, fact-checking, and formatting, and something predictable happens: it gets worse at all four, not better at each. Long, sprawling instructions dilute focus, and a huge tool list makes it more likely Claude picks the wrong one. The fix isn't a cleverer prompt — it's fewer responsibilities per agent.

The pattern: an orchestrator and specialists

The most common shape is one orchestrator agent that breaks a task apart and calls specialist agents — each with a narrow job and a small, focused toolset — then combines what comes back.

import anthropic
 
client = anthropic.Anthropic()
 
def researcher_agent(topic: str) -> str:
    """Specialist: gathers information. Nothing else."""
    response = client.messages.create(
        model="claude-sonnet-5",
        max_tokens=1024,
        system="You are a research specialist. Given a topic, return the 3-5 most important facts, plainly stated, with no framing or commentary.",
        messages=[{"role": "user", "content": topic}],
    )
    return response.content[0].text
 
 
def writer_agent(topic: str, research: str) -> str:
    """Specialist: turns research into readable prose. Nothing else."""
    response = client.messages.create(
        model="claude-sonnet-5",
        max_tokens=1024,
        system="You are a writing specialist. Turn the given research notes into a clear, engaging paragraph. Do not add facts that aren't in the research.",
        messages=[{
            "role": "user",
            "content": f"Topic: {topic}\n\nResearch notes:\n{research}\n\nWrite the paragraph.",
        }],
    )
    return response.content[0].text
 
 
def orchestrator(topic: str) -> str:
    """Coordinates the specialists. Doesn't do the work itself."""
    research = researcher_agent(topic)
    article = writer_agent(topic, research)
    return article

Three Claude calls, three narrow jobs. The researcher never has to think about prose style. The writer never has to think about what's true. The orchestrator never has to be good at either — it just sequences the handoff.

Letting the orchestrator actually decide, not just sequence

The version above always runs research, then writing, in that fixed order. A more capable orchestrator treats the specialists as tools themselves, and decides dynamically which ones to call and in what order — using exactly the tool-use loop from earlier in this series, just with other agents as the "tools":

specialist_tools = [
    {
        "name": "researcher_agent",
        "description": "Gathers factual information on a topic. Use when you need up-to-date facts before writing.",
        "input_schema": {
            "type": "object",
            "properties": {"topic": {"type": "string"}},
            "required": ["topic"],
        },
    },
    {
        "name": "writer_agent",
        "description": "Turns research notes into polished prose. Use only after research is gathered.",
        "input_schema": {
            "type": "object",
            "properties": {"topic": {"type": "string"}, "research": {"type": "string"}},
            "required": ["topic", "research"],
        },
    },
]

Run this through the agent loop from post #5, and the orchestrator itself decides: research first, maybe research again if the first pass looked thin, then write. That decision-making is exactly what makes it a multi-agent system rather than just a fixed pipeline with extra steps.

When this is worth the extra complexity

Multi-agent setups cost more — more API calls, more latency, more moving parts to debug. They're worth it when:

• The task genuinely has distinct skill boundaries (research vs. writing vs. fact-checking are different jobs, not different phrasings of one job).
• A single agent's tool list has grown large enough that it's visibly picking the wrong tool sometimes.
• You want to swap out one piece independently — a better fact-checker, without touching the writer.

They're not worth it for a task simple enough that one agent with three tools handles cleanly. Splitting things apart that don't need to be split just adds latency and failure points for no real gain.

Reference links

• Claude tool use overview (the same mechanism, applied to agents instead of functions): platform.claude.com/docs/en/agents-and-tools/tool-use/overview
• Claude Agent SDK (built-in support for subagents and orchestration): platform.claude.com/docs/en/agent-sdk/overview
• Anthropic's engineering write-up on multi-agent research systems: anthropic.com/engineering

Next in this series: "RAG + Agents — The Difference Nobody Explains Well."