Multi-Agent Systems & Orchestration

1. When Multi-Agent Is the Wrong Answer

Start from the position that you are not building a multi-agent system, and make the scenario prove otherwise. The costs are concrete and they are paid on every run:

• Coordination overhead. A manager that delegates must serialize a brief, wait, receive, and reconcile. That is latency and complexity that a single loop never pays.
• Token duplication. Each agent carries its own instructions, its own copy of shared context, its own tool schemas. Five agents reading the same corpus can pay for that corpus five times.
• An unreconstructable audit trail. One agent produces one linear transcript. Five agents produce five interleaved ones, and the reason a wrong output reached production may live in a subagent transcript the parent never saw.

Against those costs there is exactly one bar, and both halves are legitimate on their own:

If a scenario satisfies neither, the answer is a single agent, possibly a workflow around a single agent (Lab 1), but not a second reasoning loop.

2. Orchestration Topologies

When multi-agent is warranted, the shape matters more than the count. Five topologies cover the exam, arranged from cheapest to most elaborate. Choose the simplest one that satisfies the requirement, and be able to name each one's failure mode; that is what the items test.

3. Context Isolation Is the Killer Feature

The strongest architectural reason to use a subagent is not speed. It is that a subagent can read forty files and return a two-hundred-token finding, and the parent never carries the forty files. The parent's context window stays clean; it holds the finding, not the evidence.

This is why isolation beats parallelism as a justification. Parallelism saves wall-clock time. Isolation changes what is possible: it lets a bounded parent reason over a corpus far larger than its own context window, one distilled finding at a time. A single agent that tried to read those forty files itself would blow its window and degrade long before it reached a conclusion.

Explicit context passing — the #1 multi-agent bug

Here is the failure that every orchestrator–worker design must design against: a subagent does not inherit the parent's conversation. It starts with an empty context. Everything it needs (the constraint, the schema, the definition of done, the thing the parent learned three turns ago) must be written into the delegation prompt. The most common multi-agent bug is a subagent that produces a confident, well-formed answer while missing the one constraint the parent knew and forgot to pass.

So the delegation brief is not a convenience; it is the interface contract. Make it self-contained on purpose.

import anthropic

client = anthropic.Anthropic()

def delegate(subtask: str, *, corpus: str, constraints: list[str],
             output_contract: str) -> str:
    """Dispatch a self-contained brief to a worker.

    The worker inherits NOTHING from the manager's conversation. Every
    constraint the manager knows must be written into this prompt, or the
    worker will confidently answer the wrong question.
    """
    brief = (
        f"TASK: {subtask}\n\n"
        f"CONSTRAINTS (all must hold):\n"
        + "\n".join(f"- {c}" for c in constraints)
        + f"\n\nRETURN EXACTLY: {output_contract}\n"
        "Return only the finding. Do not echo the corpus back."
    )

    response = client.messages.create(
        model="claude-haiku-4-5",          # a worker; cheaper than the manager
        max_tokens=1024,
        thinking={"type": "adaptive"},
        output_config={"effort": "low"},   # scoped subtask, terse output
        system=[
            # The 40-file corpus lives ONLY in the worker's context, never
            # the manager's. This is the isolation the split exists to buy.
            {"type": "text", "text": corpus,
             "cache_control": {"type": "ephemeral"}},
        ],
        messages=[{"role": "user", "content": brief}],
    )
    return next(b.text for b in response.content if b.type == "text")

Three things are load-bearing in that call. The corpus sits in the worker's system block, so it never enters the manager's window; that is the isolation. The brief names the constraints explicitly, because the worker cannot see the conversation that established them. And the worker runs a cheaper model at effort: "low", because a scoped subtask with a clear contract does not need the manager's horsepower (Lab 3 covers routing by difficulty).

4. Managing Context Across a Long-Running Agent

Even a single long-running agent has a multi-agent problem in miniature: its context window fills with old tool results it no longer needs. Two server-side mechanisms manage this, and the exam wants you to know they are different tools for different jobs.

Both are configured through context_management.edits on the beta Messages endpoint. There is one rule that catches everyone, and it is a favourite item: when a compaction or context-management response comes back, you append the full response.content to your message history, not just the text block. The compaction block is part of that content, and the API uses it to replace the compacted history on the next turn. Extract only the text and you silently discard the compaction state; the next request re-sends the full uncompacted history and the feature does nothing.

import anthropic

client = anthropic.Anthropic()
messages: list[dict] = []

def turn(user_text: str) -> str:
    messages.append({"role": "user", "content": user_text})

    response = client.beta.messages.create(
        model="claude-opus-4-8",
        max_tokens=4096,
        betas=["compact-2026-01-12"],
        context_management={"edits": [{"type": "compact_20260112"}]},
        messages=messages,
    )

    # CRITICAL: append the FULL response.content, not just the text.
    # The compaction block lives in .content and carries the state the API
    # needs to replace compacted history next turn. Appending only the text
    # string silently discards it and the compaction never takes effect.
    messages.append({"role": "assistant", "content": response.content})

    return next(b.text for b in response.content if b.type == "text")

To clear stale tool results instead of summarizing, swap the edit and the beta:

response = client.beta.messages.create(
    model="claude-opus-4-8",
    max_tokens=4096,
    betas=["context-management-2025-06-27"],
    context_management={
        "edits": [{"type": "clear_tool_uses_20250919"}]
    },
    tools=tools,
    messages=messages,
)
# Context editing deletes old tool results. It is cheap and lossy about
# specifics. Use it when those results no longer matter; reach for
# compaction (above) when the conversation's meaning must survive.

5. Coordination Failure Modes

Multi-agent systems fail in a small, recognizable set of ways. The exam describes the symptom and asks you to name the cause, and, usually, the fix.

The last row is where cost architecture meets orchestration. When a fan-out shares a large corpus, put that corpus at the start of a stable prefix with a cache breakpoint. The first worker pays the write (1.25× for the 5-minute TTL); the rest read it at roughly a tenth of input price. Reorder or mutate that prefix per worker and you invalidate the cache for all of them, the same prefix-match discipline as Lab 3, applied across agents instead of across turns.

6. Decomposition Seams

Lab 1 established the rule: decompose along the seams where verification is possible: verifiability, trust, cost, context, and latency. Multi-agent is where two of those seams become physical.

The two seams that justify a second reasoning loop are context and latency, the same two halves of the bar from §1. Verifiability and cost seams are more often served by a workflow around a single agent than by multiple agents. If you cannot name the context seam or the latency seam a split sits on, you are looking at a diagram, not a decomposition.

7. Design Exercise

Objective: decide single-agent versus orchestrator–worker for a concrete system, and (if you split) write the delegation brief. About 45 minutes. This is the decision the exam tests; the brief is where most designs quietly fail.

Scenario. A litigation team runs discovery over 200,000 documents: emails, contracts, scanned PDFs. For a given matter they need every document responsive to a set of legal criteria, each flagged with the criterion it matches and a one-line justification a paralegal can verify. A privileged document that is accidentally produced is a serious, sometimes sanctionable, event. Turnaround is measured in hours, not seconds. The corpus does not fit in a single context window.

1. Run the §1 bar first. Is this parallelizable? Is there a context-isolation reason? Write one sentence for each half before you choose anything. Do not proceed until you can say why a single agent cannot hold this, and "200,000 documents exceed one context window" is a real answer, not a hand-wave.
2. Reject the naive single agent explicitly. Say the sentence: "One agent cannot do this because ___." If your reason is only "it would be slow," you have not found the isolation seam; look again.
3. Choose the topology and justify it against the alternatives. Orchestrator–worker (a manager fans out document batches to workers, each worker returns responsive hits) versus a flat parallel fan-out. Which failure mode from §5 are you most exposed to, and how does your topology contain it?
4. Write the worker's delegation brief. A worker sees one batch and nothing else. Enumerate exactly what must be in that prompt: the legal criteria, the definition of "responsive," the output contract (document ID, matched criterion, justification), and, critically, the privilege rule. What happens if the privilege constraint is the one the manager forgets to pass?
5. Handle the privileged-document blast radius. A model flag is not a privilege determination. Where is the human gate, and does it sit on every produced document or only the ambiguous ones? Tie this back to Lab 1's egress plane.
6. Defend the cost. 200,000 documents across N workers. What is the shared prefix (the criteria, the instructions), where does the cache breakpoint go, and roughly what does caching save versus each worker reloading the criteria cold? State the number you would put in front of the partner who signs the discovery bill.

Step 4 is the one the exam tests. Step 5 is the one that keeps the firm out of a sanctions hearing.

Key Takeaways

• The default is one agent. A second reasoning loop needs genuine parallelism or context isolation, and isolation is the stronger justification.
• Multi-agent's costs are real and paid every run: coordination overhead, token duplication, and an audit trail no one can reconstruct.
• Pick the flattest topology that expresses the work. Orchestrator–worker beats hierarchical almost every time; know each topology's signature failure mode.
• Context isolation lets a subagent read forty files and return a 200-token finding the parent never carries, the single strongest reason to use subagents.
• A subagent inherits nothing. Every constraint the parent knows must be in the delegation brief; the lost-constraint bug is the #1 multi-agent failure.
• Context editing prunes, compaction summarizes. clear_tool_uses_20250919 deletes stale tool results cheaply; compact_20260112 preserves the gist. When either returns, append the full response.content, not just the text.
• Coordination fails in five named ways: duplicated work, conflicting writes, lost constraint, infinite delegation, cost blowup. Fix the cost blowup by caching the shared prefix so N workers read it at ≈0.1×.
• Multi-agent is the context seam plus the latency seam. If a split sits on neither, it is a diagram, not a decomposition.