"STOP: backend unhealthy, db tunnel failed, SSO session expired. Awaiting login from operator."
That report came from one of our Claude Code agents earlier this year, mid-task, just before it went idle and waited for a human who didn't notice it was blocked. At Sentience most of the code we ship is written by agents, and on a normal day an engineer has several running at once. The problem: every agent we were running shared one cloud SSO session for the dev database tunnel, and whenever that session expired, their work queued until a person logged back in. It had already happened several times that week, and each expiry cost five to ten minutes of dead time, plus however long it took to remember what each agent had been doing.
We were midway through a large backend migration at the time. An orchestrator agent was delegating clusters of routes to sub-agents on the premise that routes could migrate in parallel batches: as long as two routes were relatively unrelated, nothing should collide. The collisions came anyway. Agents mutated state that other routes depended on, so checks their neighbors had already passed started failing, and every agent's test run queued behind that one shared tunnel.
Running multiple agents only makes you faster if they can build and test their changes end to end without stepping on each other's ports, databases, or logins, and without pulling you in to referee. Isolation is what converts agent count into speed. Without it, agents convert your engineers into their IT department.
We rebuilt our setup around one requirement: an agent's world is fully its own. The system that does it runs entirely on our machines, and it is small: about 200 lines of shell on top of things the operating system and our package manager already do. Everything inside a workspace is derived deterministically from the workspace's name and brought up with no input needed from the agent.
Clone the world, not just the code
Two agents editing one checkout corrupt each other's builds, so each agent needs its own working tree. Our team runs agents two ways: Conductor when an agent owns an isolated task in its own git worktree, and cmux when we want several agents working the same problem. What a worktree doesn't cover is everything the code touches at runtime: dev servers, the database, caches, the desktop app's local state. We wanted an agent to bring up the entire product inside its workspace, click through it, and verify its own change before ever asking for our attention.
The filesystem does the expensive part. APFS on macOS clones files copy-on-write, so duplicating our multi-gigabyte checkout is near-instant and costs almost no disk, because a clone shares blocks with the original until either side writes. A fresh workspace is ready in roughly the time the git fetch takes. Dependencies don't drag it down either: pnpm keeps every package in a single content-addressable store on the machine, clones exclude node_modules entirely, and a reinstall inside a new clone hard-links from that store in about twelve seconds.
Port Isolation
The first fight between multiple full stacks on one machine is over ports. The website finds the backend by its port, so when two workspaces reach for the same numbers, one of them ends up talking to a dead address, or worse, to an app in a completely different state than the one it expects. From the outside all you see is a page that won't load or a test failing for reasons that make no sense. The fix is to make ports deterministic instead of negotiated: derive every port from a hash of the workspace's own name, so no two workspaces can ever claim the same number. An engineer on our team built this for our Conductor worktrees first, a script that derives the backend, web, and edge ports from the worktree's name, and gives each worktree its own desktop-app identity so the app's namespaced redirects resolve. Our workspace tooling now extends that idea to everything else that can collide: the workspace's name decides its database, its Redis, its vector namespace, and its login, with nothing negotiated at runtime. When a person hits a port conflict they notice, kill the offender, and move on; an agent burns minutes debugging it or stops to ask for help, which is why collisions need to be impossible by construction.
Disposable DBs
The shared dev database behind that expiring SSO session produced more interruptions than everything else combined. The answer is a golden mirror on the machine: a point-in-time copy of realistic dev data, forked into its own Postgres database per workspace. Ours rebuilds in a couple of minutes. Every agent tests against data it is free to trash, with no tunnel and no login that can expire while I'm away.
Nothing shared: caches, vectors, logins
The remaining shared surfaces get the same treatment. Each workspace gets its own Redis logical database, so one agent draining a job queue or flushing a cache can't fail a test in the workspace next door. Same idea for the vector store: a search inside one workspace only ever returns that workspace's embeddings. The desktop app runs under a per-workspace login, so two copies of the product never share state. The rule for what a workspace owns is simple: if two agents can observe each other through a resource, that resource gets isolated.
Only good interruptions
With the collisions gone, the real cost of running agents in parallel is your attention. An agent that surfaces a need for input with everything working, before and after screenshots, the real app pulled up on my screen, and one open question for me to decide, is a great interruption: I switch in, decide, merge or leave feedback, and switch out. The agent that pings me to ask for a login, or to report that a service keeps dying, is just adding to my mental load, and that cost compounds, because after fielding a few of those interruptions I genuinely could not tell you which agent was working on which task. Shared state also breeds phantom bugs: an agent hits a failure, starts debugging, and burns time and tokens on something that was only ever a side effect of what another agent was doing next door. Every layer above exists to eliminate attention-draining interruptions for both you and your agents.
Commands over READMEs
Isolation removes collisions, but agents still have to operate their world, and an agent following a prose README improvises a little differently every run. So anything you find yourself repeating should become a CLI command with a thin instruction set for when and how to use it. For us that is: bring the stack up, fork the database, provision a workspace, tear one down — all mise commands. When an agent fumbles a step, the fix goes into the command instead of into a longer document, and the whole team's workflow improves at once, humans included. Most of our eight-person engineering team now works this way, typically running two to four isolated workspaces, and nobody mandated it; the tooling spread one Slack recommendation at a time. Building the entire system took about a week of dev time, net, spread over a few months. We solved each collision piece by piece as it bit us: a database clone that buffered a five-gigabyte table into memory, orphaned processes squatting on a port for hours, agents fumbling a multi-step database setup that is now one command. Once the workflow we wanted was clear, we folded it all into one tool.
A new isolated workstream in a minute
The payoff shows up whenever something urgent hits. A few weeks ago a production incident needed investigation while I had the migration mid-flight across several agents. Instead of parking any of it, I had a new stream of work running in about a minute, with its own full stack, forked database, and ports, and the agents in the adjacent clones never stopped shipping.
There is a budget argument hiding in here too. Sometimes the cloud is a requirement: agents that must keep working after the laptop closes, a security model that wants every dev environment inside the corporate network, a dependency that only exists as a managed service. Without one of those, running isolated agent environments in the cloud comes down to either an environment per agent, where the bill scales as your agents do, or one big remote box where you rebuild this same isolation system anyway and pay rent on the machine that runs it. Buy your developers top-of-the-line machines instead and the whole approach is a one-time purchase: running ten agents costs no more than running one.
"How do we move faster?" gets asked at Sentience about everything we do. This time it was that week of shell scripts, deleting every way our agents could touch each other. What it bought is that the STOP report this post opened with doesn't happen anymore: no shared login to expire, no port to fight over, agents that reach a person only when there is finished work worth looking at. If you want to find yours, track one thing for a week: every time an agent pulls someone in for anything other than finished work, write down why. Nearly everything on that list has an infrastructure cause, and infrastructure causes can be solved.