Stealing 50 Years of Database Ideas for AI Agents | OneWill

Jul 1, 2026

Stealing 50 Years ofDatabase Ideas for AI Agents

Introducing OneWill, or: why write-ahead logging is better than letting agents rawdog your computer.

Authors: Wan Lim and Will Zhang<br>Reviewed by: Andy Pavlo, Carnegie Mellon University's Databaseologist<br>100% organic human-written gluten-free text

TL;DR

Want to give autonomous agents access to your state (e.g., files, calendar, email, shell) without blindly trusting them? Check this video out and sign up for demo access here: it's a full-featured desktop environment that lets you try everything from your browser. We're also working on open-sourcing, stay tuned!

Behind the scenes, OneWill's technology interposes agent actions with database magic to make it so that before any action runs, it must either be reversible (details below) or explicitly approved by you. We provide you peace of mind and broaden the scope of work that you can hand off to agents.

Discord

GitHub

LinkedIn

The agent-state pickle

If you’re a systems developer, modern coding agents probably make you slightly uncomfortable, and computer-use agents even more so. Letting agents mutate real state directly is bonkers. But we’ve all ended up in a pickle:

The more state you giveYou could choose to give no state (blank VM) or a staged environment (sandbox). But how often does staging actually look like production? your agents, the more useful they are (e.g., calendar, email, shell).

Yet the more state you give your agents, the bigger the consequence of failure (say goodbye to your database and email).

The worst part of this deal is that there are essentiallyAuto mode gives us trust issues. If the problem is that we don’t trust models, why is the solution to trust another model? only two modes of agent operation: babysit it with approval-in-the-loop, or YOLO by dangerously skipping permissions. If anything goes wrong, you take the hit.

But it doesn’t have to be this way! We’re trying to protect our valuable state from flaky, crashy, and occasionally insane agents. Well, databases have long learned to deal with flaky, crashy, and insane hardware. The trick is in identifying the right semantic abstraction for making changes to the world.

A crash course on crash recovery

Don’t worry about crashing. Just never lose data.

Database Company Mandate

In life, it’s ok to make mistakes as long as you can recover from them. This applies to crashing too. A full lecture on crash recovery is outside the scope of this blog post; you can find one here. We’ll just recap the bits we need.

Crash recovery algorithms have two components: the bookkeeping you perform during normal operations to ensure recoverability, and the actual recovery procedures for picking up the pieces. There are two key primitive actions, UNDO and REDO. UNDO is pretty intuitive: it cleans up after incomplete or aborted operations. REDO backs the promises made by the system: if the system says something happened (e.g., transaction commit), it re-applies the effects of operations to make sure that reality matches.

Most modern database systems use a write-ahead log (WAL) for recovery. The basic idea is to write down enough recovery metadata about the intended operation, in a way that ensures the record survives crashes, before the operation’s effects are allowed to persist. That way, even if you crash halfway through, you have all the information required to perform the necessary UNDO and REDO actions. For example, suppose Will is using a supermarket’s grinder to turn 500g of peanuts into peanut butter. Then transaction T1 is:

T1 begins<br>Action 1: Will obtains 500g of peanuts from the store’s hopper<br>Store.peanuts: before=6700g, after=6200g<br>Will.peanuts: before=0g, after=500g<br>Action 2: Will grinds the peanuts into a container<br>Will.peanuts: before=500g, after=0g<br>Will.peanut_butter: before=0g, after=500g<br>Action 3: Store charges Will $7 for the peanut butter<br>Will.cash: before=$25, after=$18<br>Store.cash: before=$1000, after=$1007<br>T1 commits<br>There are many ways that buying self-ground peanut butter can go wrong. If the hopper gets stuck, Will may only get some of the peanuts. If the grinder clogs, Will may lose his peanuts without getting peanut butter. Broadly speaking, the problem with naively modifying state directly is that the system may crash at any step. A good system records intent durably before allowing an action’s effects to persist.

But with a WAL, handling crashes is relatively straightforward. If the system crashes before T1 commits, recovery uses the before images to UNDO the writes: roll back the effects of any uncommitted actions to their original values. In practice, not every action can be undone cleanly: how do you turn peanut butter back into peanuts? In those cases, you can apply compensating actions, such as ordering more peanuts or setting the peanut butter aside. If it crashes after T1 commits, meaning Will has paid the store and walked...