How do I manage multiple AI coding agents without losing track?
Managing multiple AI coding agents comes down to four disciplines — give each session an isolated worktree and a single owned task, keep one prioritized queue outside the agents, decide in advance which actions stop for human approval, and verify completion against criteria written before the work started. Most of the pain people report is one of these four missing, not the agents themselves being bad.
Running one coding agent is straightforward. Running four is a different activity, and most of the difficulty is not about the agents at all — it is about everything around them.
Here is what actually goes wrong, and what to do about each.
Give every session its own worktree
The first failure is physical. Two agents editing the same checkout will overwrite each other, and the damage is often silent: one session’s uncommitted work disappears into another’s commit, and nobody notices for a day.
Use a separate git worktree per concurrent session. One branch, one working directory, one agent. Sessions can then run in parallel without any coordination protocol at all, because there is nothing to coordinate — they cannot see each other’s files.
Two rules make this hold:
- Never let an agent work directly on your main branch. It is the one checkout every other session’s base depends on.
- One live session per worktree. Two agents in one directory is the original problem wearing a disguise.
Give every session exactly one task it owns
The second failure is scope. An agent given “improve the onboarding” will touch twelve files, three of which another session is also touching. An agent given “make the empty state explain what to do next, with a test” will not.
A task is well-formed when it names one outcome, states how you will know it is done, and can be finished in one sitting. If you cannot say what “done” looks like, that is not a task yet — it is a topic, and splitting it is the actual next step.
This is also the cheapest fix available. Most people’s throughput problem with agents is not model quality; it is that the work arrives underspecified and the agent spends its budget guessing.
Keep one prioritized queue, outside the agents
The third failure is the expensive one. With several projects in flight, the question “what should I work on next?” gets answered by whichever tab is open, whichever bug is loudest, or whichever session happens to be idle. None of those correlate with what matters.
The queue has to live somewhere the agents do not, for a simple reason: an agent’s context ends when its session does. If priority lives in the conversation, it dies with the conversation, and you rebuild it from memory tomorrow.
What a usable queue needs:
- one ordered list across every project, not one per repository;
- a reason attached to the order, so you can tell whether it is still true;
- dependencies recorded, so blocked work does not surface as available;
- an explicit next action, phrased as a verb, for whatever is at the top.
That last point matters more than it sounds. “Improve performance” at the top of a queue means the decision gets made again every morning. “Add an index on events.created_at and measure the query” does not.
Decide in advance what stops for you
The fourth failure is trust, and it goes wrong in both directions. Supervise everything and you are a full-time reviewer of your own project. Supervise nothing and you eventually find out an agent spent real money, deployed something, or rewrote a file you cared about.
The way through is to draw the line in advance rather than per-incident. Decide which categories of action always stop and wait — spending, deploying, anything irreversible, anything touching production data, anything that changes what agents themselves are allowed to do — and let everything else run.
Written down, that line becomes something a system can enforce. Held in your head, it becomes something you re-litigate every time you are tired.
Verify completion against criteria written beforehand
The fifth failure is the subtle one. An agent’s report of its own work is not evidence. It is a summary produced by the same process that did the work, and it is confidently wrong at roughly the rate the work is wrong.
The fix is cheap and almost never done: write the acceptance criteria before the work starts, and check them afterward against something observable — a passing test, a command that exits zero, a page that renders. “Done” then means the criteria were met, not that the agent said so.
This also has a pleasant side effect. Criteria written in advance are much better task specifications than the task description usually is, which improves the work as well as the verification of it.
What this looks like when it is working
A day with four agents running should feel less busy than a day with one, not more. You should be answering questions that need judgment — is this still the right priority, is this trade-off acceptable, should this ship — and not questions like “which branch was that on” or “did that actually finish.”
If most of your time goes to reconstructing state, the problem is not the number of agents. It is that the state was never written down anywhere outside their sessions.
Where Arcadia fits
Arcadia Mission Control is a system built around exactly these five disciplines: isolated sessions with one owned action each, a single prioritized queue with reasons attached, approval gates decided in advance, and completion checked against criteria written beforehand.
It is experimental and in active development. Today it governs its own development, which is a real test but not yet a product anyone else can install. If the problems above are your problems, the signup form asks how you actually hit them — and those answers decide what gets built.
Arcadia Mission Control is the system described above. It is experimental, in active development, and has no customers yet — early users are helping decide what it becomes.
Last reviewed 2026-09-22.