Multi-Agent Systems

The instinct to "add another agent" is strong and usually wrong. Multi-agent architectures solve real problems — parallelism and separation of concerns — but they multiply cost and introduce coordination failures a single agent never has. Know exactly what you're buying before you buy it.

The most useful pattern is orchestrator–worker: a lead agent breaks a task into independent sub-tasks and dispatches each to a worker (often a fresh agent with its own tools and clean context), then synthesizes the results. It shines when sub-tasks are genuinely independent and benefit from isolation — e.g. "research these 5 companies" becomes 5 parallel workers, each with a focused context, run concurrently.

What multi-agent actually buys — and costs

Buys: parallelism. Five independent research sub-tasks run concurrently finish in roughly the time of the slowest one, not the sum. On a task where a single agent would serially visit 5 sources over ~40 seconds, an orchestrator with 5 workers can finish in ~10 — a real latency win when the work is parallelizable.

Buys: focus. Each worker gets a clean, small context scoped to its sub-task, sidestepping the bloat and lost-in-the-middle problems of one giant conversation.

Costs: tokens, multiplied. Every worker is its own agent with its own system prompt, tool definitions, and loop. Anthropic's own reporting on multi-agent research systems put token use at roughly 15× a single chat — because you're paying for several agents' full contexts plus the orchestrator's coordination overhead. Multi-agent is a performance investment you make when the task value justifies a large token bill, not a default.

Costs: coordination failure. Workers can duplicate work, make contradictory assumptions, or hand back results the orchestrator can't reconcile. These are failure modes a single agent simply doesn't have.

The handoff is where it breaks

Multi-agent reliability lives in the interfaces. A worker returning a wall of unstructured prose forces the orchestrator to re-parse and often re-do work. The fix is the same discipline as tool design: define a structured contract for what a worker returns — a typed result object, not free text. Orchestrator–worker systems that use structured handoffs (each worker returns, say, a {company, revenue, source_url, confidence} record) reconcile cleanly; those that pass prose spend a chunk of their token budget just re-reading each other.

The honest default

Most tasks people reach for multi-agent on are better served by a single agent with good tools, or a workflow. Multi-agent earns its keep on a specific shape of problem — wide, parallel, independent — and is a liability everywhere else. Start single; graduate to multi only when a real parallelism or isolation need appears and the budget supports it.

Starter code

import time, concurrent.futures as cf

ITEMS = ["co A","co B","co C","co D","co E"]
WORKER_TOKENS = 1200        # each worker: own sys prompt + tools + loop
ORCH_TOKENS   = 1500        # orchestrator overhead

def research(item):
    time.sleep(0.3)          # simulate a ~0.3s tool+model round-trip
    return f"{item}: revenue $X"

def serial():
    t0 = time.time()
    for it in ITEMS: research(it)
    # one shared context grows, but it's a single agent: ~one worker's tokens
    return time.time()-t0, WORKER_TOKENS

def parallel():
    t0 = time.time()
    with cf.ThreadPoolExecutor() as ex:
        list(ex.map(research, ITEMS))
    tokens = ORCH_TOKENS + WORKER_TOKENS*len(ITEMS)   # each worker pays full freight
    return time.time()-t0, tokens

# TODO: print both (time, tokens) and compare.

st, stok = serial()
pt, ptok = parallel()
print(f"serial   {st:.1f}s  {stok} tok")
print(f"parallel {pt:.1f}s  {ptok} tok")
# => serial   1.5s  1200 tok
#    parallel 0.3s  7500 tok