Pets vs Cattle in AI Sandboxes (And Why We Use Garbage Collection)
Why treating AI workspaces as ephemeral cattle is the secret to scaling autonomous engineering.
In cloud computing, there is a famous paradigm: Pets vs. Cattle.
- Pets are servers you name, care for, and nurse back to health when they get sick. If a pet dies, it’s a tragedy.
- Cattle are servers that are numbered, identical, and easily replaced. If a cow gets sick, you replace it.
When it comes to AI coding agents, the industry is currently building pets. Developers spin up persistent, long-lived dev environments for their AI, treating them as precious workspaces that must be maintained, synced, and protected.
At OutcomeDev, we believe this is fundamentally the wrong approach. AI sandboxes should be cattle.
The Problem with Persistent Sandboxes
When you treat an AI workspace as a pet (a persistent sandbox), you inherit all the problems of legacy software development:
- State Corruption:
node_modulesget corrupted, hidden files pile up, and uncommitted changes linger. - Zombie Costs: Cloud providers charge you for storage and compute long after the task is abandoned.
- Reproducibility Failure: If an agent succeeds in a dirty environment, you can't guarantee it will work in production.
Our Approach: Ephemeral by Default with Auto-Garbage Collection
We treat sandboxes as transient compute units—cattle.
Instead of relying on the sandbox's disk to remember what happened, we rely on the ultimate source of truth: Git (where code and state are committed on dedicated task branches).
To provide the best user experience without the infrastructural bloat, we use an Auto-Garbage Collection (GC) approach:
- Warm Windows: While you are actively iterating on a task, the sandbox stays alive and persistent. This allows for lightning-fast follow-ups ("make the button blue") without re-cloning the repo.
- Aggressive GC: As soon as a task is marked as "Completed," "Cancelled," or sits idle for 24 hours, the Bouncer (our infrastructure proxy) triggers an automatic garbage collection. The sandbox is wiped from existence.
Bouncer: The Traffic Cop
The Bouncer is our centralized proxy that acts as the gateway to all sandboxes. It enforces:
- Wake-on-Request: Booting up cold sandboxes instantly when a request arrives.
- Billing Enforcement: Ensuring compute time is tracked and billed accurately.
- The Idle Death Trap: Automatically identifying and terminating unmetered or abandoned sessions.
By coupling the Bouncer with Auto-Garbage Collection, we get the "crème de la crème" experience: the speed of persistent environments during active development, with the cost-efficiency and cleanliness of ephemeral compute.
Memory Beyond the Disk
If sandboxes are ephemeral, how does the agent remember anything?
The answer is that memory doesn't belong on a transient VM disk. It belongs in a Git-tracked workspace branch and dynamic database-immortal chat histories. The intelligence outlives the infrastructure.
You don't need a pet server. You just need a very smart cow, a good garbage collector, and a permanent memory bank.