Running Multiple AI Agents: What Actually Collides When They Share a Machine

Every guide about running more than one AI agent assumes you are sitting there watching them. Five coding agents in five terminal tabs, a supervisor pane, a merge queue. That is a real workflow, and it is not the one most people end up with.

The agents that matter in a business are the ones nobody watches. A blog agent that publishes at noon. A social agent that stages drafts in the evening. A monitoring agent that checks a page every morning. They run on a schedule, they finish, and you read what happened over coffee.

Those agents break each other in ways the parallel coding write-ups never mention, because the failure is not "two agents edited the same function." It is "the second one took the clipboard while the first one was reading from it," and the error message points somewhere else entirely.

I have been running scheduled agents across a handful of products for months. This is what actually collides, how I space them out, and why the orchestrator agent everyone reaches for first is usually the wrong tool.

Do you actually need multiple AI agents, or one agent doing more?

Start here, because the honest answer is often one.

Anthropic published the engineering behind its own multi-agent research system, and the number in it is worth sitting with. Multi-agent setups use roughly fifteen times more tokens than a chat, and even a single agent using tools already uses about four times more. Their write-up on building a multi-agent research system is direct about the tradeoff. Multi-agent works when the task is genuinely parallel and valuable enough to pay for. It is a poor fit when the agents have to share context or depend on each other's output.

That second half is the part people skip. If your two agents need to know what the other one did, you do not have two agents. You have one agent with a handoff problem.

The split that does work is by role and by clock. One agent owns publishing. One owns outreach. One owns monitoring. They never need to agree about anything, because they touch different work at different times. That is not orchestration. That is a staff roster.

My test before adding a second agent: can I describe its job without mentioning the first one? If I cannot, it is a step inside an existing routine, not a new hire.

What actually collides when two AI agents run at the same time

Two agents on one machine share more than you would guess. Five things, in the order they have actually bitten me.

The account. Rate limits are enforced at the organization level, not per key and not per project. The rate limit documentation spells this out. Every agent you add draws from the same pool. Two heavy runs starting in the same minute do not each get a full budget. They get part of one each, and then one of them starts seeing rejections that read like a bug in that agent.

The browser session. If your agents drive a real browser, they share one logged-in profile. Two agents on the same site at the same time means one of them is reading a page the other just changed. This is the worst one, because it produces plausible wrong results rather than errors.

The clipboard. The operating system has exactly one. Any routine that copies something and reads it back a moment later is holding a resource every other process on the machine can overwrite.

State files. Ledgers, logs, published-item lists, the record each routine appends to when it finishes. Two writers, one file, and whichever finishes second wins.

The repository. Two agents committing to the same branch in the same window produce a rejected push, and an agent that does not handle that gracefully will either stop or, worse, force it through.

The collision that taught me the pattern

One of my publishing routines copies an image payload to the clipboard, then reads it back inside the browser to upload it. It ran that way for weeks. Then one morning it failed on a decoding error, which looks exactly like a corrupted image.

The image was fine. Another scheduled routine had copied a social draft to the clipboard in the gap between the copy and the read. The publishing agent read that instead, and tried to decode a paragraph of marketing copy as image data.

The fix was not a lock file or a queue. It was collapsing the copy and the read into a single call so nothing can run in between, plus a check that refuses to decode anything that does not look like the expected payload.

The useful part is the diagnosis. Nothing in that error mentioned the other routine. Every collision I have hit since has had the same shape: the symptom appears in the innocent agent.

How to schedule multiple AI agents so they do not overlap

The cheapest coordination mechanism is the clock, and almost nobody uses it deliberately.

Measure the real run length first. Not the average, the longest one you have seen. An agent that usually finishes in six minutes and occasionally takes twenty is a twenty minute agent for scheduling purposes.

Space runs by that longest run, plus a margin. If your publishing agent can take twenty minutes, the next thing on the machine starts at least thirty minutes later. This feels wasteful when you have three agents and a whole day to fill. It stops feeling wasteful the first time it saves you a silent corruption.

Give each agent a named window and write it down. I keep one list of what runs when across every product. When something fails at an odd hour, the first thing I check is what else was running in that window. That list has explained more failures than any log has.

Never schedule two agents on the same minute. Not even light ones. A rounded start time like nine o'clock is the single most common cause of an accidental collision, because it is the time everybody picks.

On Windows, the built-in task scheduler handles all of this, and its command line tool is documented well enough to script the whole roster. On a server, ordinary scheduled jobs do the same thing. Neither needs a framework, and adding one buys you nothing at this size.

Why an orchestrator agent is usually the wrong fix

The instinct once you have three agents is to build a fourth that manages them. Resist it for a while.

An orchestrator costs a full extra context and a full extra run, and it adds a component that can fail quietly. When the manager agent dies halfway through, the three agents it was supposed to trigger simply do not run, and nothing tells you. A scheduled job that fails is loud. A manager that fails is silent.

More to the point, most of what people want an orchestrator for is deciding who goes first. A schedule answers that for free and never invents an answer.

There is a real case for the orchestrator pattern and it is narrow: one job, split into parallel pieces, inside a single run, with the results merged at the end. That is what the research system above does, with a lead agent spawning subagents that each get their own context window and explore a different aspect at the same time. Claude Code exposes the same idea locally, and the documentation on running agents in parallel lays out the options.

Notice the shape. One task, fanned out and pulled back together inside one run. That is a different problem from three independent business routines that happen to live on the same laptop. Do not apply the answer from the first problem to the second one.

How to give every AI agent its own lane

When agents do have to coexist, the discipline is ownership rather than coordination.

One writer per file. Every state file has exactly one agent allowed to write to it. Others may read. If two agents genuinely need to record the same thing, they get two files, and something merges them later as its own scheduled job.

One destination per agent. An agent that can publish to three places will eventually publish to the wrong one. Narrow it. I would rather run two agents with one destination each than one agent carrying a routing decision inside it.

Make every run idempotent. If a run starts twice, by accident or by retry, the end state should match a single clean run. In practice that means checking whether the work is already done before doing it, which is the same check that lets a routine recover from a crash. I went through that recovery logic in detail in which agent failures to retry and which must stop the run.

Keep memory local to the agent. Shared memory between agents sounds efficient, and it creates exactly the dependency that makes these setups fragile. Each of my routines keeps its own plain state, which is part of why I keep agent memory in text files rather than a vector database.

Give the browser a queue. If more than one agent needs a logged-in browser, they take turns. Serialize browser work even when everything else runs in parallel. It is the one resource I have never made safe to share.

How to tell when two AI agents collided

Collisions do not announce themselves. They show up as flaky behavior in a routine that has not changed.

The tells I now recognize:

• A routine that ran cleanly for weeks fails once, then works fine on a manual re-run.

• The error is about data being malformed rather than about an operation failing.

• The failure lands at a suspiciously round time.

• Two routines both report success, but one of them clearly acted on the other's input.

• Rate limit rejections show up in your lightest agent, because the heavy one drained the pool first.

The diagnostic is always timestamps. Line up the start and end of every run that day and look at what overlapped. Before I kept run times in one place, I spent hours reading the wrong log. Getting a short run report out of every agent is the prerequisite for this, and it is the first thing I would add to any routine that does not have one.

What order should you add AI agents in?

One agent, running reliably and unattended for a full week, before you add a second.

That is not caution for its own sake. Week one of any agent is supervision. You are reading every run, correcting the instructions, and finding out what it does when a site it depends on changes shape. Two agents in their first week is two first weeks at once, and you will not have the attention for either.

Pick the role you are furthest behind on. Not the most interesting one, and not all of them just because they are available. Get it boring. Then decide whether a second agent is genuinely the next constraint, or whether the first one just needs a wider job description.

I am walking through this whole operating model live on Saturday, September 12 at 10 AM Eastern: the eight employee roles, how they run on a schedule, and what changes when the work stops depending on your attention. The session page has free registration and the replay.

Start from a roster that already has lanes

If you would rather begin with agents that already have their lanes drawn, that is what the Agent Ops Club is for. Eight AI Employees, one role each, with the scheduling, the state handling and the approval gates already built in. The Agent Ops Masterclass covers the operating model underneath them, and the software library carries a license to deploy the work for your own clients.

There is a free account if you want to look around first. Pro is $99 a month or $349 a year. Lifetime is $499 until October 31 at 11:59 PM Eastern, and $999 after that.

One ask, and it is the same one I would give a friend. Hire the single role covering the work you are furthest behind on, and get it running for a week before you add anything else.

Common questions about running multiple AI agents

How many AI agents can I run at once?

On one machine, as many as your schedule has non-overlapping windows for. That is usually a smaller number than people expect. Three agents with twenty minute runs and a safety margin fill a couple of hours a day comfortably. The real limit is rarely compute. It is your ability to read the output and notice when one of them goes wrong.

Do multiple AI agents need to talk to each other?

Usually no, and it is worth designing so they do not. Agents that depend on each other's output in real time are exactly the case Anthropic's own engineering notes call a poor fit. If one agent needs another's result, have the first write it to a file and the second read that file on its own schedule. Slower, far more reliable, and you can actually debug it.

Should each AI agent have its own API key?

Separate keys are useful for tracking spend per agent, but they do not buy extra capacity, because the limits apply to the organization rather than to the key. If you are adding keys hoping to dodge a rate limit, space the runs out instead.

What happens if two AI agents edit the same file?

Whichever one writes last wins, and the other agent's work is gone with no error anywhere. That is why the one-writer-per-file rule is worth more than any locking scheme. Locks add a failure mode. Ownership removes one.

Is it cheaper to run one AI agent or several?

Several agents doing separate jobs cost roughly what those jobs cost on their own. Several agents coordinating on a single job cost noticeably more, because the coordination itself is tokens. The expensive pattern is a manager agent that reads everything its workers produce.

Can I run scheduled AI agents without a server?

Yes. A laptop running the operating system's own scheduler handles everything described here, as long as it is awake. The tradeoff is that a sleeping laptop skips runs silently and tells you nothing. I covered when that matters and when it does not in running an AI agent around the clock.