· VerifyCore Labs
When an AI assistant dies halfway through a change
An AI assistant dies halfway through a change to files and a database: what our crash-recovery layer and tool tests show, and what random crashes found.
Who did this. The lab’s AI agents did the research and engineering. Nick Harris, founder. CTO of VivaMed BioPharma; co-founder of MedSim.ai, FastRead.io and Formulai. The lab’s track record.
AI assistants are moving from answering questions to acting on real systems: they edit files, write rows into databases and call outside services. Each action can be correct on its own and still leave a mess when a multi-step change stops halfway. This post is about two results from our lab that deal with that moment: what they show, who would use them, and what they do not claim.
The half-done change
Picture an assistant asked to update a customer record, move a file and log what it did. Three ordinary steps. Now the program running the assistant is killed after the second one. The record is updated and the file is moved, but the log is missing. Nothing in the assistant knows to finish the job or undo it, because the process that knew is gone. The lab’s record puts the problem this way:
An assistant whose program dies halfway through a multi-step change can leave files and database rows half-updated, with nothing to finish or undo the change afterwards
Databases and file systems solved this long ago with a write-ahead journal: write down what you intend to do before you do it, and recover from that record after a crash. Our agents built that design into a transaction layer for an AI assistant’s tool calls. What the lab set out to show, in its own plain words, with the condition it attaches:
When an AI assistant carries out a multi-step change to files and one database table, the lab's transaction layer is meant to either complete all of it or undo all of it — but only for plans it admits in advance
At the moments the lab chose, that is what its test found. At random moments it was not always so, as the sections below show.
A crash test that can fail
A claim like that is only as good as the crash test behind it. The lab killed the running program, for real, at moments chosen in advance, and each time started a fresh program that recovered from the journal on disk. In the lab’s words:
killed at 29 moments the authors chose, the program each time recovered a clean all-or-nothing state from its on-disk log in a fresh process, while a deliberately broken version did not
It also ran a deliberately broken version of the layer as a control, and that version did not recover cleanly. So the test caught at least one deliberately broken layer. It did not catch the failures that kills at random moments later found, which are described below.
What random crashes found
Moments chosen by the authors test what the authors thought of. So the lab also killed the program at random moments, thousands of times. The layer recovered all-or-nothing at every moment the lab chose; the random campaign found recoveries that were not atomic, some of which undid work that had already been committed, and the lab publishes their count:
2,893 further kills at seeded random moments found 31 recoveries that were not atomic
That figure is recorded in the lab’s claim; the run record is not published.
We publish that next to the result because it is what a buyer needs before relying on the layer. The lab has not fixed those failures yet. The kills also stopped the program without cutting the power, so the order in which the journal’s writes reach the disk is still untested.
The design covers only plans the layer admits in advance: at most one action that cannot be undone, such as sending a message, and only as the last step. Other plans are refused or handed to a person.
Tools that are safe alone and dangerous together
The second result looks at another way an assistant’s work goes wrong. A platform that approves an assistant’s tools one at a time or in pairs judges each tool, or each pair, on its own. The lab built a test world with ten tools, one stored secret and outlets it designed, and, by its account, ran every sequence of up to three tool calls against real files and a real database (this site does not show how the runs map onto the sequences):
2,379 executed sessions against real files and a real SQLite database
What it found, in the lab’s own plain words:
In a test world the lab built … the lab ran every sequence of up to three tool calls (2,379 runs on real files and a real database) and found three smallest combinations that leak the secret, each the secret-reading tool followed by an outlet and only one of them a pair
A check that looks at tools two at a time misses two of those three. Ordinary tracking of data from the secret to an outlet, known as taint analysis, would catch all three; what this adds is an executed record, which the lab reports as exhaustive, of which combinations are dangerous in one constructed world.
Who this is for
Teams that run AI assistants on real systems: agent platforms, and the runtime-security teams that decide what those assistants may touch. For them the questions are concrete. If the assistant dies mid-change, is the system left whole? If a combination of tools leaks, which one, and would our approval rules have caught it?
Why now
Research groups have begun publishing transaction layers for tool-using AI agents, among them Cordon and SagaLLM. Ours publishes a crash test with a deliberately broken control and a record of leaking tool combinations in one constructed test world. This site does not show how it compares with Cordon’s or SagaLLM’s own evaluations.
What we do not claim
- The layer covers only plans it admits in advance, with at most one action that cannot be undone, placed last.
- The crash test killed the program; power loss is untested.
- Random-timing kills found failures that the lab has not fixed yet.
- The tool-combination result is from one test world the lab built. The safeguard that enforces it lets each approval be used once, but it remembers that only while the program is running: after a restart, a used approval works again.
Crash recovery for AI assistants’ multi-step changes: the full result