Guide
By Theorem Labs
Updated
Stop parallel coding agents from taking the same task.
Running two or three coding agents on one codebase fails in predictable ways. This guide explains a coordination pattern that works with any tracker, then shows how Theorem Praxis builds it in.
01 / Guide
Why parallel agents collide
Two failures come up again and again. Two agents start the same task because neither can see that the other has taken it. And when a session ends, what it learned ends with it, so the next agent starts from scratch.
Asking agents to message each other rarely fixes this. Chat is not shared state: an agent that was not in the conversation cannot see it, and a closed session cannot answer. The fix is a shared record that every agent reads before it starts and writes before it stops.
02 / Guide
Give every task exactly one owner
- Before starting, an agent claims a task. The claim must be atomic: two agents asking at the same moment cannot both win.
- The claim expires. A time-limited lease means a crashed or abandoned session frees the task instead of holding it forever.
- To give the task back, the agent writes an outcome: what changed, what it verified, what it decided against, and where the next agent should start.
- Other agents skip claimed work and take the next task that is ready.
A June 2026 preprint, Before the Pull Request: Mining Multi-Agent Coordination, tested a shared substrate where agents claim and divide work. In the author's experiments, the share of work that redid a teammate's task fell from 78% to 0%, and useful throughput more than tripled. It is a single study and has not been peer reviewed.
03 / Guide
Let dependencies decide what is ready
An agent should never have to guess whether a task can start. Record blockers as links between tasks, and treat a task as ready only when nothing it depends on is still open. Then "take the next ready task" is a safe instruction to give any agent.
Keep acceptance criteria on the task itself. An agent that can read what done means can verify its own work before it hands back.
04 / Guide
Isolate the work, then verify it
- Give each agent its own branch or Git worktree, so parallel changes do not overwrite each other.
- Require the checks you trust (tests, type checks, a build) before an agent marks work as done, and record the result in the outcome.
- Keep a person reviewing what ships. Coordination stops duplicate work; it does not prove that the work is right.
Claims only help if every agent uses them. Put the workflow in your repository instructions (for example AGENTS.md or CLAUDE.md) so each new session follows it.
05 / Guide
Doing it with Theorem Praxis
Praxis builds this pattern into the tracker. next_task atomically claims the highest-priority ready ticket and skips blocked work. A claim has a 60-minute default lease. Releasing a claim requires an outcome, saved in the ticket thread, and GitHub branches, pull requests and merges can move tickets forward.
In Claude Code, the Praxis plugin adds /praxis:next to take work and /praxis:handoff to record the outcome and release the claim. Codex, Cursor, ChatGPT and other MCP clients use the same tools. See project tracking for Claude Code and project tracking for Codex.
Praxis is in beta and runs no AI model; your team keeps the AI apps it already uses. The AI agent project management guide explains when it fits a team.
FAQ
Common questions.
How do I stop two AI agents from working on the same ticket?
Make every agent claim a task before starting, with a claim that is atomic and expires. In Praxis, next_task does this in one step with a 60-minute default lease, so two agents using claims cannot hold the same work.
What should an agent write when it hands work back?
An outcome: what changed, what it verified and how, what it decided against, and where the next person or agent should start. Praxis requires an outcome before a claim can be released.
Do I need a special tracker for this?
No. The pattern works with any shared record that supports one owner per task. Praxis builds claims, leases, outcomes and dependency-driven ready work into the tracker so you do not have to enforce them by hand.
Sources
Primary sources
Sources reviewed 9 November 2026.