The Topology You Can Review Is the Topology You Can Run

Thirty coding agents were pointed at the same repository, and eighteen of them created a git branch with the exact same name, mvp-game-loop, not because the models were weak, but because nobody had drawn the graph they were running in (Anthropic: Patterns and problems in emerging multiagent systems¹). Every agent did its own job correctly. The failure lived entirely in the arrangement.

Start at One Agent on Coding Work

Before you decide what shape your agent graph should be, notice that the strongest controlled evidence on coding work says the shape should be a single point. This is not the “start simple” platitude every vendor guide opens with; it is a measured result on the benchmark closest to what you actually do.

Kim et al. ran 260 configurations across six agentic benchmarks and five canonical architectures, standardizing tools, prompts, and compute so the architecture was the only thing varying (Kim et al.: Towards a Science of Scaling Agent Systems²). On SWE-bench Verified (the coding benchmark, contributing 40 of those configurations across 8 models and 5 architectures), every multi-agent arrangement lost:

“all MAS architectures show slight degradation relative to SAS (mean 0.522): Hybrid −2.1% (0.511), Centralized −3.1% (0.506), Decentralized −5.4% (0.494), and Independent −14.9% (0.444).”

That is a 20-instance subset, kept small because Docker-based evaluation is expensive, so treat the result as directional rather than decisive. But the direction is uniform, and it points the opposite way from the instinct that more agents means more throughput. The same paper found agent count itself is not a significant predictor of anything: log(1+n_a) came back at β̂=0.040 with a 95% CI of [−0.074, 0.155] and p=0.487. There is also a ceiling on where extra agents can help at all: a capability ceiling of β=−0.236, p=0.004, where tasks a single agent already solves above 45% accuracy get negative returns from additional agents, because coordination costs eat the remaining headroom.

Anthropic’s own research team said the coding-specific version of this out loud in June 2025, and the tense matters: “most coding tasks involve fewer truly parallelizable tasks than research, and LLM agents are not yet great at coordinating and delegating to other agents in real time” (Anthropic: How we built our multi-agent research system³). That was written about the state of things “today,” fourteen months before this post; the SWE-bench numbers above, from a later and more controlled study, have not moved the verdict.

So the prior question about those thirty agents is not what shape they should have formed. It is whether agent number two should have existed. That question has its own answer, the isolation gate, and this post starts strictly after it. That post also set the headcount ceiling in its “Cap the Fan-Out at Your Review Throughput” section: review throughput limits how many agents you can run. What follows extends that from headcount to shape.

Coordination Does Not Arrive With Better Models

Stop treating your multi-agent failures as a model-quality problem you can wait out.

Thirty capable agents get the same repository and the same goal. Each one independently reasons about what to call its first branch, and the most obvious name for the first slice of work is the same obvious name for all of them, so eighteen converge on mvp-game-loop. Anthropic’s Frontier Red Team names that mechanism directly: “When one agent makes a bad decision, it is likely that many agents will make that same bad decision” (Anthropic: Patterns and problems in emerging multiagent systems¹). Correlated models produce correlated choices. The branch collision is not eighteen mistakes; it is one mistake, made eighteen times, by design.

Downstream of the collision, the PRs behaved exactly as you would predict. They “often conflicted with one-another, at which point they were then abandoned,” and Anthropic reads the merge rate the same way:

“A very low fraction of these PRs were merged, which suggests a lack of coordination.”

Set the collision beside the report’s other two arrangements:

Same models, different arrangements, wildly different behavior. The report’s own conclusion is the sentence to pin above the design doc:

“Coordination doesn’t naturally emerge from stronger intelligence nor alignment at the individual level.”

Read that as an engineering assignment rather than a warning. If coordination is a property of the arrangement, then the arrangement is a thing you build, review, and are accountable for, and the next model release will not build it for you.

Make Every Edge Name the Constraint That Forced It

Start from zero edges and make each one earn its existence: you may add an edge only when you can name which constraint forced it, and you write that name down next to the edge. Not a rationale in a design doc. A named constraint, attached to the edge, from a closed list.

The closed list comes from Anthropic, which after building and deploying these systems identified exactly three situations where multiple agents consistently beat one: “when context pollution degrades performance, when tasks can run in parallel, and when specialization improves tool selection or task focus.” Their own framing of what happens off that list is unambiguous: “Outside these situations, the coordination costs typically exceed the benefits” (Anthropic: Building multi-agent systems⁴). OpenAI’s orchestration guidance arrives at the same posture from the API side:

“Start with one agent whenever you can. Add specialists only when they materially improve capability isolation, policy isolation, prompt clarity, or trace legibility. Splitting too early creates more prompts, more traces, and more approval surfaces without necessarily making the workflow better.”

Note that OpenAI is not anti-splitting; “trace legibility” sits in that same sentence as a reason to split. The bar is material improvement to a named property, which is the same subtractive move Anthropic applies to complexity generally: “To repeat: you should consider adding complexity only when it demonstrably improves outcomes” (Anthropic: Building effective agents⁶).

The closed list as a working rule, where seeing the signal licenses that edge and only that edge:

If the middle column is empty, delete the edge. That last row is the one people get wrong most often: risk is a reason to add a checkpoint, never a reason to add a worker.

One refinement worth carrying, from Harrison Chase: “The key insight is that read actions are inherently more parallelizable than write actions” (Harrison Chase: How and when to build multi-agent systems⁷). Writes force you to solve two problems at once: “the dual challenge of effectively communicating context between agents and then merging their outputs coherently.” Coding is write-heavy by definition, which is why a parallelism edge that looks free on a research workload gets expensive the moment it produces diffs.

Now apply the rule backward to the thirty agents. They were not isolating context, the work was not partitioned, and no agent held a tool the others lacked. Thirty edges, zero justifications; mvp-game-loop is what that looks like in the git log.

Reuse the Constraints You Already Tiered

Author’s judgment. Deriving edges from task-risk tiers and the isolation gate is my own synthesis, not a claim any source makes. It follows from two sourced premises: Anthropic’s closed list of three forcing conditions, and OpenAI’s naming of approval surfaces as a cost that splitting creates.

Do not invent a new axis for topology. You have already tiered your agent’s authority by task risk, and you have already drawn the isolation gate. Reuse both.

The mapping is mechanical. The authority-by-task-class table tells you the blast radius of the work crossing an edge, which tells you whether that edge terminates in a merge or in a checkpoint. The isolation gate tells you whether one context window was ever the constraint, which is the only thing that licenses a context-pollution edge. And review capacity gives you the denominator in reviewer-hours, which is a number you measure rather than estimate. Three constraints you already have; no fourth needed.

Specify Each Edge, Then Plan for What the Spec Misses

Write a four-field spec on every edge before you run it (objective, output format, tools and sources, task boundaries), and then design for the decisions the spec cannot reach. Both halves are load-bearing, and most teams ship the first without the second.

The four fields are Anthropic’s, from a system they actually ran: “Each subagent needs an objective, an output format, guidance on the tools and sources to use, and clear task boundaries” (Anthropic: How we built our multi-agent research system³). They earned it the hard way: one subagent explored the 2021 automotive chip crisis while two others duplicated work investigating current 2025 supply chains, with no effective division of labor. The spec travelled on merit rather than vendor syndication; Simon Willison, an outspoken multi-agent skeptic at the time, published “OK, I’m sold on multi-agent LLM systems now” the following day (Simon Willison: How we built our multi-agent research system⁸).

Applied to the edge that produced eighteen identical branches:

Bad: Implement the MVP game loop. Open a PR when you're done.

Good:

• Objective: implement a fixed-timestep update/render loop in engine/loop.go.
• Output format: one PR titled engine: fixed-timestep game loop, on branch agent-07/engine-loop, diff under 200 LOC.
• Tools and sources: read engine/state.go and engine/render.go; do not open engine/input.go.
• Task boundaries: no input handling, no asset loading, no changes to the render backend. The branch name above is assigned; do not choose your own.

The Bad version is not a bad prompt for a single agent; a capable model handles it alone. It is a bad edge, because it leaves the coordination-relevant fields blank in a graph where thirty peers are filling those blanks independently. The branch name is the footgun: it was never in anybody’s spec, so all thirty agents inferred it, and correlated models infer the same thing.

Now the limit. Cognition’s Walden Yan argues the spec can never be complete, and he is right about the mechanism:

“The actions subagent 1 took and the actions subagent 2 took were based on conflicting assumptions not prescribed upfront.”

His conclusion is not “specify your edges more carefully”; it is that “in 2025, running multiple agents in collaboration only results in fragile systems,” and his recommended architecture is to “just use a single-threaded linear agent.” That is the steel-manned opposition to this entire post, and the subtractive procedure is the defensible middle: he is right that no spec can enumerate every implicit decision, which is exactly why the graph needs a node whose job is to catch the ones that got through.

Draw the Human Checkpoint as a Node

Put the human checkpoint in the graph as a node with a resume contract, not in the runbook as a stage. The distinction sounds pedantic until you notice what happens under load: a stage is a thing a person can skip, and a node is a thing the runtime blocks on.

Addy Osmani already owns the strongest version of the review argument:

“Until verification infrastructure catches up with generation capabilities, human review isn’t optional overhead. It’s the safety system.”

He is unambiguous that “The bottleneck is no longer generation. It’s verification.” What he does not do, and what no frontier-lab source does either, is make that checkpoint structural. His pipeline is six ordered stages (Plan, Spawn, Monitor, Verify, Integrate, Retro), and he sizes the team first: “Three to five teammates is the sweet spot.” Only then does the ratio get bolted on top: “1 reviewer per 3-4 builders.” Review is a ratio applied to a topology, not a constraint the topology was derived from. Augment Code’s workspace guide does the same thing one layer down, giving humans a tier in a review pipeline rather than a position in the graph: “A layered pipeline blocks most regressions automatically,” and the instruction is to “Reserve humans for semantic correctness and architecture” (Molisha Shah / Augment Code: How to Run a Multi-Agent Coding Workspace¹¹).

The whitespace at the labs is verifiable, not inferred. Anthropic’s “Building effective agents” gives named section headings to five workflow patterns (prompt chaining, routing, parallelization, orchestrator-workers, evaluator-optimizer) and none to human review. The only control point it draws in a diagram is programmatic: “You can add programmatic checks (see “gate” in the diagram below) on any intermediate steps to ensure that the process is still on track.” Human involvement gets one prose line: “Agents can then pause for human feedback at checkpoints or when encountering blockers” (Anthropic: Building effective agents⁶).

Author’s judgment. Treating the human checkpoint as a first-class node rather than a pipeline stage is my framing, not a claim from any source. It follows from two sourced premises: LangGraph implements human pauses as in-node interrupts backed by the graph’s own persistence layer, and no frontier-lab source elevates human review to a named architectural element.

The move is implementable today, not a rhetorical flourish. LangGraph’s interrupt is called from inside a node: it “pauses graph execution and returns a value to the caller,” and when called within a node, “LangGraph saves the current graph state and waits for you to resume execution with input” (LangGraph: Interrupts¹²). Pointed at the branch decision, the docs’ approval_node shape looks like this:

from langgraph.types import interrupt

def approve_branch(state: State):
    plan = state["branch_plan"]          # e.g. "agent-07/engine-loop"
    approved = interrupt(f"Approve branch {plan}?")
    return {"approved": approved}

That graph cannot proceed past this point without an answer. The checkpointer persists state so the run can resume later; in production that checkpointer should be database-backed. That is why LangChain describes being able to “pause execution of the graph half way through, and then resume after some time - because that checkpoint is there” (LangChain: Making it easier to build human-in-the-loop agents with interrupt¹³). The pause is durable. It survives a restart, a redeploy, and a reviewer going home.

A stage is not an acceptable substitute, because a standing manual approval step decays. The permission-tiering post argued that in “The Human Gate Decays,” and the decay mechanism is exactly the load this post is describing. Under queue pressure people approve faster, then approve in batches, then stop looking. A node under the same pressure produces a visible backlog instead of a silent rubber stamp, which turns an invisible quality problem into a capacity number you can act on.

The topology question is therefore: where does the graph physically stop and wait for a person, and is that node upstream of the irreversible action? For the thirty agents, the answer is a single approval node before branch creation: bounded, verifiable work in, one collision avoided before thirty branches exist.

flowchart TD
    A["30 agents, one repo, one goal"] --> B{"Approval node upstream of branch creation?"}
    B -->|"No node — the run as it happened"| C["Each agent names its own branch"]
    C --> D["18 identical mvp-game-loop branches"]
    D --> E["Conflicting PRs, then abandoned"]
    B -->|"Node — interrupt before create_branch"| F["18 requests to create mvp-game-loop hit one gate"]
    F --> G["1 approved: agent-07/engine-loop"]
    F --> H["17 returned with a different assigned name"]

The Idempotency Trap in a Checkpoint Node

Move every side effect to after the interrupt, because resuming does not resume mid-node. The docs are blunt about it: “The node restarts from the beginning of the node where the interrupt was called when resumed, so any code before the interrupt runs again” (LangGraph: Interrupts¹²).

• When you see a git checkout -b above the interrupt, move it below. Otherwise every resume creates another branch, and your approval node becomes a branch generator.
• When you see any write, POST, or spawn above the interrupt, move it below or make it idempotent. Re-execution is the default, not the exception.
• When you see a fresh thread_id per resume attempt, fix the caller. Reusing the thread_id resumes the same checkpoint; a new value starts a brand-new thread with empty state.
• When you see an in-memory checkpointer in a production graph, replace it. A pause that does not survive a restart is a stage wearing a node’s costume.

def approve_branch(state: State):
    # repo.create_branch(state["branch_plan"])   <- runs again on every resume
    approved = interrupt(f"Approve branch {state['branch_plan']}?")
    if approved:
        repo.create_branch(state["branch_plan"])  # runs once, after the gate
    return {"approved": approved}

Price Every Edge Twice

Budget each edge in tokens and in reviewer minutes. The token bill is the one everybody models and nobody is stopped by; the reviewer bill is the one that actually halts your pipeline, and almost no team writes it down.

Author’s judgment. Treating reviewer bandwidth as a binding constraint on topology is my framing. OpenAI names “approval surfaces” as one cost input among three that splitting creates, and never defines the term or argues it binds; Anthropic supplies the token multiplier. The step from “cost input” to “the constraint that decides the shape” is mine.

Run every proposed edge through five lines before you draw it:

1. Price the tokens. Anthropic’s internal testing puts multi-agent implementations at “3-10x more tokens than single-agent approaches for equivalent tasks” (Anthropic: Building multi-agent systems⁴). No methodology, task list, or model versions are published for that range. Treat it as a vendor’s own measurement, and as a floor rather than a forecast.
2. Price the review minutes. Every edge that terminates in a diff is a claim on reviewer-hours you have not yet spent. Convert it: expected diffs per day, times minutes per diff at your team’s measured review capacity.
3. Price the merge separately from the review. Reviewing two diffs is not the same job as reconciling them, and the reconciliation is the part tooling will not do for you.
4. Price the abandonment. Work that gets produced and then thrown away still consumed both bills. The thirty-agent run is the extreme case: 2.4 million job requests against 117 accepted jobs, plus a pile of conflicting PRs that were opened, reviewed by nobody, and abandoned.
5. Delete the edge whose second bill exceeds what the first bill bought. This is the only line that does any work. If you never delete an edge, you are not pricing them.

Line 3 is the one that surprises people, because it looks like a tooling problem and is not:

“Git detects textual conflicts, not semantic ones. Authoritative guidance still converges on mandatory human review for logic-level contradictions.”

Two agents can produce diffs that merge cleanly and still contradict each other: different assumptions about the same invariant, encoded in code that never touches the same line. Git will not flag it. Your test suite will flag it only if you happened to have a test for that invariant. A person catches it, and that person’s minutes are the scarce input.

Price one more thing before you draw any role-based edge. Anthropic is explicit that “Dividing by type of work (one agent writes features, another writes tests, a third reviews code) creates constant coordination overhead,” and that “an agent handling a feature should also handle its tests, because it already possesses the necessary context” (Anthropic: Building multi-agent systems⁴). The writer/tester/reviewer split is the most commonly drawn topology in coding setups and the one with the worst price on both bills; the handoffs degrade into what they call a “telephone game,” and every handoff adds a diff.

The Counterargument: Maybe the Edge Never Helped

Before you keep an edge you already drew, re-run the comparison with compute held equal. A large share of reported multi-agent wins do not survive that control, and the edge you are defending may never have been the thing that helped.

Tran and Kiela held reasoning tokens constant across two datasets, three model families, and five multi-agent architectures, and found single-agent systems match or beat multi-agent throughout (Tran & Kiela: Single-Agent LLMs Outperform Multi-Agent Systems¹⁴). Their diagnosis is the uncomfortable part:

“many reported advantages of multi-agent systems are better explained by unaccounted computation and context effects rather than inherent architectural benefits”

If that holds for your setup, then the edge you added was a compute increase wearing an architecture costume, and you paid coordination overhead for something a longer single-agent budget would have bought outright.

Two qualifiers are mandatory, and both cut against overreading this paper:

The carve-out reads: “In sufficiently degraded regimes, MAS and SAS may become comparable, and carefully structured MAS pipelines may occasionally surpass SAS by imposing useful factorization, filtering, or verification structure on the reasoning process.” That is the context-pollution constraint, restated from the other direction: when the single window is already degraded, structure buys something real. The scope limit is the more binding one for this post’s audience: “We focus on text-only multi-hop reasoning; MAS advantages with tools/vision or safety constraints are out of scope.” Coding agents are tool-using by definition, so this is not direct evidence about coding topology. It is a preprint about reasoning that happens to land on the same finding.

The coding-specific evidence is Kim et al.’s SWE-bench result from the top of this post, and it points the same way under its own compute normalization. Two independent studies, different domains, one shared conclusion: the edge has to prove it beat the null hypothesis of “spend the same compute on one agent.” Anthropic’s own hedge belongs here too: “Today, multi-agent systems are often applied in situations where a single agent would perform better, though this calculus continues to evolve as models improve” (Anthropic: Building multi-agent systems⁴). The calculus moving is not the same as it having moved. Re-run the comparison; don’t assume the release notes did it for you.

The Edge-Justification Table

Every proposed edge goes through this table before you draw it, and an empty cell deletes the edge. Each row is one of the sections above, compressed into the cell it demands.

Now run the thirty agents through it. Row one fails: this was coding work, and a single agent was the measured default. Row three fails for the reason the closed list already named: thirty edges, zero forcing constraints. Row five fails, which is why mvp-game-loop got invented eighteen times instead of assigned once. Row six fails, and that is the row that would have saved the run on its own: a single approval node upstream of branch creation. Row seven was never opened; the reviewer bill on 2.4 million job requests was never going to be paid by anyone.

Every one of those edges existed because it was easy to draw, not because something forced it. That is the actual failure mode, and it is not a model problem; it is a design review that nobody ran.

The table is a worksheet in the toolkit, edge-justification-worksheet¹⁵, with a checker that deletes any edge holding an empty or off-list cell, and sums the reviewer-minute bill of the ones that survive.