Stateful Agent Workspaces Mcp

Scaling State-Modifying AI Agents with MCP Workspaces

Skip to Main Menu

Skip to Main Content

Skip to Footer

Back to Blog

-->

Back to Blog

Scaling agents with test-time compute (TTC) heavily relies on running multiple reasoning paths in parallel. AI21 Maestro, our TTC-first agentic framework, is built around this idea: AI21 Maestro executes multiple trajectories concurrently, exploring different approaches and selecting the best outcome.

This approach has proven very effective with read-only tasks such as answering complex questions based on an internal knowledge base. However, when applying AI21 Maestro to code, we ran into a hard constraint: parallel agents work well when they reason, but break down once they start acting. As soon as multiple branches could edit the same files, modify shared state, or trigger external side effects, conflicts emerged:

Multiple subagents working on the same codebase would create conflicting changes

Files would get corrupted when two agents edited them simultaneously

We needed a clean mechanism for rolling back when a bad strategy was tried

These issues had to be resolved to fully utilize the capabilities of AI21 Maestro’s Execution Engine. The underlying issue is not framework-specific but rather a structural problem that must be solved if active agents are to benefit from test-time compute. This challenge isn’t limited to coding. The same challenge appears across domains:

Database agents perform schema changes that need safe rollback

Document agents make edits that can overwrite each other

Infrastructure agents provision cloud resources that might leave environments half-configured

The pattern is universal: agents that only read can share an environment. Agents that write need isolation. In order to properly scale and parallelize agents, we realized we had to extend the MCP protocol to fit the TTC era.

See how we orchestrate Test-Time Compute for long-horizon agentic tasks

The missing layer in MCP

For coding tasks, AI21 Maestro’s agents had to do more than propose edits. They had to execute them: run shell commands, compile, run tests, and inspect outputs. We used MCP ( Model Context Protocol ) to handle these tool calls. MCP is the de facto standard for connecting AI agents to external capabilities, and it handles tool execution well. But MCP makes no requirements regarding the execution context they run in. MCP tells you what a tool does and how to invoke it, not where it runs or what state it shares with other calls.

This works fine for read-only agents. But when agents start modifying state, “the environment” becomes a shared mutable state too. In our case, subagents weren’t just reading files. They were writing them, running formatters, generating build artifacts, editing configs, and then doing the classic “edit and run tests”. If two subagents do that in the same working directory, chaos starts: one agent’s git checkout invalidates another agent’s test run; one agent’s dependency update changes another agent’s build; temporary files collide.

It’s not that isolation is missing at the system level: most domains already have a way to create a “safe sandbox”. Git can fork working copies with worktrees; databases can isolate changes with transactions; documents can branch through version history. The problem is that MCP has no way to “name” or carry that isolation context across tool calls.

MCP tells agents what they can do. We needed the missing piece: where those actions take place. Specifically, isolated workspaces so multiple subagents can operate in parallel without stepping on each other. Our solution was to extend MCP with a Workspace layer: a set of primitives that any state-mutating agent can use to get isolation without rewriting its tools.

MCP workspace layer

It was important for us to make this change at the protocol level. Since different problems require different workspace abstractions, the protocol defines operations, and each domain chooses the isolation mechanism behind them. This allows different MCP clients to implement workspace isolation in a way that fits their environment, while sharing a common contract.

We designed five domain-agnostic primitives that handle the lifecycle of any state mutating context:

To provide workspace isolation to an agent, the interfaces remain the same; only the underlying implementation changes.

Our implementation: coding agents with git worktrees

Once we had workspace primitives defined at the protocol level, the challenge shifted to how an MCP client should implement them in practice. From the client’s perspective, responsible for executing tools, workspace isolation had to be concrete, efficient and compatible with existing developer workflows. For a coding agent, this translated into a few requirements: fast enough to fork dozens of times per run, cheap enough to keep around while tests execute, and mergeable/diffable because compare and merge are first-class primitives. That narrowed the options quickly.

We landed on git worktrees. a few days later, we were happy to see that the Cursor team released a post saying they went with the same approach.

Git worktrees gave us exactly what we needed:

Near-instant workspace creation: milliseconds to spin up a new checkout

Built-in change tracking: each workspace maps to a branch

Native merging capabilities: merge the winning branch back without bespoke glue code

Low disk overhead: Git objects are shared across worktrees

Once we chose worktrees, we got a near 1:1 mapping to our workspace primitives, which made the “protocol vs implementation” story click.

What this enables

Workspace isolation didn’t just prevent collisions. It changes how test-time compute and multi-agent systems can be applied to state-mutating tasks.

1. Parallel subagent execution

Multiple subagents can work simultaneously without stepping on each other. Each gets its own workspace, so concurrency becomes the default instead of a special case.

2. Speculative problem-solving

Run multiple strategies in parallel, discard the losers, merge the winner. The agent isn’t forced into a single path, so it can explore the solution space instead of committing early.

3. Safe experimentation

Rollback is a delete operation. Failed attempts are just workspaces you throw away. That removes the fear factor and makes bold experiments cheap.

4. A domain-agnostic pattern

The workspace primitives we’ve defined aren’t code-specific. The same pattern...