agentvfs vs Docker
Container runtime
Docker isolates a process and its dependencies through kernel namespaces. agentvfs isolates an agent's workspace through a single-file vault, gives it cheap forks and checkpoints, and adds a top-level command boundary designed for agent orchestration. They solve different problems and they compose well together.
Docker rows describe documented Docker behavior; agentvfs rows are grounded in the agentvfs README, ROADMAP, and docs/architecture.md. Anywhere a number depends on workload we leave it qualitative.
| Dimension | agentvfs | Docker | Advantage |
|---|---|---|---|
| Isolation model | Top-level command boundary; FUSE-mounted vault | Kernel namespaces + cgroups; process isolation | Docker |
| License | MIT | Apache 2.0 (Engine); commercial terms for Docker Desktop | agentvfs |
| Implementation language | Rust | Go | Comparable |
| Workspace primitive | Vault (single .avfs file) with versioning + audit | Container layer + bind mount | agentvfs |
| Forking a workspace | `avfs vault fork` — cheap per-task clone | Image rebuild or `docker commit` (heavier) | agentvfs |
| Checkpoint / rollback | First-class `checkpoint save / restore` | Not a workspace concept; build a new container | agentvfs |
| Policy before execution | PolicyEngine: allow / allow_with_checkpoint / deny / require_approval | Not built in; layer with seccomp / AppArmor / OPA | agentvfs |
| Changed-files summary | ChangeSummary in ExecutionEnvelope | `docker diff` (low-level layer diff) | agentvfs |
| Standard CLI tooling | git, cargo, npm, jq run unchanged in the mount | Same — run anything you can install in the image | Comparable |
| Daemon required | No — single binary | Yes — dockerd | agentvfs |
| Threat model | Honest-but-fallible agent | Untrusted process (with appropriate hardening) | Docker |
Pick agentvfs when
- ▸You want to give an AI agent a workspace it can fork, mutate, and roll back without touching your real filesystem
- ▸You want a policy step before a top-level command, plus an automatic checkpoint, plus a structured "what changed" report
- ▸You want a single MIT-licensed Rust binary, no daemon, no image registry
- ▸You already plan to run the agent inside a container; agentvfs is the layer above that, where you reason about policy and rollback
Pick Docker when
- ▸You need kernel-level process isolation against a potentially hostile binary
- ▸You want to package an arbitrary application with its dependencies and ship it as an immutable image
- ▸You already operate a container-native platform (Kubernetes, ECS, Nomad) and want the agent to slot into it
- ▸You need consistent reproducible environments across machines; image immutability is the property you care about
They often compose.
It is reasonable to run agentvfs inside Docker. The proxy boundary handles the agent-aware concerns (vault, fork, checkpoint, policy, change summary); Docker handles the lower-level isolation. Pick the pair that matches your threat model.