The real problems with managing multiple coding agents

Managing is hiding four separate problems

Search for how to manage multiple coding agents and you get tool roundups. That is the wrong shape for the question. The four things that go wrong have four different answers, only one of them is something you install, and the most expensive one is the one roundups never reach.

In the order they usually bite:

• Two agents edit the same file and one quietly undoes the other.
• You cannot tell which of them is waiting on you without checking each one.
• The reasoning dies with the pane, so tomorrow you explain the project again.
• Every agent you started can reach every credential you have.

One: they overwrite each other, and nothing errors

Two agents in one checkout will eventually write the same file. There is no conflict marker and no failure, because neither of them is doing anything wrong. One rewrites what the other already fixed, and you find it at review time if you find it at all.

The free fix is a git worktree per agent. Git will hand one repository several checkouts, each parked on its own branch in its own directory, and two agents pointed at two of those have no route to each other's files. It costs one command and nothing else, and several agents now ship a flag that runs it for you. Do this before you evaluate a single tool.

The half people miss is that this is only the disk. Two agents can still pick up the same piece of work, because that collision lives in the plan rather than in the files. What answers it is a backlog that hands a task to one agent and marks it held.

In Forkbench a piece of work is a Thread, and a Thread carries its own folders, its own notes, its own keys and its own board. An agent claims a task off that board and the claim is a lease, so the next agent to look sees it taken and picks something else. The worktree and the lease answer different halves of the same collision.

Two: you cannot tell which one is stuck

Nothing on a row of terminal tabs tells you which one has stopped. So you go through them one after another until you find the one holding a question, and the ones you checked first are still waiting by the time you get back. The cost is not the checking. It is that an agent parked on a yes-or-no answer is doing nothing at all, and nothing told you.

The free fix is naming. Name each pane after the branch it is working, or use tmux windows with real names, and at least you know what you are looking at before you look. It is crude and it earns its keep on day one.

Two numbers decide whether a setup survives being scaled: the delay between an agent going quiet and you noticing, and what it then costs to work out which one it was. Anything that shrinks both earns its place. Anything that shrinks neither is decoration.

A Thread reports which of its panes is blocked, so both halves of that test are a glance instead of a search. Talk carries the same conversations into a browser or onto a phone, which matters because most of the waiting happens while you are somewhere else.

Three: the work dies with the pane

Half an hour of an agent reading a codebase produces something valuable: an ordering, a set of assumptions, a list of approaches it discarded. All of it lives in the conversation and nowhere else. Compact the context or close the pane, and the ordering is gone while the code it was about is still there.

Add a second vendor and it compounds. Each agent files what it learned in a private format no other agent opens, so the reasoning travels between vendors about as well as it travels across a restart. You end up keeping one brief per vendor, which is the retyping you were trying to stop doing.

The free fix is a habit rather than a purchase. Make the first instruction of any job be to commit a short file saying what the agent intends to do, what it is taking for granted and what it has ruled out. The next agent reads it, a different vendor's agent reads it, and so do you in a fortnight when none of you remembers.

The tooled version is that habit with the filing done for you: notes and a backlog sitting outside every conversation, updated by the agents as they go, with nothing on a task saying which vendor is allowed to pick it up. A Thread holds exactly that. We build it, which is a reason to go and look rather than a reason to believe us.

Four: every agent has the same reach into every key

This is the one that is not a coordination problem, which is why the coordination tools do not touch it.

Give four agents four worktrees and you still have four processes running as you, with your shell, your dotenv and your tokens. The isolation you just built is about files, and a credential is not a file problem. Separate checkouts are also meant to carry your secrets, which Anthropic documents plainly: a worktree starts as a fresh checkout so untracked files like .env are missing from it, and .worktreeinclude is the supported way to have them put back every time.

It sharpens when the jobs are unrelated. The agent tidying up a side project has exactly the same reach as the one deploying the application you get paid for, because reach comes from running as you and not from what you asked for.

Be precise about why this one is different. The first three problems all end in something you can put back: a branch you throw away, a plan you write again, an hour you lose. A credential does not work that way. You can revoke it, and revoking does nothing about the copy that already landed in a transcript, a log or somebody's scrollback. It is the only one of the four where noticing sooner barely helps.

The free fix is scoping. Give each agent a credential of its own, with the narrowest permission that still lets it finish and the soonest expiry you can tolerate, so anything that escapes has a small blast radius and a deadline on it. If you take one more thing off this page after the worktrees, take that.

The version that removes the problem instead of bounding it is to stop handing the value over at all. A Thread holds the keys that job needs, and an agent working in it runs the commands that need them without the value reaching its prompt, its command line or its transcript. The agent gets the answer back. It never gets the key.

The limit in the same breath, because it matters. An agent in a terminal has the filesystem access you have, so it can still read a .env you left sitting in the project. Forkbench governs what Forkbench holds, not your machine. Moving the key out of the file is a thing you have to do once, and nothing does it for you.

Why the roundups do not answer this

Almost every page written about managing multiple coding agents answers problem one, sometimes answers problem two, occasionally mentions problem three, and stops. That is not dishonesty. It is that the first two are the ones a tool comparison can settle, and the last one is not a feature any of the tools being compared has.

So read them for problem one and take the rest deliberately: a worktree per agent, a plan written outside every conversation, a name on every pane, and a credential the agent uses rather than holds. The count of agents appears in none of them.