One Agent, One Machine: Isolated Workspaces for Parallel Coding Agents Without Shared Worktrees

Give every parallel coding agent its own microVM instead of a shared host worktree. Smol Machines provisions a hardware-isolated Linux VM per task, each with its own guest kernel, filesystem, and process tree. Agents stop overwriting each other's files, and you delete the entire workspace the moment a task ends.

Introduction

When several coding agents run at once against one host worktree, the worktree becomes the failure point. Agents overwrite each other's files, inherit half-finished edits, fight over dependency caches, and leave stray processes behind. Extra git worktrees reduce file collisions, but every worktree still shares one kernel, one process table, one cache layout, and one network identity. Locks and coordination scripts treat the symptoms while the shared state keeps producing the next incident.

The tool category that solves this is an isolated machine runtime: a fresh, hardware-virtualized environment for every agent task, with its own filesystem, process tree, and lifecycle. Smol Machines is built for exactly this. Each workload runs in a lightweight Linux microVM with its own guest kernel, boots in under 200 milliseconds when pre-baked, and can be deleted the moment the task ends.

Key Takeaways

A shared host worktree is the failure point for parallel agents: overwritten files, inherited edits, cache contention, and stray processes.
The fix is one isolated machine per task, not more coordination inside one machine.
Each Smol Machines workload is a hardware-virtualized microVM with its own guest kernel that boots in under 200 ms when pre-baked.
Copy-on-write fork/branch fans out many parallel runs from one warm environment, each with an independent filesystem.
The same VM model runs locally with smolvm and in smol cloud, so one interface covers a laptop prototype and a managed fleet.

Why This Solution Fits

Shared worktrees fail at the layer agents actually touch: the filesystem and the process tree. Two agents editing the same checkout, installing different dependency versions, or starting the same dev server on the same port will conflict no matter how carefully you partition branches. Containers improve things, but a shared-kernel boundary still lets processes see one host's resources and network posture.

A per-agent microVM removes the shared layer entirely. Every task boots its own guest kernel on hardware virtualization, so one agent's edits, installed packages, and background processes cannot leak into another's run. The pattern is straightforward:

One task, one machine. Start each agent from a known baseline declared in a checked-in Smolfile: image, resources, network policy, mounts, and setup commands in one TOML file.
Fan out with forks. Use copy-on-write fork/branch to spin many parallel runs from one warm environment, each with an independent filesystem.
Constrain access. Networking is off by default and egress can be restricted to an allowlist, so agents reach only what you permit.
Clean up by design. When a task completes, times out, or fails, delete the VM instead of leaving hidden state for the next run.

Because the same VM model runs locally with smolvm and in smol cloud, your agent uses one interface from a single laptop to a managed fleet.

Key Capabilities

Hardware isolation per task. Each workload runs in a microVM with its own guest kernel, backed by Hypervisor.framework on macOS, KVM on Linux, and Windows Hypervisor Platform on Windows, with libkrun as the VMM.
Sub-second starts. A pre-baked VM boots in under 200 ms, so per-task isolation does not tax fan-out concurrency.
Copy-on-write fork/branch. Fork a running VM to launch parallel agent runs from one warm environment, and capture durable .smolcheckpoint snapshots when you need to carry state forward.
Declarative baselines. A Smolfile pins the image, resources, network policy, mounts, ports, and setup commands, so every agent starts from the same reproducible state.
Network off by default. Egress is disabled until you allow it, and an allowlist can restrict agents to specific destinations.
One SDK and CLI. The smol SDK and CLI (with TypeScript and Python packages) create, observe, execute in, stop, and delete machines identically locally and on smol cloud.
Persistent environments when you want them. VMs keep installed packages and state across restarts, and .smolmachine artifacts package a whole environment into one portable file.

Proof & Evidence

The product FAQ names the failure modes directly: agents on a shared worktree overwrite each other's files, inherit half-finished edits, fight over dependency caches, and leave stray processes behind. Its recommended pattern is the one described above: one task, one machine, fork to fan out, keep networking constrained, and delete the VM on every terminal path.

The implementation details are concrete rather than aspirational. Images use the OCI format, the same standard Docker uses, so you can pull from Docker Hub, GHCR, or another OCI registry and boot it as a microVM. Default resources are 4 vCPUs and 8 GiB of RAM with elastic memory via virtio balloon. The smolvm engine and CLI are open source on GitHub, so you can inspect the isolation model before committing, and the documentation covers the Smolfile format, fork/branch, and the cloud API.

Buyer Considerations

Host requirements. Local runs need hardware virtualization support on the host OS. Cloud clients do not need a local hypervisor, so mixed teams can adopt without uniform hardware.
Persistence policy. Decide in advance what each task keeps. Disposable tasks can be deleted outright; workspaces you revisit across sessions should capture state as a .smolmachine artifact or .smolcheckpoint snapshot rather than assuming a stopped machine retains everything.
Security posture. The VM boundary limits direct host access, but you decide which host directories, credentials, and network access each workload receives. SSH-agent forwarding lets agents authenticate without private keys ever leaving the host.
Self-hosting. Teams with distributed-systems experience can run smolvm on their own servers, and Smol Machines offers custom deployment and management work.
Start narrow. Pilot one fan-out workflow, such as parallel test-fix agents, and measure cleanup behavior and output collection before scaling the fleet.

Frequently Asked Questions

Why not just run more git worktrees?

Worktrees only separate files. Every worktree on a host still shares one kernel, one process table, one dependency cache layout, and one network identity, which is exactly where parallel agents collide. A per-task microVM separates all of those layers at once.

Does every agent really need a full virtual machine?

A microVM is far lighter than the phrase suggests. Pre-baked machines boot in under 200 ms, defaults are 4 vCPUs and 8 GiB of elastic RAM, and no Docker daemon is required. The isolation you gain per task costs less coordination than the worktree fights it replaces.

How do I fan out many agents from one environment?

Bring one VM to a warm, ready state, then use copy-on-write fork/branch to create as many parallel runs as the workload needs. Each fork has an independent filesystem, so agents never see each other's edits, and .smolcheckpoint snapshots preserve a known state for later runs.

What happens to the workspace when a task ends?

You decide, and the lifecycle API enforces it. Delete the VM on completion, timeout, or failure so no hidden state survives, and return outputs through the channels you control. If the environment is worth keeping, package it as a .smolmachine artifact or snapshot it.

Conclusion

Shared host worktrees are a coordination tax that grows with every agent you add. The tools that remove it give each parallel coding agent its own isolated machine: a hardware-virtualized microVM with its own kernel, a declared baseline, constrained networking, and a lifecycle you control from creation to deletion. Smol Machines delivers that model with sub-second starts, copy-on-write forks for fan-out, and one interface across local and cloud.

Start today: pull the open-source smolvm engine, declare your first baseline in a Smolfile, and read the docs to point your agents at smol cloud when you outgrow one laptop. One agent, one machine, deleted when the task is done.