Why do parallel subagents produce conflicting design decisions?

Cognition's Walden Yan argues that splitting a task across parallel subagents is "very fragile" even when each subagent is given a clean subtask description. His worked example: a "build a Flappy Bird clone" task is split into a background subagent and a bird subagent; one subagent "mistook" its subtask and built a Super Mario-style background, while the other built a bird that "doesn't look like a game asset." Giving each subagent the full original task as context does not fix this either — in Yan's revised example, the background and bird come back in "completely different visual styles" because "subagent 1 and subagent 2 cannot see what the other was doing."

He states this as two principles. Principle 1: "Share context, and share full agent traces, not just individual messages" — a subagent fed an isolated instruction, or even a full task description, is still missing the intermediate decisions another subagent made en route. Principle 2: "Actions carry implicit decisions, and conflicting decisions carry bad results" — every action a subagent takes embeds choices (a visual style, an assumption about scope) that were never written down as explicit instructions, so a second subagent acting independently has no way to converge on the same choices. Yan argues these two principles are violated so often, and so consequentially, that "you should by default rule out any agent architectures that don't abide by them," defaulting instead to "a single-threaded linear agent" where context stays continuous, and reaching for a dedicated context-compression model only once that agent's context window becomes the binding constraint. He cites Claude Code's subagents as an existing design that follows this: they never run in parallel with the task they were spawned from, and are restricted to answering well-defined questions rather than doing open-ended work, specifically to avoid the conflicting-decision problem.

This runs counter to Do single agents always hit organizational limits?, which argues the opposite prescription: that single-agent loops cannot support "parallel execution, independent verification, and persistent state" at all, so the fix is to organize multiple specialized agents with graph abstractions rather than retreat to one linear agent. Yan's account supplies the failure mechanism — implicit, unshared decisions — that the survey's case for coordination has to solve before parallel execution is safe to recommend. The claim also extends the production-reliability logic in Why do protocol-based tool integrations fail in production workflows? from agent-to-tool interfaces to agent-to-agent interfaces: both treat an abstraction layer (MCP metadata, or a subagent's independent reasoning) as the source of non-determinism, and both prescribe removing the layer rather than tuning around it. It also sharpens the mechanism behind How does inconsistent agent behavior affect user understanding? by naming one concrete source of that inconsistency: parallel subagents making decisions without seeing each other's choices.

The excerpt is a design argument from one practitioner's experience building agents at Cognition, illustrated with a single worked example (the Flappy Bird clone) rather than a benchmark, ablation, or reported failure rate — it does not measure how often multi-agent architectures fail in practice, nor compare failure rates against single-threaded agents on real tasks. It also does not specify how large a task has to be before context-window overflow forces the multi-agent trade-off Yan concedes is sometimes necessary. The implication that follows is accordingly a design heuristic rather than an established result: treat parallel subagents as a last resort to be justified by a concrete context-window constraint, not a default architecture choice.