Agents Need Computers. Humans Need Monitors.

I once told an agent to move a directory. It deleted the original first, then tried to copy it. Too late. The code was gone.

The model had not invented anything. It executed an ordinary filesystem operation in the wrong order. I did not need another response. I needed the previous state back.

Most agent demos skip this part because nothing survives them. The agent gets a prompt, calls a tool, returns a result, and the environment disappears. Nobody has to inspect the filesystem, stop a stale service, or decide which state to restore. That clean reset is doing more work than the demo admits.

Agent tooling keeps expanding what a model can touch: more files, commands, services, and data. Every new permission also creates one more change a human may have to inspect or undo later.

The usual agent demo has a clean shape:

prompt -> tool call -> result

That loop leaves out what happens when agents work on real software: files, services, background jobs, database migrations, environment variables, logs, caches, secrets, running processes, and weird local setup decisions nobody remembers making.

When the environment survives the request, so do the questions. What changed? What was running? What did the agent install or delete? If I restore, what am I about to overwrite?

Imagine this is your checkpoint list:

checkpoint_9ac31f
checkpoint_b71e02
checkpoint_0f12dd

An agent has been working for 30 minutes. It installed packages, edited files, started a service, changed a config. Something is broken and you want to go back.

Which checkpoint would you restore?

I had three checkpoint IDs and no idea which one still had a working app. The restore command existed. The information I needed to use it did not. I could not tell whether verification had passed, whether the bad change had already happened, or what a restore would overwrite.

At minimum, checkpoint context should answer five questions:

task
files_changed
verification_status
app_health
restore_will_overwrite

What was the agent trying to do? What files changed? Did verification pass? Was the app healthy? What do I lose if I go back? Verification does not have to mean a full test suite. It can mean a smoke test, a health endpoint, or whatever check that project uses to know the app was alive.

The same list with context looks like this:

10:02 AM - Clean repo cloned. Verification passing.
10:11 AM - Before auth refactor.
10:18 AM - After package install. Verification failing.
10:27 AM - Working version. Preview healthy.

Now I can choose the last known working state instead of gambling on a hash.

By computer, I mean a bounded persistent environment with a filesystem, packages, running services, a URL, lifecycle controls, and checkpoints. Work can continue beyond one request without giving the agent an unbounded machine.

A disposable sandbox works for one contained execution. My agent needed to clone a repo, install dependencies, run tests, start a dev server, inspect logs, make changes, sleep, and continue the next day. That required persistence plus permissions and limits.

A Sprite provides that shape: a persistent Linux environment that can write files, install packages, expose URLs, sleep, wake, checkpoint, and restore. The same recovery problem applies to any persistent agent environment.

A persistent environment keeps useful work and bad changes alike. I needed to see both before deciding whether to restore.

This is why I built Sprite Agent Workbench.

The CLI is fast when I know the command I need. After an agent has been working, I first need to reconstruct what happened: which environment it used, whether it is running, which URL maps to it, what changed, and whether verification passed.

RecallMEM, my local-first AI memory app, runs inside a Sprite. Before letting an agent work on it, I created a checkpoint from the Workbench with context attached: the task I was about to hand the agent, verification passing, the app responding at its URL.

Then the agent worked. The Workbench showed the change and the failing check sitting next to the checkpoint that predates both.

I restored. RecallMEM came back, verification went green, and the bad change was gone. I knew which checkpoint to choose because I could see the state attached to it.

The deleted directory at the start of this post belonged to RecallMEM. I had no checkpoint before the change and no record of the operations leading up to it. I was left reconstructing from memory what had existed five minutes earlier.

The agent did not go rogue or hallucinate an API. It made a normal-looking change in the wrong order. A human might pause before the destructive step. The agent did not.

A checkpoint with context is manufactured hesitation: the missing pause moved into the system around the agent.

MCP gives agents a standard way to reach tools and context. It can also expand the set of files, services, databases, repositories, APIs, and private data an agent can affect. The tool response does not explain every consequence left in the environment.

A fair question: why not just use git?

You should use git for source code. But an agent environment also includes installed packages, generated files, local database state, running services, caches, and environment files. A commit cannot tell me whether the service was healthy or what a filesystem restore will overwrite.

Git records code history. Checkpoints capture environment state. I need both.

The old model was:

agent = model + tools

For persistent work, the model is closer to:

agent system = model + tools + computer + state + checkpoints + history + recovery

The model can get smarter. I still need to know what it changed and where I can safely go back.

Agents need computers. Humans need monitors.

Questions about this post? Ask the terminal on my homepage — it knows this whole site.

Chris Dabatos

Staff DevRel Engineer @ Fly.io, AI Engineer, and Technical Storyteller based in Las Vegas. He builds things with AI and writes about what breaks.