Why this matters
Most public discussion of multi-agent systems starts with orchestration: which agent delegates, which one plans, which model should route which task, and what tools sit behind the runtime.
That is useful, but it is not the operational center of gravity once several AI coding chats are working in one real repository.
In practice, teams get hurt more often by coordination failures:
- two agents think they own the same slice
- nobody knows which state is still active
- a resumed chat inherits ambiguous context
- a handoff says too little to continue safely
- Git history records that something changed, but not why the boundary was chosen
These are not failures of model capability alone. They are failures of shared operating structure.
A concrete failure mode
Imagine three parallel coding chats in one repository. One starts a narrow bug fix. Another notices a nearby edge case and touches the same file. A third resumes an older conversation that still thinks the original task is active.
Each individual move may look reasonable. The repo-level result is worse: ownership is unclear, lifecycle state is stale, follow-up work is guessed instead of transferred, and reviewers have to reconstruct intent from fragmented chat context.
Why orchestration is not enough
An orchestrator can decide who should do what next. That still does not answer who currently holds a role, whether an earlier agent is really inactive, what artifact another session should trust, or which commit boundary belongs to which work item.
Routing does not solve shared-state discipline. A team can have excellent delegation and still get confused because the repository lacks durable, explicit coordination surfaces.
The primitives that matter
The smallest useful multi-agent stack usually needs a registry of active agents and roles, explicit begin/end workcycle boundaries, handoff artifacts that outlive chat memory, Git ownership rules that reduce collision, and reconcile logic for stale-active sessions.
None of these ideas are glamorous. All of them become important the moment parallel work stops being a demo.
The tradeoff
Coordination adds overhead. You write down state that a single uninterrupted chat might have carried in memory for a while. You define boundaries that feel formal compared with free-form pair coding. You accept a small amount of process in exchange for much lower ambiguity.
That trade is usually worth it once multiple agents, multiple sessions, or resumed work become normal.
Takeaway
If a team wants reliable multi-agent coding, the first question should not be "Which swarm runtime should we use?"
It should be: "What explicit coordination surfaces will still make sense after interruption, parallelism, handoff, and resume?"