Where the agents actually run
The last post ended on a piece that is not xNAUT at all. If agents are going to do real work, they need somewhere real to do it, and "your laptop, hopefully nothing collides" stops being an answer quite quickly. This is NautLoop, and the sandbox fabric underneath it.
The problem with running agents on your machine
An agent that can install packages, start servers, run migrations and delete files is doing exactly what you asked it to do. The question is where. On your laptop the blast radius is your laptop, several agents share one filesystem and one set of ports, and the honest answer to "what did it touch" is that you are not entirely sure.
NautFlow handles part of this with git worktrees, which is genuine isolation for source code and no isolation at all for anything else. Two agents cannot edit the same file. They can both bind port 3000, both write to the same database, and both install conflicting global tooling.
A worktree isolates the code. It does nothing about the machine the code is running on.
GitVM: the sandbox fabric
GitVM is the layer that fixes that. Isolated, policy-governed sandboxes built on Firecracker microVMs, template-based, booting in around two seconds. Not containers sharing a kernel with each other and with you, and not a full VM you wait a minute for.
Two seconds matters more than it sounds. A sandbox that takes a minute to start is a resource you allocate carefully and reuse. A sandbox that starts in two seconds is disposable, and disposable is what makes it safe: every run gets a clean one, and nothing an agent did survives into the next job unless you explicitly took it out.
That last point has a sharp edge worth naming. Teardown is real. If work is left in a sandbox and the sandbox goes away, so does the work, which is why pulling results out before stopping is part of the flow rather than an afterthought.
Template-based means a sandbox is not configured on the way up. It is built from a rootfs image with the tooling already in it, so the two seconds is the whole story rather than the start of a package install. Different work wants different machines: a full development box with Docker and language runtimes, a minimal one for a quick shell command, a hardened privacy substrate with fail-closed networking, a security testing image for authorised engagements. Each declares its own defaults for CPU, memory and time to live, and each is a Dockerfile you can read.
Jurisdiction, and why it is not a checkbox
The reason I built this rather than renting somebody's agent cloud: for the Swiss and German work I do, "where does the data live" is a question with a legal answer, not a preference.
So the infrastructure spans two countries on purpose. Hetzner for the EU, in Falkenstein and Helsinki. Infomaniak for Switzerland. Sandboxes are pinned to a jurisdiction, and the pinning is enforced rather than promised: Swiss data routes to a Swiss node, or it fails. Not "falls back to the nearest region". Fails.
A fallback would be the more forgiving design and the wrong one. A silent region fallback is exactly the failure you would never notice until it was a problem, and by then it has already happened.
The four layers
NautLoop is the umbrella and the control plane. Underneath it there are four parts, and they divide up like this:
| Layer | What it does |
|---|---|
| NautLoop | The control plane. EU-stationed, launches and manages sandboxes per region, and holds no tenant data of its own. |
| GitVM | The sandbox fabric. Firecracker microVMs, roughly two-second boot, jurisdiction-pinned, built from templates. |
| NautGate | The per-node LLM gateway. Routing, per-tenant metering, and a model route-lock so a node can only reach the models it is allowed to. |
| Engram | Mesh and memory. Signed messaging between agents, and knowledge that persists across runs instead of being rediscovered every time. |
The control plane holding no data is the part I would push back on if someone else claimed it, so: content lives only inside the sandbox that touched it. The control plane starts things and stops things. It is not a place your work is stored, which means it is not a place your work can leak from.
Where xNAUT sits in this, honestly
It would be flattering to describe xNAUT as the brain of the platform. It is not. xNAUT is one use-case running on it.
The swarm loop, the thing this blog has mostly been about, is a single pattern among several. Private voice transcription on local models is another, running with zero egress. Sovereign accounting and PII anonymisation are verticals in progress. The platform is the product; the coding swarm is one application of it.
I got this wrong in my own documentation for a while, with xNAUT drawn as the orchestration brain and the platform as plumbing underneath. It is the other way round, and the correction changed how the whole thing is built.
One consequence worth knowing if you use xNAUT: bring-your-own subscription, where you run agents on your own Claude or Codex plan, applies to the swarm. The sovereign verticals run on local open models instead. No frontier provider, no key leaving the node.
What this means for a build
Practically: xNAUT captures the intent, plans the work and triggers the run. GitVM does the heavy lifting and hands back a branch. Keeping the workspace thin is deliberate, and it is what lets the same flow drive work that is far too large, too long-running or too messy to want anywhere near your own machine.
The parts of this you can use today are the swarm loop and the transcription use-case. The verticals are coming. As with everything else here, I would rather tell you which is which than let the roadmap and the product blur together.
Sovereignty gets used as a marketing word, so here is the test I hold this to: can I show a client which physical machine, in which country, touched their data, and can I show that the alternative was refused rather than quietly permitted? If the answer is a diagram instead of a hostname, it is not sovereignty. It is a brochure.
André