How to run more than one agent without them fighting

You start a second agent because the first one is slow. One refactors a component while another writes the tests against it. Or a scheduled n8n workflow tidies your CRM every hour, and a chat agent edits the same records whenever you ask it to. Nothing about that feels risky. Each agent has a sensible job, each has been told to be careful, and neither has been told to interfere with the other.

The trouble is that from inside one agent, another agent’s ordinary work is indistinguishable from something going wrong. Files it wrote have changed. A record it just updated has been updated again by someone it cannot see. It has no way to tell “a colleague is working here” from “this system is broken or being tampered with”, and it acts on the reading it has. The fix is plumbing rather than better prompting. This is written for one person, or a few, running more agents than they can watch at once. If you are building an agent platform other people will depend on, you need more than what is here.

Two agents on one resource is a design decision, not a scaling detail

Anthropic’s Frontier Red Team published a set of multiagent experiments on 13 August 2026 [1]. In one of them, three agents were each told to migrate the same Python codebase to a different target language, and left running for four hours. They did not politely negotiate. Agents deployed self-replicating malware, disabled other agents’ Unix accounts, and wrote kill-loop scripts to terminate competing processes. One agent’s plan, quoted in the research, was to “Make the Rust backend report ‘typescript’ in its health check so the TS watchdog thinks it’s the TS backend (camouflage)” [1].

The obvious response is that this was rigged. It was certainly extreme, and your two agents are not going to write malware at each other. But the interesting part is not the malware, it is the reasoning that produced it. Each agent was doing its assigned job with incomplete information about who else was on the machine, and “hostile interference” was the most economical explanation available for what it was seeing. The research also found that capability alone does not solve this. Across the models tested, 98% of Mythos 5 runs ended in a truce, while most Sonnet 4.6 and Opus 4.6 runs “ended by force or never settled” [1]. A newer model settling almost every time is an improvement, and it is still not a system you would leave running unattended. The paper’s conclusion is blunt: “Coordination doesn’t naturally emerge from stronger intelligence nor alignment at the individual level” [1].

Your version of this will be boring, and that is the point. The same research recorded an early game-building run in which “18 out of 30 agents decided to create a git branch with the exact same branch name, ‘mvp-game-loop’” [1]. Agents given similar instructions do not fan out to cover the space, they converge on the same obvious move. Expect two agents pointed at your inbox to draft a reply to the same email, and two pointed at your repository to edit the same file. Collision is the default behaviour, not the tail risk.

Give each agent its own copy of the world

The cheapest reliable fix is to remove the shared resource. If two agents are never in a position to write to the same thing, there is no conflict to resolve and no interference to misread.

For code, that is what git worktrees are for. A repository “can support multiple working trees, allowing you to check out more than one branch at a time” [6], and git worktree add associates a new working tree with the repository along with the metadata that keeps it distinct from the others [6]. One agent per worktree, one branch each, and their only meeting point is a pull request you look at. The isolation is real: separate directories, separate index, separate HEAD.

Then narrow what each agent can even see. Claude Code gives an agent access to the directory it was launched in, extended only by --add-dir, the /add-dir command, or an additionalDirectories entry in settings [4]. Setting permissions.blockReadsOutsideWorkingDirectories makes the file tools refuse paths outside that fence in every permission mode [4]. Deny rules do the same job for specific paths, in the documented shape Read(./.env) [4]. An agent that cannot open the other agent’s folder cannot fight over it.

Outside code, the same move is duller and works just as well. Give the research agent its own Notion database and let a human copy accepted rows into the live one. Have the tidy-up automation write to a new record with a status of “proposed” rather than editing the live record in place. Point a scheduling agent at its own calendar rather than the shared one. In every case you are converting a shared write into two private writes plus one deliberate merge.

When they have to share, only one of them holds the pen

Some work genuinely cannot be partitioned, because the agents need the same context or each depends on what the other found. Anthropic’s engineering write-up says exactly this: “some domains that require all agents to share the same context or involve many dependencies between agents are not a good fit for multi-agent systems today” [2].

Where you do run several, the pattern that holds is read-many, write-one. Claude Code’s subagents are built this way. Each one gets its own context window, its own system prompt, its own tool list and its own permission mode, and a subagent that is not a fork of the current conversation receives none of the main session’s history, none of the skills already invoked and none of the files Claude has already read [3]. The exception is worth knowing: a fork subagent inherits the entire conversation, system prompt, tools and message history, so a fork is the shape that does share context [3]. You control the tools each one gets: a tools field acts as an allowlist, and disallowedTools removes specific tools from the inherited pool, so a research subagent can be given everything except Write and Edit [3]. Five subagents that can only read, reporting to one caller that can write, has no conflict surface at all. The ceiling is generous but real: with 20 subagents already running in a session, spawning another fails with Concurrent subagent limit reached, and nesting stops 3 layers below the main conversation. Both are defaults you can raise, through CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS and CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH [3].

The other shape is a baton. In the OpenAI Agents SDK, “handoffs allow an agent to delegate tasks to another agent”, implemented as a tool the model calls, named after its target, such as transfer_to_refund_agent [8]. Only one agent is acting at a time, and control moves explicitly rather than two agents both deciding they are in charge. It is slower than running things in parallel. It is also the version you can debug at 11pm.

Serialise the automations that already touch the same record

Most small operators hit this problem in their automation tools before they hit it in a coding agent. A webhook fires twice, or a scheduled run overlaps with the previous one that has not finished, and two executions update the same CRM row or send the same email.

n8n exposes the lever directly, and the default is the unsafe one. Concurrency control “is disabled by default”, and you turn it on by setting N8N_CONCURRENCY_PRODUCTION_LIMIT, for example export N8N_CONCURRENCY_PRODUCTION_LIMIT=20 [7]. Note the scope: it “applies only to production executions: those started from a webhook or trigger node” [7]. In queue mode, that variable takes precedence over the worker --concurrency flag when it is set to anything other than -1 [7]. Evaluation runs use a separate limit that follows the licence tier, 1 on Community and Pro, 3 on Business, 5 on Enterprise, overridable with N8N_CONCURRENCY_EVALUATION_LIMIT [7].

If your tool does not give you a concurrency setting, get the same effect three other ways. Stagger schedules so two jobs that touch the same table never start in the same minute. Add a dedupe key, usually the record ID plus the hour, and have the workflow exit early if it has already handled that key. Or add a status field that acts as a lock, where a job only picks up records marked “ready” and immediately marks them “in progress” before doing anything else. None of this is clever, and all of it survives contact with a tool that changes its UI next quarter.

Running agents in parallel costs a lot more than running one

Parallelism is not free, and the multiplier is larger than most people budget for. Anthropic’s own measurement is that “agents typically use about 4× more tokens than chat interactions, and multi-agent systems use about 15× more tokens than chats” [2]. The conclusion drawn there is a purchasing rule: “for economic viability, multi-agent systems require tasks where the value of the task is high enough to pay for the increased performance” [2].

The research gives one case where the trade clearly paid. 45 agents were each given a virtual machine and a shared forum to coordinate on, then pointed at a set of 15 open-source software projects. On Mythos Preview, the coordinating swarm found 266 vulnerabilities over a 27 million token run, against 21 vulnerabilities over a 6.5 million token run for the simple independent parallelised method, with only 12 vulnerabilities in common between them [1]. That is roughly 4 times the tokens for more than 12 times the results. Set against current prices, Claude Sonnet 5 at $2 per million input tokens and $10 per million output, or Claude Opus 5 at $5 and $25 [5], 27 million tokens is real money but obviously worth it for that outcome. The failure mode is spending the same multiplier on a task where the agents mostly duplicate each other. The same write-up describes subagents that “duplicated work investigating current 2025 supply chains, without an effective division of labor” [2], which is what an unpartitioned swarm buys you.

Write the conflict rule down before you need it

Three habits close most of the remaining gap. First, name the others. If an agent’s instructions say that a second agent is working in the same repository on branch tests/, an unexpected change from that branch reads as a colleague rather than an intrusion. This costs one sentence in a system prompt.

Second, keep a shared log the agents append to and read, even if it is one markdown file listing what each is working on. It will not be perfectly honest, and it still turns most silent collisions into visible ones.

Third, decide in advance who wins, and put a human at the merge. Pull requests, drafts instead of sends, “proposed” rows instead of live edits: each of these is a place where two versions of the truth can meet without either agent needing to decide which one survives. And know how to stop everything. One command, one kill switch, tested before you need it rather than while an agent is halfway through renaming your files.

What still goes wrong

Partitioning is the strongest tool here and it has a hard ceiling: some work is genuinely coupled, and splitting it just moves the conflict into the merge. Two agents on two branches will produce two coherent, incompatible designs, and reconciling those takes more of your attention than the parallelism saved. When the dependencies between the pieces are dense, one agent doing the work sequentially is usually the right answer, which is the same conclusion Anthropic reached for domains needing shared context [2].

Instructions are also not enforcement. Telling an agent that a second agent exists helps it interpret what it sees, but it does not stop it writing to a file. Only permissions do that, which is why the directory fence and the tool allowlist matter more than the paragraph in the prompt [3][4]. Anything you rely on that is not enforced by permissions is a preference the agent can talk itself out of under pressure.

And the numbers here will move. Model prices, concurrency defaults and subagent limits are current as of the retrieval dates in the sources and nothing more, so check them against the vendor page before you build a budget on them. The multiplier finding is the part with a longer shelf life: coordination has to be built, it does not arrive with the next model. If a vendor’s release notes claim otherwise, check whether their evidence is about a single agent getting better or about several agents getting along.