Each agent gets a tiny fortress.

Normal containers share a kernel. If one container is told "go read the other guy's files," it can probably find a way. We can't have that. Firecracker is a tool that wraps each pod in a real virtual machine, so the wall between agents is the same wall between two laptops on the same desk.

The problem we are solving

A normal Docker container is not a real machine. It's a process with some fences around it. Linux uses tricks (namespaces, cgroups, seccomp) to make the process feel isolated. But it's still sharing the Linux kernel with every other container on the same node. One nasty bug in the kernel and one container can read every other container's memory.

This is fine if you trust everything running on your node. It is not fine if your business is "run code on behalf of strangers and customers who don't want their data to leak."

Firecracker, in one paragraph

Firecracker is a tool from AWS. They invented it to run AWS Lambda. It boots a real virtual machine in about 125 milliseconds, with a real Linux kernel inside, completely separated from the host. Each Firecracker VM is called a "microVM" because it's stripped down to almost nothing: no drivers you don't need, no boot screens, no nonsense. Just enough Linux to run your process.

The wall between two Firecracker microVMs is the same kind of wall between your MacBook and the Windows laptop next to it. Hardware level. To get from one to the other, you need a bug in the CPU, not a bug in some Linux feature.

Kata Containers, in one paragraph

Kubernetes doesn't know what Firecracker is. It only knows how to start containers. Kata Containers is the translator. It pretends to be a normal container runtime to Kubernetes, but under the hood, each "container" it starts is actually a Firecracker microVM. You add one config line to your pod (runtimeClassName: kata-fc) and Kubernetes is happy. Your pod gets a real VM.

Why not gVisor?

gVisor is the competitor. Google built it. Same idea (better isolation than regular containers) but it works by intercepting system calls instead of running a real VM. Cheaper to run. Weaker wall.

• gVisor: catches every syscall, simulates it in user space. Lower overhead, no real VM. Used by Google Cloud Run. Solid against most attacks.
• Firecracker: actual hardware-level virtualization. Stronger wall. Used by AWS Lambda and Fly.io.

For Houston specifically: we are running customer code (agents) on shared infrastructure, with an open marketplace where some agents will be community contributed. That means we should assume some agent code is hostile or buggy. Firecracker is the right answer for that threat model. We can switch to gVisor as an option later if the cost story demands it.

The performance question

"Doesn't booting a VM per agent make everything slow?" Used to be true. Not anymore.

• Firecracker cold start: ~125 ms to boot the VM itself.
• Add Houston engine startup: another few hundred ms.
• Total user-facing delay on first message after idle: roughly half a second.
• Subsequent messages: zero overhead. The VM is already running.

Half a second of "agent waking up" is a feature, not a bug. It maps perfectly to scale to zero (Chapter 4), which means idle agents cost nothing.

What this gets us

• Hardware-level isolation. The HR agent literally cannot reach the Sales agent's files because it's a different VM with a different kernel.
• Per agent OAuth tokens are safe. Each pod has its own credentials. Compromise one, you compromise one. Not all.
• Compliance answers write themselves. "How are agents isolated?" "Each one runs in its own Firecracker microVM." Conversation over.
• Community agents are safe to host. Someone publishes a malicious agent? Worst case it owns its own pod. Can't escape.