Why Multi-Agent?

A multi-agent system is several policies that share one job, each with its own trace, its own allow-list, and its own definition of done. A policy is the rule that maps “what I see” to “what I may do next.” A trace is the log of that policy’s steps. An allow-list is the set of tools and paths that policy may touch. Done is a check you can run in code, not a vibe that the paragraph looks helpful.

That is not several marketing names around one prompt. It is not four system-prompt nicknames that all call the same search and the same finish. Two language-model calls do not make a society. They make a bill: tokens, hops, queues, and a new way to loop.

The Agents track already split router, specialist, and verifier as three functions in one runtime. One loop. One memory. One allow-list that the assembler could still advertise as a whole. This track starts when those specialists must talk as separate runtimes: different traces you can eval apart, different tools that must not sit in the same process, different stop checks that will not agree if you squash them into one “be helpful.”

Do not re-learn the single-agent loop here. You already have observe, act, stop. Multi-agent is when that one loop is the wrong machine — because the first agent’s context, tools, or incentives get in the way of the second job.

Honest reasons to split

Pay for a second agent only when isolation or parallelism buys something you can name.

Tool isolation. A coder with run_shell should not also hold refund_customer. If both names live on one allow-list, a confused thought can refund a customer while “fixing a timeout.” Separate policies mean separate dispatchers. The Tools track already rejected unknown names. Here the question is who is asking.

Context isolation. A 40-page research dump will drown a patch-writing model. Attention is a budget. The researcher’s job is to return a brief: a short, checkable object the coder can use. The coder sees the brief plus the repo — not the entire web, not the researcher’s chain of thought, not every dead-end query. If you paste the dump into the coder’s prompt, you did not split. You bought two invoices for one drowning.

Different success checks. The researcher is done when citations exist and the brief parses. The coder is done when tests pass. One agent “being helpful” will stop at the first pretty paragraph. That is not laziness. It is one stop predicate covering two jobs that do not share a predicate. If you cannot write two different checks, you do not have two roles.

Parallelism. Independent sub-questions can run as concurrent jobs: score 200 tickets, extract fields from 80 PDFs. That is a swarm later in this track, not a roundtable now. Parallelism is an honest reason only when the sub-tasks do not share a mutable file or a customer record. If they share writes, you have a race with extra names.

If none of those rows is true, keep one agent.

Dishonest reasons

These look like architecture. They are delay, fashion, or hope:

• The vendor slide had a “team of agents”
• You want to delay specifying the workflow (who speaks, what they return, when the job ends)
• You hope a critic persona will replace unit tests
• You like watching them talk
• You think more names mean more intelligence
• You copied a demo where four chatbots discussed a poem

Personas without different tools or different stop conditions are a more expensive single agent. Merge them. A nickname in a system prompt is not a security boundary and not a success check.

A critic that only says “looks good” is a random boolean you are paying tokens for. Tests, schemas, and citation ids are cheaper and repeatable. Debate, later in this track, is for high-stakes questions with a grounded judge — not for replacing pytest.

Walkthrough: job 17 timed out

Acme’s on-call ticket: “Job 17 failed talking to the vendor. Open a PR.” Two designs.

Single agent. One policy reads logs, edits the repo, finishes. That is legal if log tools and edit tools are safe together and the log dump fits the coder’s context and “done” is one check (tests green). Many tickets should stay here. The Agents track already taught that loop.

Split. A researcher may read_logs and summarize. It cannot edit. It returns a brief: timeout talking to vendor; recommend a timeout bump; citation log-17. A coder may edit and run_tests. It cannot read the raw log mountain. It sees the brief plus the repo. The researcher is done when the brief parses with a citation. The coder is done when tests pass.

The split earns its keep only if the raw logs would drown the coder, or if read_logs and edit must not share an allow-list. If the log is three lines and both tools are safe together, the split is a tax. Pay it only when the table above has a true row.

Run to execute this in your browser. Nothing is sent to a server.

What printed: SINGLE is one trace that both read the log string and produced a patch. MULTI names two roles, returns a short brief, still produces the same patch, and sets coder_saw_raw_logs to False. The coder never sees raw logs. That is the whole point of an honest split: smaller tools and smaller context, not a second hat.

Change the brief string and run again. The patch function in this toy does not read the brief. In a real split, the coder’s only log-shaped input is that brief. If you sneak the raw log into the coder prompt “for luck,” delete the researcher. You are back to one agent with two invoices.

What a split is not

A split is not “the model will collaborate.” Models do not form teams. Your runtime forms teams: parsers, allow-lists, orchestration, a store for the brief. If those are missing, you have a group chat. Group chats have no done-check.

A split is not automatic parallelism. Two agents in a conversation are usually serial: researcher then coder. Parallelism is a swarm of independent items, later. Do not spawn four personas to discuss one ticket unless you have a judge, a hop cap, and a reason a single sample fails.

A split is not a way to skip specifying the workflow. If you cannot name who speaks next, you are not ready. That tax is the next lesson.

How agents use this

Keep a single-agent baseline on the same golden tickets: one loop, the tools that are safe together, the same success checks. If two agents do not beat it on quality, cost, latency, or incidents, delete one. Multi-agent is an optimization, not an identity. Teams that skip the baseline cannot tell whether the designer or the bill improved.

In a design review, refuse a slide that only shows four avatars. Demand the four rows: tools, context, done-check, parallelism. If the only difference is the system-prompt nickname, merge. If a dangerous tool must not sit next to another, split and put the allow-list in code, not in a paragraph that says “the coder is responsible.”

Log role on every tool call from day one. Incident response needs “who asked,” not “the team thought.” Eval the researcher’s briefs and the coder’s tests apart. A pretty brief that the coder cannot use is a researcher fail even if the final PR looks fine.

Budget hops and child jobs before you add a third name. The coordination tax, typed interfaces, and orchestration patterns in this track exist because extra agents are extra operations. Name the operations or do not split.