Parallelism vs coherence

Give three agents the same investigation and the first few minutes look excellent.

Three searches are moving. Three context windows are filling. Three answers arrive before one careful run would have finished.

Then the actual work starts.

One answer uses the newest source but misses a constraint. One covers the constraint using old evidence. The third disagrees with both and cannot show which claim caused the split. None is obviously bad. None is safe to act on without another pass.

This is the part hidden by the word "parallelism." More hands reduce elapsed time only when their outputs can remain separate or combine cheaply. Otherwise the waiting time returns as reconciliation.

The two instincts behind the debate are both reasonable.

One says agents are software workers. Copying one is cheap, so split the job and let them search, test, or draft at the same time. The other says every additional worker creates another version of the truth. Keep one agent in charge so the reasoning and state stay coherent.

I don't think the useful choice is one agent or many. It is deciding which parts of the work may diverge and where divergence must stop.

Parallelism works well when the branches are independent and missing one branch would make the result worse.

Research is the obvious case. One agent can inspect product documentation while another reads papers and a third looks for failure reports. They do not need to agree while gathering evidence. Separate context windows are useful because one line of inquiry does not crowd out another.

Anthropic describes this pattern in its multi-agent research system. A lead agent gives specialized subagents different parts of the question, then combines their findings. On Anthropic's internal research evaluation, a Claude Opus 4 lead with Claude Sonnet 4 subagents outperformed a single Claude Opus 4 agent by 90.2 percent. The company also reports that parallel tool calls cut research time by as much as 90 percent on complex queries.

Those are vendor-reported results on Anthropic's own system, not a universal multiplier. The mechanism still makes sense. Independent searches can happen at the same time, and each agent can compress its part before handing it back.

The pattern also fits production work that has clean artifact boundaries. Separate agents can write tests for different modules, classify unrelated records, or inspect independent services. If each branch has a defined input, output, and check, concurrency converts available compute into lower elapsed time.

This is Team Parallel's strongest point. A single agent has one attention stream. Some work is wider than one stream should be.

Parallel work gets expensive when the task contains shared decisions.

Suppose three agents review the same incident. One blames a retry policy. Another identifies stale state. A third recommends changing the tool contract. A summary agent can list all three conclusions, but a list is not a decision. Somebody still has to compare evidence, resolve incompatible assumptions, and choose the change that will ship.

Agreement is not enough either. Agents using the same model, sources, or prompt can repeat the same mistake. Ten matching answers may be ten correlated copies, not ten independent votes.

That makes coherence more than neat synthesis. The coordinator has to preserve provenance. Which worker found this claim? Did another worker verify the source or merely quote the first? Were two conclusions produced independently, or did the second inherit the first agent's summary? Without those answers, a polished final report can hide a weak chain of evidence.

There is a difference between a worker and a verifier. A worker adds another attempt. A verifier checks a stated property against evidence or final state. If the consequence matters, I would rather pay for one genuinely independent check than five agents applauding the same draft.

The scale can become absurd. In September 2026, OpenAI reported a candidate Navier-Stokes resolution produced by a group on the order of 10,000 concurrent agents. For that problem, the agents sent 2.7 million messages and produced about 130 billion output tokens over roughly 88 hours. Formalization and verification took another 17 hours.

The point is not that the experiment used too many agents. A Millennium Prize problem can justify unusual spend. The revealing detail is that the swarm did not remove the need for formalization and verification. It made that stage more important.

Anthropic reports the same trade-off at ordinary scale. Its multi-agent research system uses about 15 times as many tokens as a chat interaction. It also found that vague delegation caused duplicated work and gaps. The lead agent had to specify objectives, output formats, sources, and task boundaries.

Spawning is cheap. Coordination is an architecture.

The cleanest division I know is to parallelize work whose evidence can be checked independently.

"Research this issue" is a weak branch. Every agent may follow the same obvious links and return a differently worded version of the same answer.

"Check the current API contract," "reproduce the failure from logs," and "find the last change touching this path" are better branches. Each has a distinct evidence base. The outputs may disagree, but the disagreement is informative because it points to a boundary between facts.

This changes what the coordinator must do. It does not ask workers for opinions and then average them. It defines coverage, prevents overlap where possible, and requires artifacts that survive the worker's context window: source links, test results, patches, traces, or structured findings.

For code, ownership boundaries may be files or modules. For research, they may be source classes or competing hypotheses. For operations, they may be separate systems that can be inspected without changing shared state.

Irreversible actions are different. I wouldn't let three agents independently "help" with the same deployment, payment, account, or database migration. Discovery can fan out. The action path needs one owner, one current state, and one decision about whether to proceed.

Coherence does not require one agent to perform every step. It requires one place where the current decision is settled.

A lead agent can own that role, but the title alone solves nothing. It needs a compact record of what each branch found, what evidence supports it, which questions remain open, and what budget or stop condition applies. Passing every token from every worker into one giant prompt merely moves the collision into the context window.

A September paper on Gated-Memory Routing makes this problem explicit. Routing from the original query cannot react to progress or errors. Routing from the complete execution history carries redundant and low-value steps forward. The authors instead select what enters shared execution memory, what each later agent retrieves, and when the collaboration should stop. Across five reasoning and code benchmarks, they report 2.44 points higher average accuracy than their strongest baseline and 31.9 percent lower inference cost on HumanEval.

I don't want to turn one paper into a general production rule. I would keep the design question it exposes: what information is allowed to become shared state?

If every worker can rewrite the plan, there is no plan. If no worker can update it, the coordinator ignores what the workers learned. The practical middle is a single decision record with explicit proposals, evidence, and an owner who accepts or rejects changes.

That owner may be an agent for a reversible research task. For a consequential action, it may be a person. What matters is that the system does not confuse several completed branches with one completed decision.

Before adding another worker, I would ask:

My default is to parallelize discovery, independent checks, and bounded production. I centralize prioritization, shared state, final synthesis, and actions that are hard to reverse.

That rule is less exciting than "spin up a swarm." It is also cheaper to debug.

I run enough agent workstreams that an idle slot can feel like wasted capacity. When one agent is taking its time, launching three more feels productive before any result exists.

I have done this with an epic. I gave several of its tickets to separate agents and let them all run at once. On the board, each ticket looked independent. They still came from the same epic, so the changes kept landing in the same places, and the conflict resolution at the end was a lot of work.

That is the split-by-job-title mistake in its most ordinary form. A ticket is a unit of planning, not a boundary in the code. I had divided the work by how we track it instead of by what each change would touch.

The feeling that led there is the uncomfortable part. Activity is visible. Reconciliation debt is delayed. The board shows four agents running. It does not show the merge waiting for me at the end.

I want the speed. I just want to pay the coordination cost on purpose.

A swarm is not a team until somebody pays the cost of reconciliation.

The next article takes on Permission Gates vs Runtime Governors: should control happen before an agent acts, or while its behavior unfolds?