Why Your Multi-Agent Workflow Keeps Colliding

Two agents in one thread: the second rewrites the first's work because it never saw it. Three in parallel on one repo: overlapping edits, conflicting commits, a bug none of them caught. The model is fine. The setup is wrong, because nothing coordinates shared state.

The actual problem

One agent in one thread sees its own work and rarely contradicts itself. Two agents in two threads share the filesystem, git history, and task list, but do not know the other exists. Agent A renames a function; Agent B keeps calling the old name. The conflict surfaces in review, tests, or production. Human teams solve this with ownership boundaries, branches, and review gates. Agents need the same.

The pattern that works

Dispatch one fresh agent per task, with isolated context, never several implementers in parallel on the same files. Each task becomes its own loop: the agent gets the task, the plan, and relevant file paths, then reports one of four statuses. DONE: work matches the plan, proceed to review. DONE_WITH_CONCERNS: matches, but something felt off; read the concerns. NEEDS_CONTEXT: missing piece; provide it and redispatch. BLOCKED: upgrade the model, split smaller, or escalate. A clean handoff replaces the fuzzy "I think I'm done".

Two-stage review

After DONE, two reviews run in order. First spec compliance: did the agent build exactly what the plan asked, nothing missing, nothing extra. Only then code quality: clean code, proper patterns, maintainability. You never polish code that does not meet the spec.

Match the model to the task

Mechanical implementation with clear specs and one or two files: a fast, cheap model. Integration work across boundaries: the standard model. Architecture, design, review: the most capable model. Opus on an if-statement is waste; Haiku on a payment flow review is risk.

What never happens

Implementation directly on main: branch first. Skipping spec review because the change is small: small changes still must match the spec. Parallel implementers on overlapping files: they collide. Moving on with open review issues: finish the loop. Accepting "close enough" on spec compliance: if it does not match, it does not match.

The trade-off

Dispatch has overhead. A ten-minute, one-file task is better as a single-threaded edit; six independent subtasks are better as six dispatches. The discipline is being honest about which mode you are in: a "single task" with three independent parts gives you the costs of both modes and the benefits of neither.

What to do today

Take your next multi-part task, split it into isolated subtasks, and dispatch them one at a time with a required status report.