Multi-agent and multi-staging: why one does not work without the other

Parallelism, first. While one agent fixes a bug, another writes a page, a third updates a dependency. As long as these tasks do not touch the same files, the total time gets closer to that of the longest task, not their sum.

A clean context per task, next. An agent's context window degrades as it fills up. Three agents each carrying one task work better than a single agent chaining three in the same conversation.

A fresh pair of eyes, finally. Separating the agent that writes from the one that reviews mirrors what colleagues do: the review comes from someone who did not make the decisions and has no reason to defend them.

The published figures point the same way, with their price. In June 2025, Anthropic described its multi-agent research system: a lead agent (Claude Opus 4) delegating to subagents (Claude Sonnet 4) outperformed a single agent by 90.2% on its internal research eval. The same article states that such a system uses about 15 times more tokens than a chat, and that most coding tasks lend themselves less to parallelism than research does.

Several agents in the same folder step on each other. One edits a file while the other reads it, one switches branch under the other's feet, two dev servers fight over the same port, two test suites write to the same database. The result is not a clean error: it is code that seems to work, but not for the reason you think.

Implicit decisions contradict each other. Cognition, the maker of Devin, put it plainly in June 2025 in an article titled "Don't Build Multi-Agents": actions carry implicit decisions, and conflicting decisions carry bad results. Two agents each building half of the same feature, without seeing the other's work, pick two different conventions.

Verification becomes the bottleneck. A human reviews one diff at a time. If five agents produce five diffs, and the only way to see them running is to merge them one by one into a shared staging, the speed gain stops at the staging door, or worse, things get merged without being seen.

Code isolation, first, with git worktrees: separate working copies of the same repository, each on its own branch, sharing the history. Claude Code creates them itself (claude --worktree task-name, or isolation: worktree for a subagent), under .claude/worktrees/, and blocks edits aimed at the main checkout. A worktree is a fresh copy: dependencies get installed there, and a .worktreeinclude file copies untracked files such as .env.local into it.

Runtime isolation, next, with one preview environment per branch. On Vercel, where this site is hosted, every push to a branch other than the production branch creates a preview deployment, with two addresses: a branch URL, which follows the latest commit, and a commit URL, which is frozen. Every agent branch therefore has its own running site, opened without installing anything, and which Vercel does not expose to search engines by default.

Data and secrets isolation, finally. Environment variables are defined per environment, and even per branch for previews: an agent branch points to a test database and test keys, never to production ones. Some managed databases can create a data copy per branch; failing that, a shared, resettable test database is enough for most SMEs.

Above the previews, a shared staging keeps its role: checking that the merged branches hold together. Vercel allows it on every plan with a staging branch that has its own domain, or, on Pro and Enterprise plans, with a custom environment (one included per project on Pro). And for the last check, a production deployment can be built then promoted by hand, without rebuilding.

Here is the path we use, and the one this article followed. A ticket describes the expected outcome and its acceptance criteria, including a test command. A writer agent receives the ticket in its worktree, on a branch named after the ticket number.

The agent works, then runs the check itself: on this site, npm test chains the type check and the full build. While it fails, the agent fixes; after a number of attempts set in advance, it stops and hands over to a human rather than going round in circles.

The pushed branch produces its preview. A second agent, or a person, reviews the diff and opens the branch URL: does the page render, does the link work, does the text say what it should? This reviewer did not write the code, and judges a running site, not a description.

Merging into the main branch remains a human decision, and it alone triggers the production deployment. Meanwhile, other agents have done the same on other tickets, each in its own lane. The shared staging only sees what has already passed these steps.

One agent, one task, one branch. Not two agents on the same branch, not one task split between agents that would have to agree along the way. If two parts of a feature depend on each other, they go to the same agent, or they are done one after the other.

Narrower rights than a developer's. An agent never pushes to the main branch, never deploys to production, never writes to anything but a test database. These bans are written into the repository's permissions and branch protection, not only into an instruction.

A definition of done that does not come from the agent. Acceptance criteria are set in the ticket before the work, and the preview shows the result. "Done" means the tests pass and someone has seen the page, not that the agent says so.

No more agents than review capacity. The right number of parallel agents is not what the machine can handle, it is how many diffs the team can review within the day. Beyond that, branches pile up, drift from the main branch, and merge conflicts eat the time saved.

Housekeeping. Worktrees, branches and preview deployments pile up quickly. Delete the branch after merging, and let the tools remove clean worktrees.

If you do not yet have one agent that works well on its own. Several agents multiply what one agent does: good habits and bad ones alike. The CLAUDE.md, the plan before writing and the test the agent runs itself come first.

If the tasks are not independent. A redesign touching the same component everywhere, a schema migration followed by its data-access code: that is a single thread, and splitting it creates exactly the conflicting decisions described above. One agent, for longer, with a good plan, does better.

If nobody can review. An SME with a single developer already gains a lot with one agent and a preview per branch. Multi-staging helps from the first agent; multi-agent, once the queue of independent tickets grows longer than their day.

And if cost is not watched. Each agent consumes its own tokens, and custom environments beyond the included one are paid in packs. That is not a blocker, but a cost to weigh against the time saved, measured on your own tickets.

Anthropic, "How we built our multi-agent research system", 13 June 2025: Claude Opus 4 lead agent and Claude Sonnet 4 subagents, +90.2% over a single agent on the internal eval, about 15 times more tokens than a chat, fewer parallelisable tasks in coding than in research. Anthropic article.

Cognition, Walden Yan, "Don't Build Multi-Agents", 12 June 2025: share full context, and the principle that actions carry implicit decisions. Cognition article.

Claude Code documentation: parallel sessions with worktrees (--worktree, .claude/worktrees/, subagent isolation, .worktreeinclude, cleanup, blocking edits to the main checkout). Worktrees, Common workflows.

Vercel documentation, Environments (updated 17 September 2026): Local, Preview and Production environments, a preview deployment per branch, branch URL and commit URL, variables per environment and per branch, branch-based staging on every plan, custom environments on Pro and Enterprise (one included per project on Pro), manual promotion of a production deployment. Environments.

The flow described in the fourth section is ours; it is not a vendor recommendation.