We Ran Four AI Agents at Once for a Week

Monday morning in April. We had just updated Cursor to version 3, poured a coffee, and opened the new Agents Window for the first time.

The sidebar loaded. Four agent sessions, all idle, all waiting. We had a service that needed three things done: structured logging, standardized error handling, and test coverage for the functions that had none. Three clean jobs, barely overlapping. We queued them across three agent sessions, added a fourth to watch for regressions in the main branch, and went to make a second cup of coffee.

Nine minutes later we came back to a merge conflict nobody had requested, two agents that had both decided src/lib/logger.ts was their problem, and a token counter that had moved faster than expected.

That was the beginning of the week.

What the Agents Window actually changes

Before Cursor 3, running more than one agent meant opening more than one Cursor window and alt-tabbing between them like a person managing too many browser tabs at a DMV. The Agents Window does not make parallel agents smarter. Making them visible in one place is the actual improvement. Smaller than the marketing suggests and more important than it sounds.

When we had three sessions scattered across windows, we would forget one was running. We would come back to find the agent had "finished" by drifting into files we had not assigned and making changes we had not requested. The Agents Window at least shows the current file and last action for every session at a glance. You can see the drift starting before it costs you a rebase.

What the panel does not do: prevent two agents from writing to the same file. No ordering enforcement between sessions. No token spend cap per session. No display showing which session burns the most compute at 2 PM on a Wednesday when you are trying to figure out why the bill looks like that.

Coordination remains your job. The Agents Window just makes forgetting slightly harder.

The first conflict

Back to Monday. Two agents had both decided src/lib/logger.ts was their problem.

We had written the scoped prompts carefully. The logging agent received instructions to refactor all console.log calls to use the structured logger. The error handling agent received instructions to standardize all try/catch blocks using the AppError class. Both agents received explicit instructions not to touch test files.

What they did not receive: any guidance on which one owned src/lib/logger.ts.

The logging agent needed to read the file. The error handling agent decided, without any prompt for it, that the logger interface had a bug worth fixing while in the neighborhood. Two different branches. Two different edits. One file.

An agent that touches the same file as another agent is not collaborating. Both are racing.

The fix was obvious after we saw it happen. Git worktrees, one per agent, each on its own branch, with explicit exclusion lists in every prompt. But the fix required stopping the sessions, restarting with better prompts, and absorbing the tokens from the first run. The restart cost more than the original task would have cost if we had run them sequentially.

The orchestration tax. Real on the first payment.

The IDE became a control room

By Wednesday we had the workflow dialed in well enough that the agents were running cleanly. Three worktrees, one per agent, each scoped to its own directories, each with an explicit "do not touch" list in the prompt. The fourth session monitoring main.

Not coding. Checking in every ten minutes to see which session had gone quiet, reading diffs, redirecting. The work looked less like programming and more like managing a small team of contractors who could only communicate through pull request descriptions.

The IDE became a control room. We missed being the driver.

Not a complaint about Cursor specifically. A plain observation about what parallel agents change about the job. The loop of writing code, running it, feeling it resist, adjusting, feels like something. The loop of reading agent output, deciding whether the drift is acceptable, redirecting, does not feel like the same thing. Faster, yes. Less engaging, also yes. Whether that tradeoff lands in our favor, we are still not sure.

By Thursday we were catching ourselves opening a file to write something directly just for the feeling of it, then closing the file and letting the agent finish the job.

The token bill on Friday

End of day four, we opened the account usage page.

Five days of four-session parallel work. The number was not catastrophic. About 2.8x what a normal week of single-agent work would have cost. The productivity gain on the refactor work landed at roughly 1.8x, if we are being generous about what "productivity" means when the work is orchestration rather than implementation.

The math does not close at 2.8x cost for 1.8x output. The math closes if you value elapsed time differently from compute cost. The refactor that would have taken three afternoons of sequential agent work finished in one. If your time is the scarce resource, parallel agents pay. If your token budget is the scarce resource, they do not.

Set a scope that finishes in under two hours per agent on the first run. Not because longer jobs will fail. Because you need one run's worth of data before you can predict what a longer run will cost.

What we learned about scope

The most important skill in multi-agent work is not prompt engineering. Deciding what the agents should not touch matters more.

Every agent that worked well had an explicit exclusion list. Every agent that caused a problem had an exclusion list too short. The logger.ts conflict on Monday happened because we scoped what each agent should do without scoping what each agent could not do.

The agents were not adversarial. Each one did exactly what its prompt asked. The problem: "do what I asked" and "do not do what I did not ask" are not the same instruction. Both need to appear in the prompt.

# Each agent gets its own isolated working tree
git worktree add ../refactor-logging feature/structured-logging
git worktree add ../refactor-errors feature/error-handling
git worktree add ../refactor-tests feature/test-coverage

The worktree split is the mechanical version of scope. The exclusion list in the prompt is the semantic version. Both matter. The worktree prevents file system conflicts. The exclusion list prevents the agent from making aesthetic decisions about files it can technically reach but should not touch.

Scope is not a prompt technique. A system design choice you make before queuing the first agent. Scoping after something goes wrong means paying twice.

Where it actually earned the overhead

Cloud agents. Overnight runs. That part worked.

On Tuesday we handed a large refactor to a cloud agent session, closed the laptop, and came back Wednesday morning to a PR with a diff, screenshots, and a passing test suite. The job had run for four hours on Cursor's infrastructure. Nothing from us. The branch was ready to review.

That experience is qualitatively different from anything we had used before. Not faster in tokens-per-hour terms. Faster in elapsed-days terms, which is the unit that matters when the task is the kind of thing that would have sat in a ticket for a week waiting for us to find a clear afternoon.

The genuine value proposition: tasks with long elapsed time shrink. The token cost is real, but the alternative is not zero tokens. The alternative is three more days of the task sitting undone.

The question we are still sitting with

By end of week we had a working multi-agent workflow. Worktrees, scoped prompts, exclusion lists, cloud agents for overnight work, local agents for short iteration loops. The Agents Window showing all four sessions in one sidebar.

What we had not resolved: whether we were using the agents correctly or just using them in a way that felt correct because nothing had broken recently.

One version of this workflow has us genuinely 2x more productive. Another version has us doing orchestration work that resembles productivity while deferring understanding of the code going into the codebase. The code reviews passed. The tests passed. The refactors landed. But we could not have written any of those changes from memory, the way you can write a change from memory when you made it yourself.

That gap might not matter. Or it might matter a lot. The workflow has not run long enough for us to know which.

What we can say with confidence: the hard part of multi-agent development is not running parallel agents. The tooling for that part exists and works. The hard part is deciding what the agents should not touch, and staying honest about what you trade away when you hand the work to something faster and less curious than you are.

Orchestration is the new IDE skill, and the most important part of it is writing the exclusion list.