Everyone optimizing agents is staring at the model. Meanwhile the biggest chunk of wall-clock time in a background agent session is often the setup: clone the repositories, install the dependencies, write the skills to disk, then finally start the actual task. Do that once and it is a minor tax. Do it on every session across an organization running hundreds of sessions a day and it is the dominant cost of the whole system.
The fix is boring and decisive: snapshots. Build a virtual machine image on a schedule with the repos already cloned, dependencies already installed, skills already embedded. When a ticket comes in and an agent picks it up, the session starts on a warm machine and goes straight to work. Nothing about this is glamorous. It is also the difference between an agent that responds in seconds and one that spends its first minutes doing janitorial setup before it writes a line of code.
The second half of the argument is what that machine should be. Not a stripped container with a filesystem and a prayer. A full computer: browser, editor, terminal, enough memory to build a real monorepo. An agent fixing a bug in a web app should be able to open the app in Chrome and look at it. An agent changing a build should be able to run the build. Verification is what separates production agents from autocomplete, and verification requires a machine capable of running the software, not just holding the source.
This is why I keep saying the gap is infrastructure, not intelligence. The models crossed the capability threshold for most engineering tasks a while ago. What has not caught up is the plumbing underneath them, and cloud development environments are exactly that plumbing for parallel agent work. Snapshots, warm pools, full VMs per session. Table stakes, once you see it.
If your agents feel slow, profile the session before you blame the model. You will probably find a git clone where your latency lives.
Key takeaways
- Agent latency is dominated by environment setup, cloning repos, installing dependencies, and writing skills to disk on every session.
- Scheduled VM snapshots that bake in repositories, dependencies, and skills let every session start on a warm machine instead of a cold one.
- Agents need full computers with a browser, editor, and terminal, because verifying work requires running the software, not just generating it.
FAQ
Why do background agents need full virtual machines instead of containers?
Because an agent doing real engineering work needs what a developer needs, a browser to load the app, a terminal to run builds and type checks, and an editor over the full codebase. Stripped-down containers force the agent to guess where a full machine lets it verify.
What goes into an agent VM snapshot?
The repositories the agent works on, installed dependencies, and embedded skills, rebuilt on a schedule so it stays current. When a session starts from the snapshot, the agent skips cloning and installing and goes straight to the task.
Related Essays
The Agent Harness Problem
Enterprise agents need layered interfaces, real software skills, and flexible platforms. The harness around the model matters more than the model.
Your Agent Instructions Are Rotting
Every new model reinterprets your old agent instructions. The discipline that matters now is deletion, and almost nobody practices it.
Agents Are Software, and Software Needs a Factory
People talk about agent harnesses as if the harness is the interesting part. It is not. The interesting part is the factory — sandboxing, orchestration, persistence, model translation.
Drowning in pull requests that need your review? Try Tembo Review, a beautiful AI-assisted PR review tool unlike anything you’ve used.