Multi-agent systems

The December numbers came in on the second of January, and one line was red. Five of Crumb’s six stores had grown their online sales over Christmas, between 8% and 22%. Koregaon Park had fallen 18%. Meera wanted to know why before Monday’s meeting with the store manager, and she didn’t want a guess.

The answer could be hiding almost anywhere. In the order database (were orders failing?). In 3,100 customer reviews and support emails (were people angry about something?). In the delivery partner’s logs (were deliveries late?). Or outside Crumb entirely (had a competitor opened next door?).

Arjun knew one agent with all the right tools could investigate. He gave it the database tool, a review search tool, a delivery log tool and web search, and asked it the question. Thirty-four steps later, it was reading its 900th review. Its conversation had grown to about 180,000 tokens. It answered: “The decline is most likely due to increased competition in the area.” The evidence it cited was the last web page it had read. It had seen the delivery logs at step 9, and by step 34 they were buried under a mountain of reviews. Because each of those 34 steps re-read the whole growing conversation, that run read over two million tokens in total. It cost about $9, roughly ₹800, and took eight minutes.

Arjun’s second attempt: the committee

“The problem is it’s one agent doing four jobs,” Arjun said. “So I’ll make four agents.” He created a Data Analyst, a Review Reader, a Delivery Investigator and a Market Researcher, put them in one shared conversation, and told them to discuss until they agreed.

It was eighty messages long. The Review Reader posted a list of complaints. The Data Analyst replied, “Great insight! Building on that…” and repeated half of it. The Market Researcher found the competitor’s page and everyone agreed it was important. Twice they decided to “summarise the findings so far”, producing summaries of summaries. Nobody owned the final answer, so nobody wrote it. Arjun stopped it at ₹140.

He showed Priya both logs. “One agent drowns. Four agents chat.”

The newsroom

“Have you ever seen how a newspaper investigates a story?” Priya asked.

“Not really.”

“There’s an editor. She gets the big question: why did this company collapse? She doesn’t read every document herself. She splits the question into beats and assigns a reporter to each. You take the financial filings. You talk to former employees. You check the court records. Each reporter disappears for a day, reads hundreds of pages, and comes back with what?”

“Their notes?”

“A one-page memo. The editor never sees the hundreds of pages. She reads four one-page memos, notices that two of them point at the same thing, maybe sends one reporter back with a follow-up, and writes the story. There’s also a board on the newsroom wall with the key facts everyone needs: names, dates, numbers. Now, why did your single agent fail?”

“It was the editor and all four reporters, reading everything into one head.”

“And the committee?”

Arjun winced. “Four reporters, no editor. And no memos, just everyone talking at once.”

“That’s the whole design. An orchestrator (the editor) splits the work and owns the final answer. Specialists (the reporters) each work in their own, separate context, with only the tools for their beat, and return a short memo. A shared board holds the few facts everyone needs. The magic isn’t that there are more agents. It’s that each one only has to hold a small, focused part of the problem.”

Where the analogy breaks: human reporters remember yesterday’s conversation and notice when a colleague is wrong. Agents don’t, unless you build that in. A specialist that misreads the data will write a confident memo, and the orchestrator has no way to know, except by cross-checking memos against each other. Also, newspapers don’t pay per word read. You do.

Following the investigation, end to end

Here is the Koregaon Park question, run through a three-specialist system. Every number below comes from one real-feeling run.

Step 1: the orchestrator plans. It reads the question and the list of available specialists, and calls its delegate tool three times with self-contained briefs:

delegate("sales_analyst", "Compare Koregaon Park's online orders in Dec vs Nov, and vs the other
  five stores. Look at order counts, failed or cancelled orders, average basket, and which
  products dropped. Period: 1 Nov to 31 Dec. Return a memo under 250 words with numbers.")

delegate("review_reader", "Read reviews and support emails mentioning Koregaon Park from
  1 Nov to 31 Dec. What are customers unhappy about, and how often? Return top themes
  with counts and two short quotes each, under 250 words.")

delegate("delivery_investigator", "Check delivery partner logs for Koregaon Park, Nov vs Dec:
  on-time rate, cancellations, average delay. Compare with the other stores. Under 250 words.")

Notice what each brief contains: the question, the time period, the store, what to compare, and the shape of the answer. A specialist starts with an empty context. Everything it needs must be in the brief.

Step 2: the specialists work, separately.

Specialist	Steps	Tokens read (all its steps)	Memo
Sales analyst	7	~38,000	Orders down 18%; cancellations up from 2% to 11%, mostly 15–24 Dec; average basket unchanged
Review reader	12	~96,000	142 complaints mention “cancelled” or “never arrived” (up from 9 in Nov); “lovely cake, shame about delivery”
Delivery investigator	5	~21,000	On-time rate fell from 94% to 61% from 14 Dec; new partner zone excluded parts of Koregaon Park

Each specialist also posts one or two facts to the shared board, so the others can see them while they work:

[sales_analyst]          Cancellations at KP: 2% Nov -> 11% Dec, spike 15-24 Dec.
[delivery_investigator]  Partner changed delivery zones on 14 Dec; KP lanes north of the
                         main road now 'out of zone'.

The review reader, which was still working, read the board, searched specifically for “out of zone” and “can’t deliver”, and found 61 more complaints it would otherwise have filed under “general”.

Step 3: the orchestrator synthesises. It reads three memos, about 750 words in total, instead of 155,000 tokens of raw material. It notices all three point to the same date, 14 December, and writes:

“Koregaon Park’s December fall was caused by delivery, not demand. On 14 Dec our delivery partner redrew its zones, putting part of Koregaon Park ‘out of zone’. On-time delivery fell from 94% to 61% and cancellations rose from 2% to 11%. 203 customer complaints mention cancellations or undeliverable addresses. Average basket size was unchanged, and no competitor evidence explains the timing. Recommend: restore the zone with the partner, and contact the 200-odd affected customers.”

The bill: about 175,000 input tokens across all agents and 9,000 output tokens. At $4and$20 per million, roughly $0.88, about ₹78, a tenth of what the drowning single agent cost. Because the three specialists ran at the same time, it took about three minutes instead of eight. And it was right.

Don’t take the wrong lesson from that. The team was cheaper only because the single agent was badly designed: it let its context balloon. Compared with a well-designed single agent (one that keeps its context small by summarising and returning only what it needs), expect a multi-agent system to cost several times more. Anthropic reported that its multi-agent research system used roughly fifteen times the tokens of an ordinary chat. That is the price of reading widely.

Show the answer

Detail and nuance are lost, and so is the ability to check. If the review reader misread “cancelled” complaints as being about a different store, the orchestrator would never know: it only sees the memo. This is the “telephone game” problem. Protections: ask specialists to include numbers and short verbatim quotes with sources (so claims can be spot-checked); cross-check memos against each other (all three agreed on 14 December, which is strong evidence); and let the orchestrator send a specialist back with a follow-up question when something doesn’t add up.

Opening the hood: why split, and how to coordinate

Three reasons to use several agents

1. Context isolation. Each specialist gets a fresh context window (the text a model can see in one request). The review reader can read 96,000 tokens of reviews without polluting the sales analyst’s view. Each one stays focused. This is the biggest win, and the reason the single agent failed.
2. Specialisation. Each specialist has its own instructions, its own small set of tools, and even its own model. The delivery investigator only needs a simple log tool; a cheaper, faster model might do its job well.
3. Parallelism. Independent specialists run at the same time. Three minutes instead of eight.

Three reasons not to

1. Cost. More agents, more tokens. Several times a single agent is normal.
2. Coordination failures. Duplicated work, information lost in memos, agents that agree with each other too readily (models tend towards politeness, as the committee showed).
3. Debugging. Several conversations instead of one. Without good logging, you can’t tell which agent introduced an error.

So multi-agent systems suit tasks that are broad (many independent threads to pull), read-heavy (lots of material to digest) and valuable enough to justify the cost. Research and investigation fit perfectly. Writing one email does not. Tightly linked tasks where every step depends on the last, like editing one piece of code, usually work better with a single agent.

Three ways to wire agents together

flowchart TD
  U["Question"] --> O["Orchestrator"]
  O -->|"brief"| A["Sales analyst"]
  O -->|"brief"| B["Review reader"]
  O -->|"brief"| C["Delivery investigator"]
  A -->|"memo"| O
  B -->|"memo"| O
  C -->|"memo"| O
  A <--> Board["Shared board"]
  B <--> Board
  C <--> Board

• Orchestrator (supervisor). One agent plans, delegates and synthesises, as above. The most common and easiest to control. It is the orchestrator-workers pattern from the last lesson, where each worker is now a full agent with its own loop.
• Handoff. One agent passes the whole conversation to another and steps back. A triage agent hands an allergy question to the allergy specialist, which then talks to the customer directly. Good for customer-facing routing; you’ll see it in agent SDKs in Module 18.
• Group chat. Agents take turns in one shared conversation, with rules about who speaks next and when to stop. It can work for debate and review, but as Arjun’s committee showed, it needs firm structure. You’ll meet frameworks built around it in the next lesson.

Memory in a team

“Memory” means three different things here, and mixing them up causes bugs:

• Working memory: each agent’s own context. Private, temporary, gone when the agent finishes.
• Shared memory: the board. A small store of verified facts any agent can read and write during the task. Keep it short and factual; it is not a chat room.
• Long-term memory: what the system remembers next time (for example, “the delivery partner changed zones once before, in June”). That is the subject of Module 15.

Show the answer

Because every agent reads the board, so everything on it is copied into every context. Full conversations would recreate the single-agent problem: huge, noisy contexts. Short facts, each tagged with who posted it, give other agents exactly the cross-cutting knowledge they need (like the 14 December zone change) at a tiny cost. A good board is like the newsroom wall: names, dates, numbers, not drafts.

Building a small team

This version uses only the Anthropic SDK’s tool runner from Your first agent, so there is no framework magic. The data tools (query_orders, search_reviews, delivery_stats) are stand-ins for the safe tools you built in earlier lessons.

Step 1: the shared board

# team.py
import anthropic
from anthropic import beta_tool
from dotenv import load_dotenv

load_dotenv()
client = anthropic.Anthropic()

BOARD: list[str] = []   # shared memory for ONE investigation; reset for the next

@beta_tool
def post_note(author: str, fact: str) -> str:
    """Add one short, verified fact to the team's shared board (under 30 words).

    Args:
        author: Your specialist name.
        fact: One fact with a number and a date or period. No opinions.
    """
    BOARD.append(f"[{author}] {fact[:200]}")
    return "Posted."

@beta_tool
def read_notes() -> str:
    """Read the facts other specialists have posted so far."""
    return "\n".join(BOARD) or "The board is empty."

Step 2: specialists, each with its own context and tools

MEMO_RULES = ("You are one specialist on an investigation team. Work only on your brief. "
              "Read the shared board early. Post key facts with numbers to the board. "
              "Finish with a memo under 250 words: findings, numbers, 2 short quotes or sources.")

SPECIALISTS = {
    "sales_analyst": {"system": "You analyse Crumb's order data. " + MEMO_RULES,
                      "tools": [describe_tables, query_orders]},
    "review_reader": {"system": "You read customer reviews and support emails. " + MEMO_RULES,
                      "tools": [search_reviews]},
    "delivery_investigator": {"system": "You analyse delivery partner logs. " + MEMO_RULES,
                              "tools": [delivery_stats]},
}

def run_specialist(name: str, brief: str, max_turns: int = 15) -> str:
    spec = SPECIALISTS[name]
    runner = client.beta.messages.tool_runner(
        model="claude-opus-5-5",
        max_tokens=4000,
        system=spec["system"],
        tools=spec["tools"] + [post_note, read_notes],
        messages=[{"role": "user", "content": brief}],   # a FRESH context: only the brief
    )
    last = None
    for turn, message in enumerate(runner):
        last = message
        if turn + 1 >= max_turns:                        # brakes for every specialist
            break
    text = "".join(b.text for b in last.content if b.type == "text") if last else ""
    return text or f"{name} did not finish within {max_turns} turns."

The line that matters most is messages=[{"role": "user", "content": brief}]. Each specialist starts from nothing but its brief. That is context isolation, in one line.

Step 3: the orchestrator delegates through a tool

@beta_tool
def delegate(specialist: str, brief: str) -> str:
    """Give one self-contained task to a specialist and get back their memo.

    Args:
        specialist: One of sales_analyst, review_reader, delivery_investigator.
        brief: Everything they need: the question, store, time period, comparisons, memo format.
    """
    if specialist not in SPECIALISTS:
        return f"Unknown specialist. Choose from {list(SPECIALISTS)}."
    print(f"-> delegating to {specialist}")
    return run_specialist(specialist, brief)

ORCHESTRATOR = ("You lead an investigation for Crumb & Co. Split the question into briefs for your "
                "specialists, delegate, then read their memos and the shared board. Cross-check "
                "claims between memos. If something doesn't add up, send a follow-up brief. "
                "Finish with a cause, the evidence with numbers, and a recommendation.")

def investigate(question: str) -> str:
    BOARD.clear()
    runner = client.beta.messages.tool_runner(
        model="claude-opus-5-5", max_tokens=4000, system=ORCHESTRATOR,
        tools=[delegate, read_notes],
        messages=[{"role": "user", "content": question}],
    )
    final = None
    for final in runner:
        pass
    return "".join(b.text for b in final.content if b.type == "text")

print(investigate("Why did Koregaon Park's online sales fall 18% in December while other stores grew?"))

When it runs, you should see three -> delegating to ... lines, a pause while the specialists work, and a final answer that cites numbers from the memos. This version runs specialists one after another. To run them in parallel, have the orchestrator’s tool calls dispatched to a thread pool, as in the parallelisation pattern; that’s a good exercise once the basic version works.

smolagents offers the same structure built in: give an agent a name and description, and pass it to another agent’s managed_agents list. Frameworks hide the plumbing; you now know what the plumbing is.

Where it breaks

The investigation team became Crumb’s go-to tool for “why did this number change?” questions. Over a month, Priya and Arjun kept a list of failures:

• Vague briefs, wasted work. Early on, the orchestrator wrote briefs like “look into sales”. The sales analyst spent fifteen turns exploring and returned a memo about the wrong period. The fix was in the orchestrator’s prompt: every brief must include the question, store, period, comparison and memo format. Most multi-agent failures are briefing failures.
• Duplicated effort. Two specialists both queried the order database for cancellations. Clear, non-overlapping beats fixed it.
• Too many agents for simple questions. “How many plum cakes did Baner sell yesterday?” spun up three specialists. The orchestrator now has a rule: if one tool call can answer it, answer directly.
• Cost spikes. One run delegated eleven times. A cap on delegations in code (not just in the prompt) followed the next day.
• Confident memos, wrong data. Once, the review reader double-counted complaints that appeared in both reviews and emails. Cross-checking caught it only because the sales analyst’s cancellation count was much lower. Specialists now report sources so counts can be audited.

Try it yourself

Use the structure above with two specialists and fake data you write yourself:

• menu_planner with a search_recipes(query) tool over a small dictionary of recipes.
• stock_checker with a check_stock(item) tool over a dictionary of stock levels.

Ask the orchestrator: “Propose three Diwali hampers that only use items in stock at all stores.” Then deliberately make one item out of stock and see whether the final answer avoids it.

Show the expected result

The orchestrator should brief the menu planner to propose candidates, then brief the stock checker with the specific items (or check the board, if the planner posted them). The final hampers should exclude the out-of-stock item. If they don’t, read the logs: usually the stock checker’s brief didn’t list all the items, or the orchestrator wrote its answer before the stock memo came back. Fix the orchestrator’s instructions (“never propose an item the stock checker hasn’t confirmed”) and run again. Notice that this task is small enough that one agent with both tools might do just as well, and more cheaply. That is worth checking too.

Common mistakes

• Going multi-agent too early. Try a single agent, then workflow patterns. Split only when one context can’t hold the work, or when parallel threads clearly help.
• Agents without an owner. Someone has to write the final answer. Group chats without an orchestrator or termination rule drift.
• Briefs that assume context. Specialists start empty. “Continue the analysis” means nothing to them. Write briefs like you’re emailing a contractor who has never heard of Crumb.
• Turning shared memory into a chat log. The board is for short facts. Long text on it bloats every agent’s context.
• No limits per agent. Every specialist needs a turn cap, and the orchestrator needs a delegation cap.

Recap

• A multi-agent system splits a task across specialists, each with its own context, tools and instructions, usually under an orchestrator that briefs them and synthesises their memos.
• The main win is context isolation: each agent holds a small, focused part of the problem. Specialisation and parallelism are bonuses.
• The main costs are tokens (several times a single agent), coordination failures and harder debugging.
• Coordinate with an orchestrator, handoffs or a carefully structured group chat. Share only short facts on a shared board.
• Good briefs and good memos (with numbers and sources) matter more than clever prompts.

On Monday, Arjun walked into the meeting with Meera and the Koregaon Park store manager. “It wasn’t demand,” he said. “On the 14th, our delivery partner redrew its zones and cut off half of Koregaon Park. On-time delivery fell from 94% to 61%. Three separate checks, one on orders, one on reviews and one on delivery logs, all point to the same date.” The store manager looked relieved. Meera looked furious, at the delivery partner.

After the meeting, Arjun asked Priya, “Should I have used a framework for this? Everyone online talks about CrewAI and AutoGen.”

“You’ve built a team by hand, so now you’ll understand what they’re doing for you,” she said. “Let’s look at both tomorrow, and see what they make easier and what they hide.”

Go deeper

• Building effective agents (Anthropic), on orchestrator-workers and when complexity pays off.
• smolagents documentation, for managed_agents.
• Anthropic documentation, for the tool runner.
• LangGraph documentation, which you’ll use in Module 14 to build supervised teams as explicit graphs.