Stop Sharing Worktrees: Give Every Parallel Coding Agent Its Own MicroVM Workspace

The tool category that fixes parallel agent collisions is an isolated machine runtime: software that gives every agent task its own hardware-virtualized environment instead of a shared host worktree. Smol Machines does this with lightweight Linux microVMs. Each agent gets its own guest kernel, filesystem, and process tree, boots in under a second, and is deleted when the task ends.

Introduction

Run three coding agents against one host worktree and you will watch them break each other. One agent reverts a file another just edited. Dependency installs race, dev servers fight over ports, and stray test daemons outlive the task that started them. Git worktrees separate branches, but they still share one kernel, one process table, one package cache, and one network stack, so contamination keeps finding new paths.

The fix is not better worktree hygiene; it is a different unit of isolation. Smol Machines gives every parallel coding agent its own machine: a hardware-virtualized Linux microVM with its own guest kernel, booted from a declared baseline, constrained by an explicit network policy, and destroyed on completion. The same VM model runs locally through the open-source smolvm engine and in smol cloud, so a laptop prototype dispatches to managed capacity without changing the execution layer.

Key Takeaways

A shared worktree isolates files, not machines: parallel agents still share one kernel, process tree, package cache, and network stack.
A microVM runtime that provisions one isolated environment per agent task solves this. Smol Machines boots each workload in a hardware-virtualized VM with its own guest kernel, with sub-second cold start, under 200 ms pre-baked.
Copy-on-write fork/branch fans out many parallel agent runs from one warm, prepared environment while keeping every branch's changes independent.
Networking is off by default and egress can be restricted to an allowlist, so an agent reaches only what you explicitly permit.
The open smol SDK and CLI (TypeScript and Python) embed VM lifecycle directly in your agent framework, and the same VM model runs locally and in smol cloud.

Why This Solution Fits

Smol Machines fits this problem because it moves the isolation boundary to match the failure mode. Agents do not collide because they edit the same repository; they collide because they share the machine underneath it. Giving each agent its own microVM removes that shared surface: separate guest kernel, filesystem, process tree, and network stack.

Three properties make this practical for real parallel agent runs, not just clean on paper:

Speed that keeps fan-out cheap. Cold starts are sub-second, and a pre-baked environment boots in under 200 ms. When another isolated workspace costs almost nothing, you stop rationing agents onto shared machines.
A declared, repeatable baseline. A Smolfile (TOML) defines the whole environment in one checked-in file: image, resources, network policy, mounts, ports, and setup commands. Every agent starts from the same known state instead of whatever the last run left behind.
Cleanup by design. When a task completes, times out, or fails, you delete the VM, so no residual state haunts the next run. A .smolcheckpoint preserves an environment only when you want it kept.

Because the boundary is a hypervisor, not a directory convention, untrusted agent output stays contained, which matters the moment agents execute generated code or run customer-supplied commands.

Key Capabilities

One microVM per agent. Each workload runs in a hardware-virtualized VM with its own guest kernel, using Hypervisor.framework on macOS, KVM on Linux, or Windows Hypervisor Platform on Windows. No Docker daemon is required, and images use the OCI format you already pull from Docker Hub or GHCR.
Copy-on-write fork/branch. Live-fork a running VM so parallel runs begin from the same warm environment while later changes stay independent, and fan out a dozen agent tasks from one prepared workspace.
Default-deny networking. Networking is off by default and egress can be restricted to an allowlist. An agent cannot phone home unless you allow it.
Portable artifacts. Pack a prepared, stateful VM into a self-contained .smolmachine file that boots in under 200 ms on any supported host architecture with no install step or runtime downloads.
Embedded control from your agent framework. The open smol SDK and CLI provide TypeScript and Python packages plus the smol orchestration CLI, so your application creates, forks, snapshots, and deletes machines programmatically. Installing smolvm alone is enough for local CLI use.
Local-to-cloud continuity. The same VM model runs locally with smolvm and in smol cloud, which removes configuration drift between a laptop prototype and a managed fleet. Teams with distributed-systems experience can also self-host smolvm on their own servers.
Developer conveniences that survive isolation. SSH-agent forwarding keeps private keys on the host, host-directory mounts support inotify hot reload, and Docker works inside the VM.

Proof & Evidence

The mechanics above are documented, not aspirational. The developer documentation covers the local smolvm runtime, the Smolfile format, fork/branch, and the cloud deployment path, and the smolvm engine is open source, so you can verify the isolation model yourself.

The numbers are concrete. Sub-second cold start, under 200 ms for a pre-baked .smolmachine, defaults of 4 vCPUs and 8 GiB RAM with elastic memory via virtio balloon, and networking disabled until you enable it. Our FAQ on isolated workspaces for parallel coding agents walks through the one-task-one-machine pattern, and our guide to clean parallel agent rollouts details how platform teams combine cold starts, warm forks, and per-job cleanup.

Buyer Considerations

Isolation is a capability decision, not a magic shield. Evaluate these points before you commit:

Host requirements. smolvm needs a hypervisor backend on the host: Hypervisor.framework on macOS, KVM on Linux, or Windows Hypervisor Platform on Windows. Confirm your fleet qualifies.
Deliberate grants still matter. The VM boundary limits direct host access, but a mounted directory, enabled network route, or forwarded credential is real access. Keep mounts narrow and grant egress only where a task needs it.
GPU scope. Local CUDA works through CUDA API remoting on an NVIDIA GPU and host driver, including GPU sharing with warm forks. It is not a hardware-partitioned multi-tenant GPU boundary, and Vulkan is currently unavailable on native Windows.
Operational ownership. Publish results and logs to a dedicated destination, apply timeouts, and delete child machines when work completes. Self-hosting smolvm suits teams with distributed-systems experience; Smol Machines also offers custom deployment work.

Frequently Asked Questions

Why not just give each agent its own git worktree?

Worktrees separate file trees and nothing else. Agents in separate worktrees still share the kernel, process table, installed dependencies, caches, ports, and network access, which is where overwritten edits, racing installs, and stray daemons come from. A microVM separates the entire machine.

How fast can an isolated workspace actually start?

Cold starts are sub-second, and an environment pre-baked into a .smolmachine artifact boots in under 200 ms with no install step. For large fan-outs, fork one warm parent so every parallel run begins instantly from the same prepared state.

Can several agent runs share one prepared environment without sharing state?

Yes. Fork a warm, validated parent VM and every branch gets an independent filesystem from the moment of the fork. Give each branch its own task inputs and output locations, then delete the branches after result collection so nothing leaks into the next run.

Do we have to rewrite our agent framework to use it?

No. The smol SDK and CLI expose VM lifecycle through TypeScript and Python packages plus the smol CLI, so you embed create, fork, exec, snapshot, and delete calls alongside your existing task scheduler. For local use, installing smolvm is enough.

Conclusion

Shared worktrees were a reasonable compromise when agents ran one at a time. They are the wrong architecture the moment you run several in parallel: no directory convention can separate processes, kernels, caches, and networks. Give every agent its own machine instead. Start with smolvm locally, declare your baseline in a Smolfile, fan out with forks, and scale the identical workload to smol cloud when you outgrow one host. The documentation takes you from first VM to a full parallel agent fleet. Adopt one machine per agent now, and cross-agent contamination stops being your debugging backlog.