Multi-Agent Systems

The urge to add another agent is strong and usually wrong. Multi-agent designs solve real problems, parallel work and separation of concerns, but they multiply cost and add coordination failures a single agent never has.

Orchestrator and workers

The most useful pattern is orchestrator and workers. A lead agent splits a task into independent sub-tasks, sends each to a worker (usually a fresh agent with its own tools and a clean context), and combines the results. It works well when sub-tasks don't depend on each other, as in "research these five companies": five workers, each with a focused context, running at the same time.

What it buys and what it costs

Parallelism. Five independent research tasks run together finish in about the time of the slowest one. A single agent visiting five sources one after another might take 40 seconds; five workers might take 10.

Focus. Each worker gets a small, clean context for its own sub-task, avoiding the bloat of one giant conversation.

Many more tokens. Every worker has its own system prompt, tool definitions and loop. Anthropic has reported that its multi-agent research system used about 15 times the tokens of a normal chat, once all the workers' contexts and the coordination are counted. It's an investment for tasks valuable enough to justify that bill.

Coordination failures. Workers can duplicate each other, make conflicting assumptions or return results the orchestrator can't reconcile. A single agent doesn't have these problems.

Handoffs are where it breaks

Multi-agent reliability depends on the interfaces. A worker that returns a page of prose forces the orchestrator to reread and often redo work. Define what each worker returns as a structured record, for example {company, revenue, source_url, confidence}, the same discipline as tool design. Structured handoffs merge cleanly; prose handoffs spend a large share of the budget on agents rereading each other.

Most tasks people reach for multi-agent on are better served by one agent with good tools, or by a workflow. Start with one agent and move to several only when a real need for parallelism or isolation shows up and the budget allows 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