The first failure is usually ownership.
Putting two capable coding agents on the same repository sounds like a speed multiplier. It can be. It can also create a quieter problem: both agents make locally reasonable changes while the shared state becomes impossible to trust.
The hard part is not generating more code. It is deciding who may change what, which evidence counts, and what happens when a task stops halfway through.
Use one writer, not two competing editors.
A reliable workflow gives one agent temporary write ownership while the other plans, challenges assumptions and verifies the result. The roles can change from task to task, but there should be only one active writer for a bounded piece of work.
This is less flexible than letting both agents edit freely. That is the point. The small loss in parallelism buys a clear answer to the question that matters after something goes wrong: who changed the shared state?
Bound the task before granting write access.
A useful handoff names the objective, exact files in scope, known risks, acceptance checks and a snapshot of the starting state. The implementer should not have to infer the boundary from a long conversation.
If the starting state has changed before work begins, the safest response is to stop. A stale instruction should fail closed instead of being applied to a repository that no longer matches the plan.
- Name the exact change and the files it may touch.
- Record the pre-change state so drift is detectable.
- Separate implementation evidence from the final verification decision.
- Require fresh approval for external or irreversible actions.
Keep the handoff durable.
Chat history is useful context, but it is a poor system of record. Sessions end, context gets compressed, and a connection can disappear after the work has partly completed.
The durable handoff should live with the project: what was requested, what changed, what was tested and what remains uncertain. A new session can then resume from evidence instead of reconstructing intent from memory.
Human approval is a boundary, not a ceremony.
The workflow should distinguish reversible engineering work from actions that affect the outside world. Drafting a message is not sending it. Preparing a deployment is not deploying it. A capable agent should be able to move quickly inside the approved boundary and stop cleanly at the edge.
That separation makes autonomy more useful, not less. It lets the system proceed without asking the same question repeatedly while preserving an explicit decision point for actions that matter.
The reusable pattern.
Multi-agent work becomes dependable when coordination is treated as part of the system design. One writer, a bounded task, a known starting state, an independent review and durable evidence are simple controls. Together they prevent the most expensive kind of failure: work that looks complete but cannot be trusted.