Agent Isolation & Blast Radius: Protecting Parallel Work From Parallel Agents
A dispatched agent did what it thought was right — created a clean branch. That single action destroyed 130 uncommitted quiz questions across 26 lessons. Isolation is not optional.
March 2026. Twenty-six lessons had been authored with quiz questions — five questions per lesson, 130 questions total. Type definitions extended. Hooks updated. Test files written. All of it lived in the working directory as uncommitted modifications to tracked files.
A logo integration agent was dispatched. Its job was simple: update branding assets across the site. Standard task. The agent did what any responsible developer would do — it created a new branch from main for a clean working surface.
That branch switch wiped every uncommitted tracked-file modification in the working directory. One hundred and thirty quiz questions. Type definitions. Hook extensions. Test updates. Gone.
The agent did nothing wrong. The system had no isolation.An agent that operates in a shared working directory without constraints is not a collaborator. It is a loaded weapon pointed at your uncommitted work.
The blast radius of an unconstrained agent is everything in the working directory that is not committed.
The Anatomy of the Incident
Understanding exactly how this happened is the difference between a lesson and a platitude.
The working directory was on a feature branch. Modifications to existing tracked files — quiz additions to MDX files, type definition changes, hook updates — were staged or modified but not committed. The work was in progress. Committing was premature because the feature was not complete.
The logo agent was dispatched with a simple instruction: update branding. It had no branch constraint. No file manifest. No isolation. It saw main as the correct starting point for a branding task and ran git checkout main followed by git checkout -b logo-integration.
When git switches branches, it does two things. First, it replaces the working directory contents with the target branch state. Second — and this is the lethal part — uncommitted modifications to tracked files are discarded if they conflict with the target branch. Git does not ask. Git does not warn if the checkout is forced or the files diverge. The modifications simply disappear.
Untracked new files survived. They were not on either branch, so git had no reason to touch them. But every modification to an existing file — every quiz question added to an existing lesson MDX file, every type definition change, every hook extension — was erased.
Recovery took an hour. The quiz data had to be re-authored. The type definitions re-written. The tests re-built. An hour of rework caused by an agent that was trying to help.
Great leaders are almost always great simplifiers, who can cut through argument, debate, and doubt to offer a solution everybody can understand.
— General Colin Powell · My American Journey, 1995
The simple solution: never dispatch an agent into a shared working directory with uncommitted work. The rest of this lesson is the implementation of that principle.
The Independence Test
Before dispatching parallel agents, run this test. The answer determines your isolation strategy.
The test is a decision tree, not a suggestion. Run it before every multi-agent dispatch. The March incident happened because the test was never run. The question "can this agent switch branches?" was never asked. The answer — "yes, and it will destroy uncommitted work" — was never confronted.
File Manifests: Explicit Ownership, Enforced Boundaries
A file manifest is the minimum viable isolation for agents sharing a repo without branch isolation. It is an explicit, enumerated list of what the agent owns.
You own the following files:
- public/images/logo.svg
- public/images/favicon.ico
- components/layout/Header.tsx (logo import only)
Do NOT edit, create, delete, or modify any file outside this list.
Do NOT switch branches. Do NOT run git checkout.
Do NOT modify package.json, configuration files, or content files.
The manifest serves two purposes. First, it constrains the agent's action space. Second — and more importantly — it makes the blast radius explicit before the agent starts. You can look at the manifest and answer: "If this agent goes rogue, what is the worst case?" If the worst case is limited to three files, the risk is acceptable. If the worst case is "the entire working directory," the risk is not.
Manifests are not foolproof. An agent with a compelling reason to edit a file outside its manifest might do so. The constraint is instructional, not mechanical. But instructional constraints work in practice because agents follow explicit instructions far more reliably than implicit expectations.
The file manifest is not just a safety mechanism. It is a scoping tool.
An agent with a clear manifest finishes faster because it is not exploring files outside its scope. It is not "helpfully" refactoring adjacent code. It is not improving things that were not asked for. Constraints improve both safety and speed.
Worktree Isolation: The Physical Barrier
When an agent needs its own branch — because the work requires a PR, or the changes span enough files that a manifest becomes unwieldy — git worktree is the correct tool.
git worktree add .claude/worktrees/logo-integration main
This creates a physically separate directory containing a full checkout of the repo at the specified branch. The agent works entirely inside that directory. The main working directory is untouched. Branch switches in the worktree do not affect the main working directory. File modifications in the worktree do not appear in the main checkout.
This is not soft isolation. This is physical directory separation. The agent literally cannot affect the main working directory because it is operating in a different filesystem path. When the work is complete, changes are merged from the worktree branch into the target branch through normal git operations.
The cost is disk space — a worktree duplicates the checkout. The benefit is absolute isolation. For any task where the agent needs branch freedom, the tradeoff is not close.
The Commit-Before-Dispatch Rule
Every isolation strategy above assumes something: that you have committed or stashed your work before dispatching agents. This is not a suggestion. It is a prerequisite.
Uncommitted work is unprotected work. If you dispatch an agent into a repo with uncommitted modifications, you are gambling that the agent will not touch those files. That gamble has known odds — and they are not in your favor.
The rule: commit or stash before dispatch. No exceptions.
The commit does not need to be clean. It does not need a polished message. git commit -m "WIP: saving state before agent dispatch" is perfectly acceptable. The point is not code hygiene. The point is that committed work survives branch switches, checkout operations, and agent mistakes. Uncommitted work does not.
If the work is truly not ready for a commit — not even a WIP commit — use git stash. Stashed changes live in a stack that survives any branch operation. git stash pop restores them when the agent is done. The work is preserved. The agent has a clean surface.
Blast Radius Thinking
Before dispatching any agent, answer one question: what is the worst thing this agent could do?
Not what it is likely to do. Not what it intends to do. The worst case. The maximum blast radius if every constraint fails and the agent takes the most destructive reasonable action.
Map the blast radius:
- Can the agent switch branches? If yes, it can wipe uncommitted tracked-file changes. Isolate with worktrees or commit first.
- Can the agent edit files outside its scope? If yes, it can introduce unintended changes to unrelated features. Constrain with a file manifest.
- Can the agent delete files? If yes, it can remove files that other agents or the main session depend on. Enumerate forbidden operations in the instructions.
- Can the agent push to remote? If yes, it can force-push and rewrite history. Restrict push permissions or specify branches.
If you cannot answer these questions before dispatch, you do not have enough isolation. Add constraints until every question has a safe answer.
The isolation investment scales with agent count. One agent in a repo — low risk, minimal isolation needed. Three agents in a repo — mandatory worktrees or strict file manifests. The combinatorial risk of agent interactions grows faster than the number of agents. Two agents have one interaction pair. Three have three. Five have ten. Isolation cost is linear. Interaction risk is quadratic. The math is clear.
Lesson 35 Drill
Review your last multi-agent or multi-task session. Answer these questions:
- Did any agent have the ability to switch branches in a directory with uncommitted work? If yes, you were exposed.
- Did every agent have a file manifest or worktree isolation? If not, what was the blast radius?
- Was there uncommitted work in the repo before agents were dispatched? If yes, was it committed or stashed first?
For your next dispatch, write the isolation plan before the task spec. Define the worktree path or file manifest. Verify uncommitted work is committed. Run the independence test. Then — and only then — dispatch.
Bottom Line
Agents are competent, fast, and goal-directed. They will do what they think is right. And "right" sometimes means switching branches, creating new files, or reorganizing code in ways that destroy your parallel work.
The solution is not to make agents less capable. It is to constrain their environment so that competent behavior cannot produce catastrophic side effects. Commit before dispatch. Isolate with worktrees. Scope with manifests. Think in blast radius.
One hundred and thirty quiz questions is a cheap lesson. The next time the blast radius is a production database.
Explore the Invictus Labs Ecosystem