Deploy agents you can roll back

The agent works. It reads the right context, makes reasonable decisions, produces good output. The next step is letting it write: create files, update records, reorganise things, delete what is no longer needed.

This is where most teams stop. A bad run in a read-only setup is a poor answer. A bad run with write access is corrupted data, and if the agent is operating in a customer's workspace, that corrupted data belongs to someone who trusted your product with it. So the agent ships with its capabilities turned down, and the thing you built is running at a fraction of what it was designed to do.

This page is for teams whose blocker is trust rather than capability.

What you have probably already tried

Every workaround here is a trade between what the agent can do and how much damage it can cause.

Confirmation prompts on every write put a human in the loop, which caps throughput at human speed and trains users to click through the prompts anyway. You have added friction without adding much safety.

Draft mode, where the agent proposes and a person applies keeps the human in control and removes most of the value, because the work you wanted automated is now a review queue. It also does not scale past the point where reviewing takes as long as doing.

Scoping the agent to a safe subset works, and it means the agent is useful for the operations that did not really need automating and locked out of the ones that did.

Backups are the honest attempt and the granularity is wrong. A nightly backup restores yesterday, not the state five minutes before a specific agent run, and restoring it means rolling back everything else that happened in between.

Extensive testing before deployment reduces the frequency of bad runs without changing what happens when one occurs. Agents operate on inputs you did not anticipate, which is rather the point of using them.

The pattern is that each of these manages the consequences of having no undo. None of them provide one, which is why the agent stays throttled.

How Exabase handles this

Bases support filesystem snapshotting. Every write to a resource is captured automatically, so you can query a Base as it existed at any past point, including resources that have since been deleted.

In practice: snapshot before a risky operation, let the agent run at full capability, inspect what it did, and restore if something went wrong. You can diff between states to see exactly what changed rather than guessing. Granularity is hourly within the last 24 hours and in six-hour windows from one to seven days, with configurable retention, and what is included at each plan level is on the pricing page.

What this changes is the question you are asking. It stops being "do I trust the agent enough to let it write," which is unanswerable in advance, and becomes "can I recover if it gets something wrong," which has a yes. That is a much easier decision to make, and it lets the agent ship with the autonomy it was built for.

One thing to be clear about, because it determines what you can design around it. This versions the data inside a Base: files, resources, and the agent's working context. It does not reverse actions the agent took in external systems. An email that was sent stays sent, and a third-party API call that succeeded stays succeeded. Snapshots cover the agent's own state, so if your agent acts on the outside world, design for that boundary rather than assuming rollback covers it.

What changes

Agents that were shipping in restricted mode can ship properly. The confirmation prompts, draft queues, and narrowed permissions were all compensating for the absence of a recovery path, and with one in place they can come off.

It also changes how you iterate. Testing an agent's behaviour on real data is normally risky enough that teams do it sparingly, on copies, or not at all. With a restore point, you can run it, look at what it actually did, and revert, which makes the feedback loop on agent behaviour much faster than reasoning about it in the abstract.

For the fuller architectural treatment, version control for agent context covers checkpointing and isolated environments in depth, and if several agents are working in the same shared context, multi-agent coordination covers snapshotting shared state before a risky stage.

Get started

The Bases page has the API detail for snapshotting and restore. Version control for agent context is the end-to-end pattern, and AI infrastructure for developer tools covers the case where the agent is operating on project state. There is a free tier to build against.

FAQs

What exactly can I roll back?

The state of a Base's filesystem: files, resources, and the agent's working context, including resources that were deleted. You can query the Base as it existed at a past point and restore to it.

Does rollback undo things the agent did in other systems?

No. Snapshots cover the agent's own data inside the Base. An email that was sent, a payment that was processed, or a third-party API call that succeeded are all outside that boundary, so design for external side effects separately rather than assuming a restore covers them.

How far back can I go, and how precisely?

Hourly granularity within the last 24 hours, and six-hour windows from one to seven days, with configurable retention. Plan specifics are on the pricing page.

Can I see what changed before deciding to restore?

Yes. You can diff between two states to see exactly what the agent altered, which is usually how you decide whether a run was good rather than restoring blindly.

Is this a sandbox for running agent code?

No. It isolates and versions the agent's data rather than executing the agent's process. Your agent runs in your environment; what Exabase provides is an isolated, restorable store for the context and files it works on.

How is this different from backups?

Granularity and scope. A nightly backup restores an entire system to yesterday, which also reverts everything else that happened since. Snapshots let you restore one Base to a point minutes before a specific run, so a single agent's mistake does not require rolling back unrelated work.

Can I use this to test agent behaviour on real data?

That is one of the more useful applications. Snapshot, run the agent against real content, inspect what it did, then restore. It gives you a fast feedback loop on behaviour without the risk that normally keeps teams testing on copies.

Does each customer's environment get its own snapshots?

Yes. Snapshots are per Base, so in a multi-tenant product each customer's state is versioned and restorable independently. Shipping multi-tenant covers the isolation model.