A Git Worktree Is Not an Agent Sandbox

On November 10, Google announced /swarm for Antigravity: a multi-agent workflow that gives parallel workers isolated Git worktrees and uses separate verifiers to challenge their changes. Anthropic has also announced newer models aimed at longer, more complex technical work.

The direction is clear: developers are moving from asking one assistant to complete a task toward coordinating several agents.

But there is a trap in the word isolated.

A Git worktree isolates a checkout and a branch. It does not automatically isolate the database, Redis instance, ports, test accounts, API quotas, queues, credentials, or cloud resources those agents use.

You can have three agents in three clean worktrees and still have them break each other's environment.

The useful mental model is:

A worktree isolates files. A reliable agent workflow must isolate resources and ownership too.

1. Start with one worktree per independent task

Worktrees are still a good foundation. They let multiple branches have separate working directories without cloning the repository's entire Git history.

For example:

git worktree add ../app-agent-auth -b agent/auth git worktree add ../app-agent-export -b agent/export git worktree list 

Now each agent has its own checkout. One can work on authentication while another builds an export feature.

That prevents the most obvious collision: two processes editing the same working tree.

It does not prevent either process from connecting to the same local Postgres database.

2. Give every agent its own runtime resources

Imagine agent A runs a migration that renames a database column. Agent B is halfway through an integration test that expects the old column.

Their files are separate. Their database is not.

The same class of problem appears with:

• a shared Redis cache or queue;
• two development servers trying to use the same port;
• a shared test account whose state one agent resets;
• generated files written to one common directory;
• a rate-limited sandbox API called by several agents;
• one agent changing a shared schema while another builds against it.

For local development, assign a small resource namespace to each worktree:

The values are examples; use the names and isolation mechanisms your stack supports.

Keep per-agent configuration outside tracked files. Do not copy production credentials into every worktree. Give agents short-lived, least-privilege credentials for test environments only.

If a service cannot be separated, treat it as a shared resource and coordinate access rather than pretending it is isolated.

3. Use a resource contract, not just a prompt

Before starting an agent, write down what it owns and what it must not touch.

A useful task card can be as small as this:

task: add CSV export worktree: ../app-agent-export branch: agent/export owns: - src/export/** read_only: - src/api/contracts/** do_not_edit: - db/schema.prisma - package-lock.json resources: port: 3102 database: app_agent_2 storage_prefix: agent-2/ acceptance: - export unit tests pass - no changes outside owned paths without approval - report commands actually executed 

This is a task contract, not a universal configuration format. Its job is to make boundaries explicit before the agent starts changing things.

For tasks that need the same schema, lockfile, migration, or central configuration, assign one owner. Other agents can work against an agreed interface, but they should not independently rewrite the shared contract.

4. Serialize the parts that are genuinely shared

Not every task benefits from parallel execution.

Good candidates:

• add a feature in a separate module;
• write documentation for an already stable API;
• build an independent UI component;
• add tests for a defined interface.

Keep these serial unless you have a deliberate coordination mechanism:

• database migrations;
• dependency lockfile updates;
• shared API or event schema changes;
• edits to the same central file;
• operations against one stateful external test account.

For external APIs with strict rate limits, use a queue or semaphore with a known concurrency limit. Giving every agent the same API key does not create more quota; it creates a race for the same quota.

5. Integrate one change at a time

A coordinator should not merge every agent's output at once.

A safer loop is:

1. Ask each agent for a concise summary, changed-file list, test commands, and unresolved risks.
2. Inspect the diff against the agreed task contract.
3. Merge one branch.
4. Run the relevant tests against the combined state.
5. Only then merge the next branch.
6. Remove the worktree when its work is accepted.

A separate verifier can challenge assumptions and run tests, but it is not a substitute for reviewing the integrated result.

6. Measure whether parallelism is actually helping

More agents do not automatically mean faster delivery. Coordination, repeated setup, merge conflicts, test collisions, and model usage all have a cost. Google also notes that its multi-agent workflow can consume quota much faster than a standard chat.

Start with two agents, not ten.

Track a few simple signals:

• time from task start to an accepted change;
• time spent resolving integration conflicts;
• failed tests caused by shared state;
• repeated work or overwritten changes;
• total model and infrastructure cost.

If the integration and rework time exceeds the time saved, split the work differently—or do it sequentially.

A short pre-flight checklist

Before launching parallel agents, check:

• [ ] Each agent has a separate worktree and branch.
• [ ] Each task has clear file ownership and acceptance criteria.
• [ ] Ports, databases, caches, queues, and storage are separated or coordinated.
• [ ] Credentials are scoped to test resources.
• [ ] Shared schemas, migrations, and lockfiles have one owner.
• [ ] Changes will be reviewed and integrated one at a time.

Google's Antigravity /swarm announcement is an interesting signal of where developer tooling is heading. The lesson for an ordinary team is not that everyone needs a swarm. It is that concurrency needs explicit boundaries.

A worktree gives an agent its own desk. It does not give it its own database, API quota, or authority.

When you run multiple coding agents, what has caused the most trouble for your team: file conflicts, shared runtime resources, unclear task ownership, or integration review?