Multiple AI agents in one project: how to keep them out of each other’s way

Where conflicts come from

With one coding agent session, things are simple: one terminal window, one conversation and one task. When you run several sessions at once in the same repository, four kinds of trouble can appear:

• The same files. Sessions started in one folder work on the same files. One can overwrite the other’s work, and one session’s tests can fail because of the other’s unfinished changes.
• The same work. Two sessions got similar instructions, and both do the same thing, each in its own way.
• The wrong order. An agent starts work that needs the result of other work that isn’t finished yet. For example, it builds a screen that uses an API that doesn’t exist yet, and guesses what that API will look like.
• No overview. The tasks are in terminal windows and nowhere else. After an hour, it is hard to say which session is doing what and what is ready to check.

A separate folder for each session keeps the files apart. Two rules prevent double work and the wrong order: one session delivers one plan, and dependencies between plans show what can start right away. An overview comes from one place where those plans are written down.

Each session in its own folder

Give each session that changes code its own working copy. Git has the worktree for this: an extra working folder of the same repository, with its own files and its own branch, but a shared history. You create one with a single command in the project’s folder:

git worktree add -b backend ../shop-backend

A session started in ../shop-backend works on its own copy of the files, so its changes don’t reach other folders. By default, Git won’t let you check out the same branch in two folders at once, which is why each folder has its own. Later you merge the branch from each folder like any other.

A worktree is a fresh copy: it has no files Git ignores, such as .env, and no installed dependencies. Set them up in each folder separately.

A separate folder keeps the files apart, but it doesn’t say which session should do what. For that, you need plans.

One session, one plan

Write the agent’s task down as a plan: a short document that says what needs doing, what not to change and how to tell the work is finished. This approach, in which the description of the work comes before the code, is called spec-driven development. What to put in a plan so the agent doesn’t have to guess is covered in the post How to write a plan an AI agent can deliver without guessing.

One session takes one plan, delivers it and reports what it did. The next plan goes to a new session, or to the same one after its conversation is cleared. This rule gives you three things:

• A focused agent. The agent has one goal and one description of finished work in front of it, not instructions gathered over a whole day. The whole conversation so far goes to the model with every request, and a conversation about one task gets better answers and costs less.
• Clear acceptance. The finished work matches one plan, so you check it against what the plan set out.
• No double work. Each plan has one session delivering it, so two sessions won’t do the same thing.

A plan also needs boundaries: write down which part of the code it covers. The boundaries show whether two plans can run in parallel or one has to wait for the other.

Dependencies set the order

A dependency is one sentence: plan B waits on plan A. Until A is delivered, B shouldn’t start. The agent then doesn’t have to guess whether the work it needs is ready yet.

Dependencies also show how much work can run in parallel:

• Plans that wait on nothing are ready to start. Each of them can go to a different session.
• Plans that wait start once their predecessors are delivered.
• A plan that many others wait on is a bottleneck. It is the one to start with, because it unlocks the most work.

When you break the work down, aim for as many plans as possible that wait on nothing, and for short dependency chains. The more plans are ready at once, the more sessions have something to do. Even several AI agents won’t speed up a long chain, because each link waits on the one before it.

It is worth recording a dependency even when two plans don’t need each other’s results but change the same file. Otherwise their changes may collide when the branches are merged.

Step by step

1. Break the work down into plans. Each has one goal, boundaries and a description of finished work.
2. For each plan, write down what it waits on. Check which plans are ready to start.
3. For each session you want to run, create a separate folder and branch.
4. Give each session one ready plan.
5. When a session finishes a plan, check the work and merge the branch. See which plans have been unlocked, and give them to free sessions.

AI agent task management in featureloom

featureloom is a plan board you connect Claude Code, Codex or Cursor to through a remote MCP server. featureloom calls an AI assistant connected this way a console. AI agent task management there follows the steps above, except that plans and dependencies are written on the board, not in terminal windows.

• Plans and dependencies. A plan is a document on a kanban board. On the plan’s screen you unfold Dependencies, press Add dependency, choose Waits on… and find the plan it should wait on. featureloom won’t accept a dependency that would make two plans wait on each other. The Order screen shows which of an epic’s plans are ready to start, and the plan marked Bottleneck unlocks the most others.
• Ready-made prompts. Every new organization has the Planner and Realizer prompts. The Planner prompt tells the agent that one plan is one piece of work one agent session delivers whole, and to record the order as dependencies. The Realizer prompt takes the agent through one plan, from taking it on to reporting it delivered.
• The next ready plan. After the command featureloom realizer with no plan key, the agent asks featureloom for the next plan. From the column marked with the backlog state, it gets the plan that comes next in board order, one that waits on nothing and that nobody else is responsible for. A console won’t start a plan that waits: the server refuses and names the keys of the plans it still waits on.
• Two sessions, the same plan. Two consoles that ask for the next plan at the same moment may be offered the same plan, but just one of them takes it on. The other is refused with the name of the one working on it and can ask for the next.
• The predecessors’ work. A command with a plan key, such as featureloom realizer INV-15, gives the agent in one call the prompt, the whole plan and the documents of the delivered plans this plan directly waits on.
• Who is doing what. The card of a plan being delivered shows the person, their console and a short note the console may give itself. The Realizer prompt tells the agent to give it at the start: the session’s name, or the computer, repository and branch. When the agent gives the branch and each folder has its own, the card shows at once which folder the work is happening in.

Claude Code’s default connection is one console for every folder on your system account, so agents in each folder sign plans with the same name. To tell them apart, connect a separate console for each folder. In the menu, open Integrations, press Connect console on the Your consoles card and choose Claude Code. In the window, press Show advanced and copy the command with Copy the folder’s connect command. Paste it in an ordinary system terminal, not inside the Claude Code window, in the folder you run that console in, for example shop-backend. You can rename the new console, to backend for example, on the Your consoles card. Always start such a console in its own folder: started in another one, a subfolder included, it doesn’t see the connection.

You’ll find the details in the tutorials Your consoles and Epics and Order, and the page A team with several agents describes the whole team’s work.