Why 4 Coordinated Agents Beat a Single Opus Run

By Lazar Milicevic · Published August 17, 2026 · 10 min read

You've got a 400k-line codebase, a migration deadline, and one AI assistant that keeps losing the plot around tool call #40. It hallucinates a helper function that doesn't exist, patches the wrong file, and by the time you catch it you've burned $18 in tokens for a diff you have to throw away. This is the wall every solo dev and small engineering team hits when they push a single frontier model at a long-horizon coding task, and it's the reason coordinated multi-agent setups are quietly eating single-model runs on real enterprise work.

The single-agent wall on long-horizon coding

A single model — even a strong one like Claude Opus 4.8 — has a fixed attention budget per run. Once a coding task requires reading 30+ files, running tests, patching, re-running tests, and reasoning about cross-module effects, three things start to fail at once:

1. Context rot. The earliest tool outputs get compressed or forgotten. The model "remembers" the plan but not what the plan was based on.
2. Compounding errors. One wrong assumption at step 12 poisons steps 13–40. Nothing corrects it because the same agent that made the mistake is the one evaluating its own work.
3. Tool-call cost. Every retry pays the full context tax again. A single 60-step task can easily consume $10–$30 in tokens with a frontier model, and most of that is the same context being reshipped.

The obvious response — "just give it a bigger context window" — doesn't fix compounding errors, and it makes cost worse, not better. The interesting question isn't how much can one agent hold? It's how do you split the work so no single agent has to hold all of it?

Why naive multi-agent setups fail

Most people's first attempt at multi-agent is a manager pattern: one "orchestrator" agent spawns sub-agents, waits for each to return, then decides the next step. This is what LangGraph, CrewAI, and the default Claude sub-agent pattern give you out of the box. It's clean, and it works fine for parallelizable tasks like "read these 20 files and summarize each."

It falls apart on coordination-heavy work for one reason: the agents can't talk to each other mid-task. Sub-agent B doesn't know that sub-agent A just discovered the auth module actually lives in a shared package. Sub-agent A can't ask sub-agent C "hey, did that migration script already handle the users table?" Every piece of shared understanding has to route back through the orchestrator, get re-summarized, and get pushed back down. You end up with a bureaucracy that loses information at every hop.

The fatal pattern looks like this:

User task
   │
   ▼
Orchestrator ──► Agent A (finishes, returns)
   │
   ├──► Agent B (works with stale info from A's summary)
   │
   └──► Agent C (duplicates half of A's work)
   │
   ▼
Orchestrator stitches conflicting outputs → mess

The research groups pushing multi-agent past single-model performance on real coding benchmarks are all doing some version of the opposite: agents that can coordinate mid-task, share a live workspace, and challenge each other's conclusions before the orchestrator sees the result.

What "real-time coordination" actually means

Real-time coordination is a technical claim, not a marketing one. It means three specific properties are true of your system:

• Shared mutable state. Agents read and write to the same workspace — a file tree, a memory store, a scratchpad — and see each other's changes without waiting for the orchestrator.
• Direct agent-to-agent messaging. Agent B can send Agent A a targeted question ("which file did you patch for the token refresh?") and get an answer without the orchestrator interpreting it.
• Event-driven progress. Agents react to changes in the workspace (new file, failing test, updated spec) instead of running on a fixed step-by-step plan.

Model Context Protocol (MCP) makes this practical for small teams because it standardizes how agents talk to shared tools. Instead of writing custom glue for each agent-to-tool connection, you expose one MCP server per capability (filesystem, test runner, git, database) and let every agent in the team hit it. The shared server is the coordination surface.

Here's the shape of a minimal MCP-backed coordination server that four coding agents can hit at once:

# coord_server.py — an MCP server exposing a shared task board
from mcp.server import Server
from mcp.types import Tool, TextContent
import json, asyncio, pathlib

STATE = pathlib.Path("./.agent_state.json")
LOCK = asyncio.Lock()

server = Server("coord")

async def _load():
    if not STATE.exists():
        return {"claims": {}, "notes": [], "findings": {}}
    return json.loads(STATE.read_text())

async def _save(state):
    STATE.write_text(json.dumps(state, indent=2))

@server.call_tool()
async def claim_file(agent_id: str, path: str) -> list[TextContent]:
    async with LOCK:
        s = await _load()
        holder = s["claims"].get(path)
        if holder and holder != agent_id:
            return [TextContent(type="text",
                text=f"BLOCKED: {holder} owns {path}. Post a note or wait.")]
        s["claims"][path] = agent_id
        await _save(s)
        return [TextContent(type="text", text=f"OK: {agent_id} owns {path}")]

@server.call_tool()
async def post_finding(agent_id: str, key: str, value: str):
    async with LOCK:
        s = await _load()
        s["findings"][key] = {"by": agent_id, "value": value}
        await _save(s)
    return [TextContent(type="text", text="stored")]

@server.call_tool()
async def read_findings() -> list[TextContent]:
    s = await _load()
    return [TextContent(type="text", text=json.dumps(s["findings"], indent=2))]

Four agents pointed at this server can now claim files (no double-patching), publish findings the moment they discover them (no waiting for a round trip), and read each other's findings before deciding what to do next. The orchestrator becomes a lightweight referee, not a bottleneck.

A concrete 4-agent split for enterprise coding tasks

The split that consistently outperforms a single frontier-model run on multi-file coding work is roughly:

The critical detail: the Adversary is a peer, not a reviewer at the end. It runs concurrently and posts risks to the shared board as soon as it sees them. The Implementer sees a new risk appear mid-task and can adjust before finishing the patch. That's the loop a single agent literally cannot run against itself, because it has no independent perspective.

A rough config for launching this with Claude Code sub-agents or an equivalent framework:

agents:
  cartographer:
    model: claude-haiku
    tools: [filesystem, coord.claim_file, coord.post_finding, coord.read_findings]
    system: "Map the codebase. Post findings as you go. Never patch."
  implementer:
    model: claude-sonnet
    tools: [filesystem, coord.*, git]
    system: "Patch only claimed files. Re-read findings before each edit."
  verifier:
    model: claude-haiku
    tools: [shell, coord.*]
    system: "Run tests on every change. Post failures with the diff hash."
  adversary:
    model: claude-sonnet
    tools: [filesystem, coord.*]
    system: "Find what the implementer missed. Post risks, don't patch."
orchestrator:
  policy: event-driven
  halt_on: [verifier reports pass, adversary reports no new risks, 3 idle cycles]

Cost note: using a cheaper model (Haiku-class) for the Cartographer and Verifier is where most of the token savings come from. The Implementer and Adversary need the strong model. In practice, a well-tuned 4-agent run often costs less than a single Opus run on the same task, because you're not reshipping the full codebase context to the expensive model on every step.

What the coordination pattern actually buys you

Three things that a single-agent run genuinely cannot do, no matter how large its context:

1. Independent verification without self-review bias. The Verifier and Adversary have no stake in the Implementer's patch being correct. When a single agent reviews its own work, it tends to justify what it just did. Split roles eliminate that failure mode structurally, not through prompting tricks.

2. Parallel exploration under a shared budget. The Cartographer can be halfway through mapping module 40 while the Implementer is patching module 3 based on what was mapped at minute two. You compress wall-clock time without compressing quality.

3. Graceful failure isolation. If the Implementer goes off the rails on file X, the claim system prevents it from corrupting files Y and Z. The Verifier catches the bad patch, the orchestrator rolls back only that claim, and the rest of the work survives. A single agent that goes off the rails on step 30 usually poisons everything after step 30.

The trade-off is real: coordination overhead is not free. For tasks that fit comfortably in one agent's working memory — a single-file bug fix, a docstring pass, a small refactor — the multi-agent setup is slower and more expensive. The break-even, in our experience, is somewhere around "any task that touches more than ~8 files or requires more than ~20 tool calls." Below that, ship a single agent. Above that, coordinate.

The failure modes nobody warns you about

If you build this yourself, you will hit these:

• Deadlocks on file claims. Agent A claims auth.py, needs to read users.py, which Agent B claimed and is waiting on auth.py. Fix: claims must have a TTL, and the orchestrator arbitrates on timeout.
• Finding-board pollution. Agents dump verbose logs into the shared board and blow up each other's context. Fix: enforce a max size per finding and require a key namespace per agent role.
• Runaway consensus. All four agents converge on the same wrong assumption because they're all reading the same seed findings. Fix: the Adversary must be prompted to actively disagree, and its findings should be weighted higher when they contradict the Implementer.
• Cost blowouts from chatter. Agents send each other 40 messages when 3 would do. Fix: rate-limit post_finding per agent per minute; the orchestrator drops low-signal posts.
• Non-determinism in reproduction. Two runs of the same task produce different diffs because agents interleave differently. Fix: seed the coordination server with a deterministic ordering policy, and always log the full event stream so you can replay a run.

Anthropic's own writing on multi-agent research systems (worth reading directly on their engineering blog) is candid about most of these — coordination is where the engineering work actually lives, not in prompt design.

How BizFlowAI approaches this

We build coordinated agent teams over MCP for exactly this class of problem — codebase migrations, multi-system ops workflows, and long-horizon tasks where a single model run keeps degrading past the 30-step mark. The pattern above (Cartographer / Implementer / Verifier / Adversary over a shared MCP coordination server) is close to what we deploy for clients, tuned to their stack and cost ceiling. Most of the work is not the agents themselves; it's the coordination server, the claim/rollback policy, and the observability so you can actually see why a run went the way it did.

If you're hitting the single-agent wall on your own codebase or ops workflow, book a discovery call and we'll map out whether a coordinated setup is the right fix or whether a leaner single-agent design gets you there for less. Not every problem needs four agents; the honest answer is what we lead with.

When to reach for this pattern (and when not to)

A short decision table for the reader who wants to stop reading and start building:

The signal isn't "is this task hard?" It's "does this task require holding more state than one agent can reliably hold, or benefit from independent verification?" If yes to either, coordinate. If no, don't over-engineer.

The broader shift worth naming: the frontier-model-as-monolith era is ending for real production work. Not because the models are getting worse — they're getting better — but because the tasks people actually want to run are outgrowing what any single context can hold. The teams shipping useful automation in 2026 are the ones treating agents like microservices: small, specialized, coordinated over a well-defined protocol, and observable end-to-end. That's less exciting than "one giant brain solves everything," and it's what actually works.

Work with BizFlowAI

If you'd rather have this built for you, that's what we do: production AI automation for solo founders and small teams — agents, integrations, and document pipelines that actually ship.

Book a free discovery call — 30 minutes, we map the highest-ROI automation in your workflow. No pitch deck, just engineering.

More guides like this on the BizFlowAI blog.