Parallel isn't coordinated: the real bottleneck in agentic coding

“Analysis is running in parallel (4 agents)…”

That line from an AI coding agent made me stop scrolling. Four agents, working simultaneously. Impressive.

Then, a few lines later, the same agent quietly admitted the catch:

“The four analysis agents are already dispatched with fixed prompts, so I can’t inject that into them mid-run.”

Parallel? Yes. Coordinated? Not even close.

Think about how a real engineering team works. A human notices new information. A human interrupts. A human reprioritizes. A human shares fresh context on the fly. Today’s coding agents mostly can’t. Once work starts, the plan is frozen. It feels less like a collaborative engineering team and more like submitting four batch jobs and waiting for them to finish.

So I went looking for evidence that this is a systemic limitation, not a one-off quirk.

Turns out, Anthropic’s own engineering team has said the quiet part out loud.

Exhibit A: Anthropic’s multi-agent research system

In their write-up on building a multi-agent research system, they describe running subagents synchronously: the lead agent waits for each batch to finish before moving on. By their own account, the lead agent can’t steer subagents mid-run, subagents can’t coordinate with each other, and the whole system can stall waiting on a single slow worker.

Their admission is refreshingly direct: today’s LLM agents “are not yet great at coordinating and delegating to other agents in real time.”

Exhibit B: 16 Claudes vs. the Linux kernel

In February 2026, an Anthropic researcher put 16 Claude agents on a shared codebase to build a C compiler from scratch.

When the work was naturally parallel - hundreds of independent failing tests - 16 agents flew.

But the moment they hit one big shared task, compiling the Linux kernel, it fell apart. Every agent hit the same bug, fixed it, and overwrote each other’s changes. Sixteen agents didn’t help, because all sixteen were stuck on the same problem.

And the coordination mechanism? A bare-bones git-based file-locking scheme. No orchestrator. No live communication between agents.

That’s not a coordination strategy. That’s a mutex with extra steps.

The real leap isn’t more agents

Here’s my thesis: the next big jump in agentic software engineering won’t come from adding agents. It will come from making agents:

Interruptible - able to absorb new information mid-run
Context-synchronized - continuously, not at batch boundaries
Renegotiable - able to re-plan and re-divide work when the situation changes
Mutually aware - knowing what every other agent is discovering, in real time

The industry is already leaning this way. Anthropic ships a production research system on an orchestrator-worker pattern and is openly exploring the harder version: asynchronous execution, where agents work concurrently and spawn subagents on the fly. They’re candid that this unlocks parallelism but introduces thorny problems around result coordination, state consistency, and error propagation. Other labs are pushing on subagents and parallel execution too.

But dynamic coordination - running agents that update each other’s plans without restarting - is still very much an open problem.

Sound familiar? It should. This is the distributed-systems problem of the AI agent era. The bottleneck is shifting from raw model quality to coordination, ownership, synchronization, and orchestration.

The strongest evidence: there’s no free pattern

In April 2026, Anthropic published a breakdown of five multi-agent coordination patterns. What stands out is that every single one trades one failure mode for another - exactly the “pick your poison” reality anyone who has built distributed systems will recognize:

Generator-verifier. One agent produces, another checks against explicit criteria. Solves quality control - but the verifier is only as good as its rubric. A vague “is this good?” check rubber-stamps everything, and the loop can oscillate forever without converging.
Orchestrator-subagent. A lead agent plans, delegates, and synthesizes - this is how Claude Code works. Solves clean task decomposition - but the orchestrator becomes an information bottleneck. When one subagent discovers something another needs, it travels back through the lead, and details get summarized away.
Agent teams. Persistent workers claim tasks from a shared queue and run autonomously for long stretches. Solves parallel, long-running work - but teammates can’t easily share intermediate findings and can collide on shared files. Exactly the Linux-kernel failure above.
Message bus. Agents publish and subscribe to events, so you can add agents without rewiring. Solves scaling an evolving ecosystem - but event flows are hard to trace, and a misrouted event fails silently: handling nothing while never crashing.
Shared state. Agents read and write a common store with no central coordinator. Solves real-time collaboration and removes the single point of failure - but agents can duplicate work or fall into reactive loops, burning tokens on work that never converges.

Anthropic’s own advice: start with the simplest pattern that could work, watch where it breaks, and evolve. In production, teams usually end up combining patterns - an orchestrator for the workflow, shared state for the collaboration-heavy parts.

That’s not a solved problem. That’s engineering around trade-offs.

Which is exactly why I keep coming back to the distributed-systems analogy: we’re not chasing the one right pattern, we’re learning to compose imperfect ones. CAP theorem energy, but for agents.

Over to you

Two genuine questions I’d love a second opinion on:

Have you come across research or products tackling live coordination between long-running coding agents - not just parallel execution?
If you’ve built multi-agent systems in production, which pattern (or combination) did you land on, and where did it break first?

If you’ve got war stories or links on this, reach out.

Found this useful? I write about agentic AI and open source.
More posts · GitHub