How to Run Multiple Coding Agents

Give the agent one named task, only the context it needs and a check you can rerun. A task shaped this way produces a diff small enough to review and a result you can repeat.

Each move fails in its own way. Without a boundary, the agent edits files you never meant to open, and the diff becomes hard to read. Thin context fails more quietly: the code compiles and the tests pass, but the change ignores patterns the rest of the repo follows. Without a check you can rerun, you are taking the agent's word that the work is done.

Asking for a plan before the agent writes code is the easiest step to skip. It means a short wait while nothing visible happens, and the price of skipping it shows up later, in review.

If the plan names files you didn't expect, you learn that before any code exists. If it names the right files, you have a list to check the diff against. Once four hundred lines of diff are on screen, changing the approach means throwing that work away.

The habit that matters most for a team is leaving a trail the next reviewer can follow. The steps below keep the prompt and its proof attached to the change.

1. 1Pick one real backlog item with a clear owner and expected result.
2. 2Add only the context the agent needs: files, failing output, constraints and done state.
3. 3Ask for a plan before code when the task touches more than one file.
4. 4Run checks that match the risk: unit test, typecheck, visual pass or review checklist.
5. 5Capture the prompt, diff, result and reviewer note so the workflow can be repeated.

Match the effort to the change. A one-file fix needs a clear done state and a typecheck, and a plan adds little. A change across several files is where a plan pays for itself, and where the check should include tests and a reviewer who knows that code.

Keep whatever lets someone rerun the work or pick it up later. A finished task is the merged code plus a short trail that shows how it got there.

• The prompt or plan that shaped the work.
• The files changed and the reason each file changed.
• The command, screenshot or review note that proved the result.
• The rule, checklist or template you would reuse next time.

The last item pays off over time. A rule or template saved from one good run means the next run starts from what already worked, not from a blank prompt.

The two split by intent. One agent per task fans out across separate jobs, so more gets done at once. Best-of-N on one task points several models at the same problem and compares their answers. Choose by whether you want coverage or a better single answer.

Run several models when the answer is worth more than the spend. For a payment issue tied to a specific user, the presenter of Cursor's workshop for product managers started a multi-agent run with four or five models on the same problem at once. At the time, they were ComposerCursor's own fast coding model, tuned for the editor and priced well below frontier models; the recommended day-to-day model for executing a plan. Press Enter for the full definition. 1, Claude 4.5 Opus, Sonnet and GPT-5.1, and each ran many searches against the logs through the Datadog MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. Press Enter for the full definition.. GPT-5.1 stopped early, and comparing what the others found was enough to debug the issue fully.

Check your plan before you copy this or the CLI setup below. Free and Plus don't include third-party models such as Claude and GPT, and on Premium and above they bill at the model's API list price.

Open several terminal tabs and start an agent in each, in the same directory. Use a different model in each tab: Cursor's in-house ComposerCursor's own fast coding model, tuned for the editor and priced well below frontier models; the recommended day-to-day model for executing a plan. Press Enter for the full definition. in one, a GPT-5.x model with a chosen reasoning level in another and Opus 4.x in a third. Give all three the same task, and you get three competing implementations side by side. Because the agents share one directory, make sure each one writes to its own files. If their work could overlap, start each one with agent --worktree instead, so each agent edits its own checkout.

In the CLI, ⇧+⇥ rotates between the Agent, Plan and Ask modes. In the IDE, you create new chats and manage them through history, or run /best-of-n, which runs the same task across several models and gives each run its own worktree.

# tab 1
agent  # Composer (in-house, fast)
# tab 2
agent
/model  # -> GPT-5.x, reasoning: high
# tab 3
agent
/model  # -> Opus 4.x

# then paste the same prompt into all three:
# "use your best judgment and build the best bot; name it after your model"

Yes, and it turns a support engineer into an orchestrator instead of a serial worker. Start many agents at once, one per ticket: one on "how do I log in with SCIMSystem for Cross-domain Identity Management. A standard for automatically creating and removing user accounts when people join or leave. Press Enter for the full definition.", another on "what does the analytics dashboard show". Review the work as it streams in, and step into each agent individually with little context switching. A member of Cursor's support team described this pattern in a workshop, saying time is the team's scarcest currency. Parallel agents keep one person moving through a steady volume of tickets instead of waiting on a single agent to finish.

It depends on whether their outputs can collide, not on how many agents are running. In the best-of-NSampling a model N times and keeping the best answer. During Composer 2's RL, best-of-16 on a held-out set and best-of-4 on CursorBench rose along with the average, which Cursor's report takes to suggest RL also widened the set of correct solutions. Press Enter for the full definition. example above, the prompt told each model to name its bot after itself. The three agents shared one checkout, wrote three different files and never touched each other's work.

Point the same three agents at "fix the checkout bug" and they edit the same file in the same working tree. Each agent's uncommitted edits become part of what the next one reads, and you spend the afternoon untangling a tree that three agents wrote to at once. A worktree gives each agent its own checkout: run /worktree in the IDE, start the agent in a worktree from the Agents WindowCursor's surface listing your agent runs; open a run to read its diff and search transcripts from the command palette. Press Enter for the full definition., or pass --worktree to the CLI. That separates more than a branch does, because branches in one checkout share a working tree.

So the test is whether two agents can write to the same path. When you are not sure, treat the answer as yes.

Merge the branch that touches shared code first. The other branches then rebase onto a settled base while you still remember what each agent was doing. Leave it until last, and every other branch needs another review after the rebase, because the diff you approved is no longer the diff that lands.

On a three-person team, you can keep this in your head. That stops working once the agents' owners are no longer all in the same conversation, and the merge order has to be written down. We prefer a fixed rule to a judgment call per branch. No source we found puts a number on the team size where the switch happens.

It depends on what comes back. A support agent hands back an answer you can judge in the time it takes to read it, so one person can keep a queue of tickets moving. A branch is different work: you read the code and run the check, and only then do you know whether the agent was right.

Design around that difference. Where the output is prose or a diagnosis, fan out wide and review results as they stream in. Where the output is a diff against production code, the limit is the number of diffs you will open and read. Every agent past that number adds to a queue that nobody is reviewing.