Stealing 50 Years of Database Ideas for AI Agents | OneWill

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.

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:

1. 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).
2. 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.

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
  Action 1: Will obtains 500g of peanuts from the store’s hopper
    Store.peanuts: before=6700g, after=6200g
    Will.peanuts: before=0g, after=500g
  Action 2: Will grinds the peanuts into a container
    Will.peanuts: before=500g, after=0g
    Will.peanut_butter: before=0g, after=500g
  Action 3: Store charges Will $7 for the peanut butter
    Will.cash: before=$25, after=$18
    Store.cash: before=$1000, after=$1007
T1 commits

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 away with peanut butter, but before all the updated state is persisted (e.g., the register crashes after printing the receipt), recovery uses the after images to REDO the writes. Together, UNDO and REDO make the outcome all-or-nothing and durable.

At this point, you might be thinking: isn’t this pretty straightforward? Yes! And yet somehow today’s default agent experience is rawdogging your state. The closest we’ve seen to this concept in the wild is still post-mortem; they record what the agent does, they may even define an agent by what it did, but there’s a reason WALs get into the write path.

Although WALs have many uses (e.g., replication), as a broad concept, it’s hard to innovate beyond the WAL for regular data management. But what if we re-imagine the WAL for action management instead?

Historically speaking, action management wasn’t that big an issue because most actions were initiated by reasonable humans. We don’t make crazy assumptions like “this deletion API is probably just staging” or develop periodic amnesia that leads to us ignoring critical instructions. Even though humans make mistakes, we generally develop enough of a sense of danger to distinguish between harmless actions and risky actions, allowing us to take the appropriate precautions.

Agents operate differently. Today’s agents play a funny trick on you by asking for your permission to ls and rm -rf in the same unassuming approval flow. The burden is on you to notice that a tool call is one approval away from creating a disaster. This is exacerbated by using autonomous agents for more consequential tasks that involve files outside of version control (e.g., presentations), networked API calls, and computer-use.

As people who burn a decent amount of tokens, we’ve often found ourselves performing forensics to figure out (1) what an agent did, (2) why it did it (e.g., what input it saw), and (3) whether there was an easy way to reverse its effects. In practice, this looks a lot like crash recovery. Database systems don’t make you manually scan disk blocks after a crash because they apply actions in the right order: they record how to recover from an action before applying it. Applying this ordering to agent actions also provides a governance mechanism: before an action is executed, we either record enough information to reverse it later or require explicit approval before letting it run.

At OneWill, we’re in the business of re-imagining database technology for the agentic age. Our thesis is that to effectively control agent execution, we need a database-like transactional interface between speculative agent work and durable world mutations. This is especially important as agents run for longerIf trajectories were short, you could probably get away with good forking technology. But we regularly run goal mode for hours or days, so it's pretty wasteful to have "blow away the entire system" as a rollback strategy. and interactSome people default to thinking that this is simply git. But even today, a lot of useful state lives outside of version control, such as calendar and email. Now add computer-use on top of that. with computers directly.

In short, we think that the WAL architecture is the answer to today’s agent controllability problems. It provides a principled method for structuring the chaos of numerous agents into a semantic action stream. But existing solutions in a similar reversibility and/or governance space require you to instrument your source code or modify the agent, where the burden is still on you - any problems are user error, good luck!

Enter Wally, OneWill’s first release. It is based on the decades-proven database WAL architecture, now applied to agent actions. Our goal is to provide a drop-in experience that delivers precise control over agent actions. The insight here is that even without changing the agent, you can still change its behavior by modifying the world around it.

Conceptually, the most interesting part of this project is defining UNDO and REDO semantics for arbitrary agent actions. We've encountered three types of actions so far:

• Perfectly Reversible: like a git-tracked file.
• Compensable: you can cancel a calendar event but you cannot unsend the invitations.
• Irreversible: once you send an email, you can’t take it back.

Quick sketch of how this all works: WAL, FUSE, VPN, MITM, frame buffers, interposition. To limit the length of this blog post and prioritize based on reader interest, we’re deferring in-depth technical details to future posts; join our Discord server to vote on what we should write about next.

At the time of writing, you will probably encounter a series of unfortunate production events if you try vibe-coding this yourself with the frontier models (shoot us an email if that changes!). But you don’t have to build this yourself, you can use and contribute to what we made instead.

Our public prototype currently demonstrates the action stream, coding agent integrations (claude, codex, agy), support for enforcing local AI usage, and some use cases around our technology. That includes: enhanced git diff for "what did the agent do overnight," enhanced filesystem view for "what did the agent see when it made this change," and basic rollback functionality. Here's a video:

Try it now on the web for free: demo access. We'll provide instructions with your access code. You can actually run a beta build locally today on Ubuntu and macOS, but because we're still simplifying the macOS permissions menus, we encourage macOS users to stick with the web version for now.

We aim to open-source the core WAL and various useful primitives in the coming weeks. We'll announce on Discord when we do. Stay tuned!

We post open roles to our Discord server.

At the time of writing, our next likely hire is in engineering. We value (1) experience with agents (e.g., you should be comfortable productively burning 500M to 1B tokens a day) and (2) a background in database systems (e.g., completing the online version of CMU's 15-445). If this sounds like you, please reach out!

For collaborations and design partnerships, please email [email protected].

---

Join our Discord server to vote on blog topics and get notified when new posts go live!