NautsAI software & research
Back to NautLoop

NautLoop / Guide 3 of 3 / 3 min read

Beneath the bonnet: microVMs and messages

How the control plane creates temporary environments, agents coordinate their work and results survive the sandbox.

The reason

An agent needs somewhere to work, and a way to return the result.

Parallel tasks should not all share the same files, credentials and dependencies. Each assignment needs an execution boundary and a clear owner.

NautLoop builds on temporary GitVM environments. Work runs in a sandbox with a defined lifetime, then code and artifacts come back before that environment expires.

48Nauts / Product guides · In development

From a task to a running sandbox

Task entry

CLI or connected development tool

Request an environment, send work and collect results.

↓ Authenticated control requests

GitVM control plane

Project and sandbox records, template selection and scheduling. The documented gitvmd service includes an API, SQLite storage and dashboard.

↓ Schedule on a compute node

Compute node → Firecracker microVMs

The node manages VM execution through KVM. Each sandbox has its own working environment and a time-limited lease.

↓ Separate task workspaces

Sandbox A

Assigned code and tools
Build, run or test
Configured preview URL

Sandbox B

Separate assignment and workspace
Its own configured access
Independent results

↓ Copy back code and artifacts before teardown or lease expiry

Retained results

Keep the deliverable outside the temporary VM. Stopping the sandbox destroys its workspace.

NautLoop coordination design · in development

Lead and specialists

The lead assigns work and collects contributions. Engram supplies signed agent messaging and optional memory; NautGate supplies model routing and usage records. Integration availability depends on the deployment.

Logical overview from the GitVM technical guide and NautLoop docs. The broader managed platform is still in development.

NautLoop builds on GitVM sandbox infrastructure. The control plane receives an authenticated request, records the sandbox and schedules it on a compute node. The node runs the virtual machine. Separating these jobs lets the system manage environments across more than one host.

The GitVM guide describes gitvmd as the service containing the API, project records, scheduler and dashboard, with SQLite for its state. A node service manages Firecracker microVMs through Linux KVM. Templates supply the starting environment, rather than asking every task to assemble a machine from scratch.

Separate execution environments

A microVM is a small virtual machine with its own guest kernel. Its purpose here is to run an assigned build, test or agent task away from the development machine and other tasks. A sandbox can contain the repository and tools needed for that work without receiving the whole contents of your laptop.

Isolation still needs an access policy. Decide which credentials enter the VM, what network destinations it can reach and which service ports it exposes. A separate machine does not make every command safe or prevent a credential you deliberately supplied from being used.

A workspace with an expiry time

The GitVM CLI follows a directory-scoped workflow. Warm up an environment, synchronise the working directory into /workspace, then run commands there. A configured exposed port can provide a URL for inspecting the application while it is running.

Each sandbox has a lease. TTL means time to live: once that lifetime ends, the temporary environment can be reclaimed. This makes a sandbox useful for a test or preview without treating it as permanent hosting.

Pull code changes and artifacts back before stopping the VM or letting the lease expire. The CLI has separate operations for pulling the workspace and downloading artifacts. Teardown destroys the sandbox workspace, so the deliverable must exist elsewhere before that happens.

  1. 01Create from a template
  2. 02Send code and run the task
  3. 03Inspect or test the result
  4. 04Copy back code and artifacts
  5. 05Stop or expire the sandbox

Signed agent communication

The NautLoop coordination design gives a lead the job of dividing the task and collecting specialist contributions. Specialists work in separate environments and exchange messages through the agent mesh, rather than assuming they share one filesystem.

Engram supplies the messaging and optional memory layer in this design. Signed messages can be checked against trusted keys, but a signature does not establish that an agent reached the right conclusion. The lead and reviewer still need to assess the returned work.

Routing, memory and current scope

NautGate supplies the model-routing and usage-recording layer. Optional Engram memory retains selected findings beyond the life of a sandbox. Keeping that memory is a separate choice from keeping the VM alive: temporary execution does not mean every associated record is automatically deleted.

The broader NautLoop platform is still in development. Its documents describe xNaut integration both as available and as upcoming, so this chapter does not promise that every managed workflow is ready. The GitVM sandbox lifecycle is the concrete technical foundation described here.