Microsoft's Cosmos DB recipe: give every parallel coding agent its own throwaway database

Run several coding agents on one app and you can give each its own branch and Git worktree. Their database is usually still shared. One agent resets the fixtures while another is checking a write, or a cleanup script drops the database under a running test suite. A new Azure Cosmos DB blog post puts it in one line: “The code is isolated. The state is not.”

The pattern

The fix is to make the task the unit of isolation: a separate worktree, a separate emulator, known fixtures, independent tests and cleanup that only removes what that task created. The sample repository does this with the Cosmos DB emulator in Docker:

• each task starts its own emulator container, on a host port Docker assigns and binds to 127.0.0.1;
• the runner waits for readiness, seeds versioned synthetic fixtures and passes each test process its own endpoint, instead of rewriting a shared .env file;
• cleanup removes only the container that run owns, and a result report is written only after the checks pass and removal is verified.

The proof deliberately reuses the same database, document ID and partition key in two environments, writes different values, and confirms each one reads back its own value. It then removes one environment and checks the other still works.

With real agents

An optional GitHub Actions job runs GitHub Copilot CLI as the coding agent on three tasks in parallel. In the run Microsoft describes, all five jobs passed, Copilot resolved one genuine Git conflict, and the integrated code passed 75 combined tests against a fresh emulator; the swarm runner took about 2 minutes 21 seconds, excluding job setup. Microsoft labels those as observed results, not guarantees. The real-agent job is off by default, is billed to the organization, and caps each Copilot session at 30 AI credits.

The caveats Microsoft states

• It is “not a security sandbox”: the agents still have broad runner and Docker access, so use trusted, reviewed code.
• The emulator does not enforce authentication, so keep its ports on loopback.
• Isolated state does not resolve design conflicts, such as one agent making a field required while another changes the fixtures. Rebuild a fresh environment from the merged revision and test that.
• Merge code, fixtures and migrations, never the emulator’s data. Fixture resets are not a way to update a live database.

The sample is Cosmos DB specific, but the idea should carry over to any database you can start in a container.