Microsoft shows how to give each AI coding agent its own private test database

Code is isolated, data is not

Picture several AI coding agents working on one app at the same moment. One changes how deliveries are dispatched, another adds a depot rule, a third edits tests. Each has its own branch and maybe its own copy of the files. But if all of them point at one development database, they trample each other.

As devblogs.microsoft.com reported in this Microsoft walkthrough, the failures are mundane. One agent resets the sample data while another is mid-check. A test alters a record that a different task assumed was untouched. A cleanup step wipes the database under a test suite that is still running.

Azure Cosmos DB stores flexible documents rather than rigid tables, so it avoids relational-style schema migrations. The article's point is that this doesn't remove the problem. Apps still rely on the shape of their documents, on partition keys (the field that decides where a record lives), on indexing settings, and on predictable test data.

One environment per task

The proposal is to treat the task, not the branch, as the unit of isolation. Every task receives a private copy of the code, its own database emulator (a local program that imitates the cloud database), a known set of starting records, separate logs, and responsibility for cleaning up after itself.

The author is careful about what this is not. It is borrowing the spirit of a Git worktree, which lets you keep several branches checked out side by side. It does not copy database snapshots, clone a production account, or merge database contents back together. Each emulator is rebuilt from scripted sample data, and only the reviewed code changes get merged.

The two-environment proof

Before involving any agents, the sample answers a smaller question. Can two emulators hold records with identical identities, accept different edits, and be shut down without one affecting the other? The test deliberately reuses the same database name, item ID and partition-key value in both, so any leak would show up.

Both environments start with a Seattle dispatch record set to pickup bay BAY-2. Environment A writes BAY-7 and Environment B writes BAY-8. Afterward, the test reads each record back independently and confirms the stored values belong to that environment. It also checks that a Portland record still has its original BAY-99 value.

Then it removes A and confirms B still holds its own update. A failed check makes the command exit with an error, cleans up its containers and writes no success report. The script gives each client explicit settings rather than editing a shared .env file, and Docker assigns different host ports even though the emulator uses 8081 and 8080 internally.

Running it in GitHub Actions

The second half is continuous integration (CI), the automatic checks that run when someone opens a pull request. The sample adds a workflow with two task presets: one for dispatch tests and one for fleet-rule tests. Each preset gets its own Ubuntu runner and its own emulator, rebuilt from the proposed revision rather than inherited from another task.

The same check can be run locally, so an agent can verify its work before submitting. The workflow sets a 15-minute timeout, lets one task finish even if the other fails, and uploads logs and results even after a failure. Artifacts are kept for 7 days, and names include the task and attempt so parallel jobs don't overwrite each other.

The article stresses that these narrow checks are quick feedback, not a replacement for testing the whole application before merging.

The swarm check and its limits

A separate script tests the full flow. It creates three worktrees from one revision, starts an emulator for each, and runs the tasks at the same time: two in the dispatch area and one for fleet rules. Each task edits a file, writes a dispatch update and commits. The check then confirms every emulator holds only its own task's update.

A negative control runs two stand-in tasks against a single shared emulator and requires that one write gets lost. This shows the collision is real. Afterward the branches are merged into an integration worktree, the combined tests run on a fresh emulator, and the temporary resources are removed.

By default the coding step is a scripted stand-in. Passing a command for GitHub Copilot's command-line tool makes real agents do the work. Database isolation won't stop code conflicts, so when agents collide on a merge, the runner asks the same agent command to resolve it. The author also notes that a production-grade coordinator for agents is separate from this sample.