Eliminating Serial Dependencies in Multi-Agent Systems

The seductive promise of multi-agent AI systems collides with a brutal reality: adding agents often makes systems perform worse, not better. Recent research from Google and MIT quantifies this degradation—past certain thresholds, 20 agents produce less output than three would. The intuition that fails: if one agent completes a task in an hour, ten agents should finish it in six minutes. Instead, seventeen agents effectively stand in line while three work.

This isn’t diminishing returns—it’s actual performance degradation. The culprit: serial dependencies. Every coordination point becomes a bottleneck where agents wait for each other, duplicate work, or create conflicts requiring resolution. As agent count grows, coordination overhead scales faster than capability. The mathematics are unforgiving. When single-agent accuracy exceeds 45% on a task, adding agents yields negative returns. In tool-heavy environments with ten or more tools, multi-agent efficiency drops by factors of 2-6 compared to single agents.

The practitioners who’ve achieved actual scale—Cursor running hundreds of agents, Steve Yaggi’s Gas Town orchestrating 20-30 agents simultaneously—converged on counterintuitive architectures that eliminate coordination entirely. Their systems don’t resemble the team-based metaphors dominating frameworks. They implement strict hierarchies, ephemeral workers, and coordination-free execution patterns.

The synthesis reveals why simplicity scales: complexity creates serial dependencies, and serial dependencies block the conversion of compute into capability. The conversion of compute into capability is what multi-agent architecture promises to deliver.

Architecture Principles: Two Tiers, Not Teams

The industry consensus treats agents like human teams—they share context, coordinate dynamically, and operate continuously. Cursor tested this directly by giving agents equal status and letting them coordinate through shared files. Each agent could check others’ work and claim tasks. The sophisticated coordination infrastructure failed catastrophically.

Agents held locks too long, forgot to release tasks, and created bottlenecks where most system time was spent waiting. Twenty agents produced 10% of expected output. The behavioral failure mode proved equally destructive: with no hierarchy, agents became risk-averse, gravitating toward small, safe changes. Hard problems sat unclaimed because claiming meant accepting responsibility for potential failure while others accumulated easy wins.

The team dynamics metaphor imports centuries-old human coordination problems. Meetings become synchronization points where everyone waits. Status updates create read-after-write dependencies. Technical analogs to human rituals emerge and fail at scale.

Add to CLAUDE.md:

When breaking down complex tasks, use strict two-tier hierarchy: 1) I (planner) create specific, isolated tasks, 2) You (worker) execute exactly what’s assigned without coordinating with other instances or considering broader context. Do not suggest adjacent tasks or refactor beyond scope. Execute, report results, and stop.

Add to CLAUDE.md:

Treat this conversation as an API contract. I will provide: 1) Exact deliverable, 2) Success criteria, 3) Context boundaries. You will: 1) Acknowledge understanding, 2) Execute within bounds, 3) Report completion status. 79% of multi-agent failures come from unclear specs, not technical issues.

The alternative architecture eliminates peer coordination entirely. Planners create tasks. Workers execute them in isolation. Workers don’t know other workers exist. Each picks up a task, executes in isolation, pushes changes, and terminates. Git or merge queues handle conflicts after execution completes.

Yaggi’s Gas Town architecture confirms this pattern. His “pole cats” are ephemeral workers that spin up, execute a single task, hand results to the merge queue, and get decommissioned. They never coordinate with other workers. The “mayor” sits above them, creating and assigning work. This structure emerged from four failed orchestration patterns where peer coordination collapsed under load.

Task Isolation and Ephemeral Execution

Workers staying ignorant of broader context prevents scope creep that creates dependencies. Each agent receives minimum viable context—exactly what’s needed for its specific deliverable, no more. This architectural constraint enables true parallel execution because no worker waits for another’s state or decisions.

Create /isolate-task command:

Takes a complex task and breaks it into isolated, minimum viable context tasks. Each task includes: 1) Specific deliverable, 2) Exact context needed (no more), 3) Success criteria, 4) No dependencies on other tasks. Templates for parallel execution.

The decomposition process identifies coordination points before they become bottlenecks. Tasks that would require coordination get merged or assigned to single agents. Dependencies get externalized to merge queues or state files that workers read from and write to without coordinating with each other.

Context pollution destroys long-running agents. Each interaction adds irrelevant information that degrades decision quality over time. The solution: planned endings. Workers capture essential state to external systems and terminate. Fresh workers restart from captured state without accumulated context pollution.

Create ephemeral-session skill:

The skill designs workflows that capture progress to external state (files, databases) and can restart fresh. First, it identifies session boundaries where state can be externalized. Second, it creates state capture mechanisms that preserve essential progress. Third, it designs restart protocols that maintain workflow continuity. Fourth, it implements termination triggers that prevent context drift.

This pattern contradicts frameworks advocating continuous agents that accumulate context indefinitely. Long-running context becomes a liability, not an asset. Ephemeral execution with external state management scales where persistent agents degrade.

Tool Selection and Coordination Infrastructure

Tool selection accuracy drops precipitously with choice expansion. Research demonstrates degradation beyond 30-50 tools even with unlimited context. Each additional tool creates decision complexity that serializes execution—agents spend more time choosing tools than using them.

Implement minimal tool set principle:

Limit each agent instance to 3-5 core tools max. Create progressive disclosure pattern where additional tools are only available when specifically requested for the task. Document tool selection accuracy degradation past 30-50 tools in team guidelines.

The progressive disclosure pattern provides tools just-in-time rather than front-loading entire toolchains. Workers receive exactly the tools needed for their isolated task. This reduces decision overhead and prevents tool conflicts where multiple agents compete for limited resources.

Merge coordination becomes critical infrastructure when workers operate in isolation. Without peer coordination, conflicts emerge at the merge point where isolated outputs combine. A dedicated merge coordinator handles this complexity outside the worker execution path.

Create merge-coordinator subagent:

Input: Outputs from isolated workers and conflict detection rules. Process: First, it analyzes outputs for conflicts (file changes, schema mismatches, dependency violations). Second, it applies merge strategies (Git merge, queue ordering, manual escalation). Third, it validates merged results against success criteria. Fourth, it updates external state with clean merged output. Output: Validated, conflict-free merged result or escalation notification.

This infrastructure enables the coordination-free architecture by handling complexity at the edges rather than distributing it throughout worker execution. Workers remain ignorant of conflicts and coordination—the merge coordinator bears that complexity.

Coordination-Free Workflow Patterns

The architecture principles combine into workflow patterns that eliminate serial dependencies entirely. Each workflow step reads input from external state, executes in complete isolation, writes output to external state, and terminates. No worker knows other workers exist.

For coordination-free workflows:

Design multi-step workflows where each step: 1) Reads input from external state (files/queue), 2) Executes in complete isolation, 3) Writes output to external state, 4) Terminates. No worker knows other workers exist. Use Git or task queues for coordination. Route conflicts to merge coordinator. Log all state transitions for debugging parallel execution issues.

Git becomes coordination infrastructure rather than version control. Each worker commits changes to branches. Merge conflicts get resolved by dedicated coordination agents, not workers. This externalizes complexity while maintaining parallel execution benefits.

Task queues provide another coordination mechanism. Workers pull tasks, execute in isolation, push results, and terminate. Queue ordering and priority management happen outside worker execution. This pattern scales linearly—adding workers increases throughput proportionally because no coordination overhead exists between workers.

The external state pattern prevents workers from sharing memory or communicating directly. All coordination happens through Git commits, task queue entries, or file system writes that other workers read. This architectural constraint forces elimination of serial dependencies at the design level.

The Synthesis: Simplicity Scales Through Isolation

The CLAUDE.md constraints establish worker behavior boundaries. The task isolation command creates parallelizable work units. The ephemeral session skill prevents context degradation. These artifacts prevent coordination by design. The merge coordinator and workflow patterns handle coordination externally. This creates tension: some artifacts eliminate coordination while others manage its consequences.

The pattern reveals why industry frameworks fail at scale. Team-based metaphors import human coordination problems into systems that could eliminate them entirely. The sophisticated coordination infrastructure becomes the bottleneck rather than the solution. When coordination overhead scales faster than capability, adding agents degrades performance.

Successful architectures converge on counterintuitive simplicity. Two tiers instead of flat teams. Ephemeral workers instead of persistent agents. External state instead of shared memory. Isolation instead of collaboration. These constraints feel limiting until coordination collapse demonstrates their necessity. The synthesis: complexity creates serial dependencies, serial dependencies block scaling, therefore simplicity is not a design choice but a scaling requirement.