An agent that can only talk is a chatbot. An agent that can do things — clone the repo, run the tests, edit the files, hit the database — needs a machine to do them on. That machine is the part nobody wants to talk about.

Because the moment your agent runs code, three questions you were ignoring become urgent: Where does it run? What can it reach while it's running? And who else can see what it touched? The convenient answer to all three is "some container in some vendor's cloud, in some region, next to some other tenants, we don't really say." For a weekend hack, fine. For a client's codebase or anything with real data in it, that's not an answer — it's a shrug.

I wanted the where to be the point, not the footnote. That's NautLoop.

The platform, not the swarm

NautLoop gets described as "the thing that runs agent swarms," and it does — but leading with the swarm sells the wrong thing. The swarm is a workload. The platform is a place to run any agent workload with the isolation and the jurisdiction nailed down.

Underneath is a sandbox fabric: each job gets its own Firecracker microVM — a real virtual machine with a real kernel boundary, not a shared container — that boots in a couple of seconds, does its work, and is thrown away. Disposable is the security model. Nothing an agent did survives except the artifact you asked for; there's no long-lived box accumulating state and blast radius.

Sovereign isn't a slogan here

"Sovereign" gets sprayed on a lot of infrastructure that just means "we have a data centre in Frankfurt." I mean something you can point at:

  • Jurisdiction you choose, and can prove. A job pins to the EU or to Switzerland, and it runs on infrastructure that's actually there — the fabric runs across Hetzner in the EU and Infomaniak in Switzerland precisely so "runs in Switzerland" is a demonstrable fact about where the microVM booted, not a marketing region label.
  • A control plane that holds nothing. NautLoop orchestrates the sandboxes but is designed to hold no tenant data. The place that coordinates your jobs is not a place your code and data pile up. That's deliberate: the coordinator being a breach target is how most platforms quietly become the thing they promised to protect you from.
  • Local models by default. The inference an agent needs can run on open models on the node itself, so a sandbox can do real work with zero egress — nothing about the task leaves the boundary to reach a model API. When a call does go out, it goes through a gateway on the node, not straight to a vendor.
Why zero-egress is the whole game

Isolation that still phones home isn't isolation. If your "private" agent sandbox ships every prompt to a model API to think, you've moved the leak, not closed it. Running the model inside the boundary is what lets a sandbox be genuinely sealed — it can read the sensitive repo, reason about it, and hand back a diff without the sensitive part ever crossing the line. That's the difference between private and private-ish.

Four layers, each with one job

The reason this holds together instead of being a pile of features is that each layer does exactly one thing and hands off cleanly:

  • NautLoop — the control plane. Decides what runs where; holds no tenant data.
  • GitVM — the sandbox fabric. The Firecracker microVMs themselves: boot, isolate, execute, destroy.
  • NautGate — a per-node LLM gateway. Every model call inside a sandbox goes through it, which is where routing and the receipts live, one node at a time.
  • Engram — mesh and memory. How agents that should share context do so, under an explicit policy, instead of by accident.

You can read the seams in that list: execution is separate from coordination is separate from inference is separate from memory. Each can be reasoned about — and audited — on its own. That separation isn't architectural vanity; it's what makes a claim like "this data never left Switzerland and never reached a cloud model" something you can actually check, layer by layer.

What you'd actually run on it

Two workloads make the shape concrete:

  • The swarm — a coding-and-research loop where you bring your own agent (Claude Code, Codex) and let one worker, or a fleet of them in parallel, grind through build/test/fix inside the sandboxes. Same agent you already use; a place to let it off the leash safely.
  • NautScribe — private voice transcription: audio in, text out, local models, zero egress. A boring-sounding task that is exactly the kind of thing you cannot responsibly hand to a random cloud endpoint when the audio is a client call or a medical note.

Different jobs, same guarantee underneath.

The honest bit

This is more machinery than most people need, and I'll say so plainly: if you're building a hobby agent to rename your files, you do not need jurisdiction-pinned microVMs. Reach for this when the where actually has consequences — regulated data, client confidentiality, a contract that says your code doesn't touch third-party clouds. That's a real and growing set of situations, especially in the Swiss and German market I build for, and for that set the usual "somewhere in the cloud" answer isn't good enough.

It's the same instinct as everything else I write about here — own the boundary — scaled up from a single search box to the whole machine an agent runs on. Give an agent hands, and the responsible next question isn't "how smart is it." It's "where is it standing, and what can it touch from there." NautLoop is me refusing to let that question stay a shrug.