Version control for agent context

Agents make mistakes. They overwrite something they shouldn't, mangle a document, or take a wrong turn that leaves their working context in a mess. When that happens you want two things: the damage contained to one isolated environment rather than spreading, and a way to put things back the way they were before the agent got it wrong.

Exabase gives you both at the level of the agent's data. A Base is an isolated filesystem and knowledge store, and filesystem snapshots let you checkpoint that store before a risky operation and restore it afterward. It's version control for an agent's context: you can browse what a Base looked like at a point in the past and roll back to it. This page is about using that to give agents a safe place to work and an undo button when they go wrong.

One clarification up front, because it matters for what you'd build. Exabase isolates and versions an agent's data, its files, context, and knowledge store. It is not a code-execution sandbox that runs the agent's process or contains its outside side effects. The rollback restores the Base's filesystem to an earlier state; it doesn't reverse actions an agent took in other systems. The isolation and the undo are for the agent's context, which is the part this page is about.

The problem

An agent that can modify its own working context is useful and a little dangerous. The usefulness is obvious: an agent that can write files, update documents, and reorganise its knowledge can do real work. The danger is that the same freedom lets it corrupt that context, and without isolation and rollback you're left cleaning up by hand or, worse, discovering the mess only after it's propagated.

Two problems sit underneath this. The first is isolation: if an agent operates directly on shared, live data, a mistake isn't contained, it affects everything that data touches. You want the agent working in an environment where an error stays put rather than spreading. The second is reversibility: even contained, a mistake needs undoing, and "undo" over a filesystem means having the earlier state saved and restorable. Without snapshots, the state before the agent's mistake is simply gone, and you're reconstructing it from memory or backups that may not be granular enough.

Building this yourself, per-agent isolated stores plus a snapshot-and-restore mechanism over them, is a meaningful piece of infrastructure, and it's the kind of safety scaffolding that tends to get skipped until an agent does something destructive and there's no way back.

What Exabase unlocks

With isolated, snapshottable Bases, an agent gets a safe place to work and you get a way to undo its mistakes.

The agent's context is isolated. It operates inside a Base, its own filesystem and knowledge store, so whatever it does is contained there rather than touching shared or live data. If you're running experiments or letting an agent operate more freely, you can do it in a Base set aside for the purpose, where a mistake affects only that environment.

You can checkpoint before anything risky. Before an operation you're unsure about, take a snapshot, and the Base's state at that moment is saved. If the operation goes well, carry on; if it goes wrong, restore the snapshot and the context is back as it was, without manual repair.

And you can see the history. Snapshots let you browse what a Base looked like at past points and revert to any of them, which is version control for the agent's data: not just a single undo, but a timeline you can move back along. The state before a bad run isn't lost, it's a snapshot you can return to.

How it works

Two primitives carry this: Bases for the isolated environment, and the snapshotting built into them for the rollback.

Bases

A Base is a fully isolated environment with its own filesystem, knowledge store, and search. For this use case the important property is that it's a contained space an agent can work in: anything the agent does to its files and context happens inside the Base and doesn't reach outside it. You can give an agent its own Base, or set up a separate Base for testing and experiments, so risky work is isolated from anything that matters. Creating a Base is a single API call, so spinning up an isolated environment for an agent, or a fresh one for each run, is cheap. The general isolation pattern is covered in multi-tenant memory for SaaS.

Filesystem snapshots

Filesystem snapshotting is the rollback mechanism. A snapshot captures the state of a Base's filesystem at a moment in time, and you can restore the Base to any snapshot later. You take one before a risky operation as a checkpoint, and revert to it if the operation goes wrong. Because you can keep multiple snapshots, you get a history of the Base's state to browse and revert across, rather than a single level of undo. This is what turns an isolated environment into a safe one: isolation contains a mistake, and snapshots undo it.

Example architecture

The pattern is checkpoint, operate, and either keep going or roll back.

Give the agent a Base. Create a Base as the agent's isolated filesystem and knowledge store, or a dedicated Base for testing and experiments. Work stays contained to it.

Snapshot before risk. Ahead of an operation you're not sure about, take a snapshot to checkpoint the Base's current state.

Operate, then decide. Let the agent run. If the result is good, continue, the snapshot stays as a restore point. If it's bad, restore the snapshot and the Base returns to its pre-operation state.

Reset between runs if you want a clean slate. For repeated experiments, restore to a baseline snapshot, or delete and recreate the Base, so each run starts fresh.

The agent works inside an isolated Base, you checkpoint before anything risky, and you roll back the Base's state when needed. The isolation keeps mistakes contained; the snapshots make them reversible.

What compounds over time

The value here isn't really about accumulation the way it is for memory or a knowledge base; it's about confidence, and that grows as you lean on agents to do more.

The more an agent is allowed to modify its own context, the more useful it is and the more a mistake would cost, so the ability to contain and undo errors is what makes giving an agent that freedom reasonable in the first place. As you build more capable agents that take more consequential actions on their data, having isolation and rollback underneath is what lets you do it without each new capability being a new way to lose work. The snapshot history also means you can experiment freely, trying things in a Base knowing you can always return to a known-good state, which is the kind of safety that makes iteration faster rather than more cautious.

Building this scaffolding yourself, isolated per-agent stores and a snapshot-restore layer over them, is infrastructure you'd maintain rather than feature work on your product. Having it as a property of the Base means the safety is there from the start instead of being the thing you wish you'd built after an agent deletes something important.

Who's building this

Teams building agents that modify files or their own working context, autonomous agents doing multi-step work on a data store, and anyone testing agent behaviour who wants a contained, resettable environment to do it in. It's especially relevant where an agent has enough freedom to do damage and you want a way back.

The isolation here is the same primitive behind multi-tenant memory for SaaS, and the snapshot capability supports any use case where agents act on shared context, including multi-agent coordination where several agents work in one Base. For agents that write code, project context can live in a snapshottable Base, as in coding assistants with project memory.

Get started

Start with the getting started guide, then about Bases, creating Bases, and especially filesystem snapshotting for the checkpoint-and-restore mechanism. There's a free tier to build against.

FAQs

Is this a place to run my agent's code?

No. Exabase isolates and versions an agent's data, its filesystem, context, and knowledge store, rather than running the agent's process. The agent executes in your environment; what Exabase provides is an isolated, snapshottable store for its context. If you need a code-execution sandbox, that's a separate thing from what this offers.

What exactly can I roll back?

The state of a Base's filesystem. A snapshot captures the Base's files and context at a moment, and you can restore the Base to that snapshot. It rolls back the agent's data, not actions the agent took in other systems.

Can I keep more than one checkpoint?

Yes. You can take multiple snapshots and revert to any of them, so you have a history of the Base's state to browse and move back along rather than a single undo.

How do I keep one agent's mistakes from affecting others?

Give each agent its own Base. A Base is fully isolated, so an agent's changes are contained to its own environment and can't reach another's.

How do I reset to a clean state for repeated tests?

Restore to a baseline snapshot, or delete and recreate the Base. Either gives each test run a known starting point.

Does rolling back undo actions the agent took outside the Base?

No. Rollback restores the Base's filesystem state only. Anything the agent did in external systems is outside what a snapshot captures, so design accordingly when an agent takes actions beyond its own context.