Why Your Multi-Agent Workflow Keeps Colliding

You run two coding agents in one thread. The first builds a feature. The second rewrites part of it because it did not see the first agent's work. You run three in parallel on the same repo. They edit overlapping files, push conflicting commits, and ship a bug none of them caught.

The model is fine. The setup is wrong. Multiple agents in shared state produce conflicts because nothing coordinates them.

The actual problem

A single agent in one thread has a single context window. It sees what it did. It does not contradict itself (much).

Two agents in two threads do not see each other. They share the filesystem, the git history, and the task list, but they do not know the other exists. So they make decisions based on stale state. Agent A renames a function. Agent B keeps calling the old name. Agent A deletes a file. Agent B edits the deleted file. The conflict shows up in review, in tests, or in production.

This is the same problem human teams have. Humans solve it with ownership boundaries, branches, and review gates. Agents need the same.

The pattern that works

Dispatch one fresh agent per task. Give it isolated context. Do not let multiple implementation agents run in parallel against the same files.

Each task becomes its own loop. The agent gets the task, the plan, and the relevant file paths. It implements. It reports one of four statuses.

DONE. The work matches the plan. Proceed to review.

DONE_WITH_CONCERNS. The work matches the plan, but something felt off. Read the concerns before proceeding.

NEEDS_CONTEXT. The agent hit a missing piece. Provide it, then re-dispatch.

BLOCKED. The agent cannot proceed. Upgrade the model, break the task smaller, add context, or escalate to a human.

The pattern matters because it forces a clean handoff at every step. There is no fuzzy "I think I'm done". There is a status, and the coordinator acts on it.

Two-stage review after each task

After the implementer reports DONE, two reviews run in sequence.

First, a spec compliance check. Did the agent build what the plan asked? Nothing missing. Nothing extra. If the answer is no, the implementer goes back.

Second, a code quality check. Only after spec compliance is confirmed. This reviewer looks for clean code, proper patterns, maintainability.

The ordering matters. You do not polish code that does not meet the spec. You fix the spec first. The implementer never gets to argue about style while the feature is still wrong.

Model selection by task type

Not every task needs the most capable model. The leverage is matching the model to the work.

Mechanical implementation tasks. Isolated functions, clear specs, one or two files. Use a fast, cheap model. The work is mostly typing.

Integration tasks. Connecting components, wiring APIs, debugging across boundaries. Use the standard model. Judgment matters.

Architecture, design, review. Choosing between approaches, evaluating trade-offs, catching subtle bugs. Use the most capable model you have.

Spending Opus on a function that writes one if-statement is a waste. Spending Haiku on a payment flow review is a risk. The skill is matching.

What never happens

A few patterns are off-limits regardless of pressure.

Implementation directly on main. No. Branch first.

Skipping the spec compliance review because the change is small. No. Small changes still need to match the spec.

Multiple implementation agents in parallel on overlapping files. No. They will collide.

Moving to the next task while a review has open issues. No. Finish the loop.

Accepting "close enough" on spec compliance. No. If it does not match, it does not match.

When one agent in one thread still wins

Subagent dispatch has overhead. For a five-minute task, the ceremony costs more than the work.

The judgment is task size and isolation. A task that touches one file and takes ten minutes is better as a single-threaded edit. A task that has six independent subtasks is better as six subagent dispatches.

The discipline is honesty about which one you are running. If you call something a single task and it has three independent parts, you are paying for both modes and getting the worst of each.

What changes for your team

Treat agent output like junior output. Plan the work in small isolated tasks. Dispatch one agent per task. Require status reports. Review spec compliance first, quality second. Match the model to the work.

The agents do not get tired and do not lose context. They do conflict if you let them share state. The fix is structural, not motivational.