Direct answer
It deleted the files. Now prove what it actually did.
The damage is done and the agent has already moved on to its summary. What you need is not its version of the story. You need the run itself: every call it made, in order, with what came back. Here is how to reconstruct what happened, what a per-step record proves after the fact, and where the honest limit sits when the work was never recorded at all.
Updated October 17, 2026.
The first hour: stop the run, keep everything
Before any reconstruction, freeze the scene. Pause the agent and revoke or rotate the keys it was using, so nothing else runs while you work out what happened. Then gather what still exists before it rotates away: backups and snapshots, trash and recycle locations, file version history, database backups, and the platform logs for the window in question. Write down your own timeline while it is fresh: when you last saw the files intact, what you asked the agent to do, and when you noticed the damage.
One warning that matters: do not send the same agent back in to help clean up. Every repair attempt it makes is another set of actions, and if those run unrecorded they bury the original trail under new changes. Reconstruct first, repair second.
Reconstruct the run: three sources, in order of strength
The per-step record, if the work ran through a recording connection. When an agent works through Zambo, every tool call writes a verifiable receipt at the moment it runs: the call that was made, the result that came back, and the time the step was saved, in order. A destructive run reads plainly in that record. The step that deleted the folder is there with its target and its returned result. The step that dropped the table is there. So is everything before and after, which is what separates an accident from a misunderstanding about the instructions.
Platform and provider logs. Cloud consoles, database logs, and app audit trails often hold part of the story. They are worth pulling in the first hour, before retention windows close. Their weakness is structural: they are kept by the operator of the system, they can be edited or pruned, and they rarely line up step for step with what the agent was asked to do.
The chat transcript. The weakest source, and usually the only one people reach for. A transcript is a summary the agent produced, often after the fact. It shows what the agent says it did. After a deletion, that distinction is the whole argument.
What the record settles, and how to read it
Line the record up against the three questions every incident comes down to. What ran: the calls themselves, in order, not a retelling. What each call returned: the saved result, including failures and refusals, not just the successes. When each step was saved: the times that turn a vague "sometime last night" into a sequence you can check against backups and logs. If the agent claims it only removed temporary files, the record either shows only temporary targets or it does not. The claim stops being something you argue about and becomes something you read.
The public handover records elsewhere on this hub show the same shape on ordinary work: every step listed with the time it was saved, and an acceptance state on top. One record's client checked four of four steps and accepted; another still sits pending. An incident run is the same list read for a worse reason.
The honest part: if the work was never recorded
If the agent ran with no recording in place, the record of that run does not exist, and no tool can create it after the fact. A receipt proves the saved result was not changed since it was saved; it cannot be backdated, and any service offering to reconstruct a proof after the incident is selling you a story, not evidence. What you have is backups, version history, and whatever logs the platforms kept. Use them, and let the gap be the lesson the next section fixes.
Set up so the next incident answers itself
Run agents through a connection that records every call as it happens, so the record exists before anyone knows whether the run will matter. Keep destructive tools behind a sign-off gate, where a person approves the specific action before it runs, and keep spend caps on the same connection so a bad night is bounded as well as recorded. Then make review a habit: one page shows everything your AIs did today, each line backed by its receipt, so a strange step gets noticed the day it happens instead of the week the files are missed.
Frequently asked questions
My AI agent deleted my files. How do I prove what it actually did?
Start by freezing the scene: pause the agent, rotate its keys, and pull backups, version history, and platform logs before retention windows close. Then reconstruct from the strongest source you have. If the work ran through Zambo, every tool call wrote a verifiable receipt as it ran, so the run reads step by step: the call, its target, the result that came back, and the time it was saved. The deletion is a step in that list, not a rumor. If the work ran unrecorded, no proof can be created after the fact, and you are working from backups and logs alone.
Can a receipt be created after the fact for work that was never recorded?
No. A verifiable receipt is written at the moment a call runs, and it proves the saved result was not changed since it was saved. Backdating one would break the very check that makes it worth anything. Anyone offering to mint proof of a past unrecorded run is selling a story. What you can do after an incident is preserve every surviving source, and put recording in place so the next run is provable from the first step.
My agent says it only deleted temporary files. How do I check that claim?
Read the targets, not the summary. In the per-step record, each deletion call names what it acted on and carries the result that came back. If only temporary files were removed, the targets say so. If a project folder or a production table is in the list, the claim fails on the record itself. Where no record exists, compare backup contents and version history against the claim, and treat anything the agent cannot point to in a saved source as unproven.
What is the difference between the chat transcript and the record?
The transcript is what the agent says it did, written as a summary, sometimes polished after the fact, and it can be edited like any other text. The record is written at call time, before the outcome is known: each step saved with its result and its time. Checking the record is a recompute, not a reread. That is why the transcript loses an argument the record settles.
How do I make sure this cannot happen silently again?
Three changes, all cheap. Run the agent through a connection that records every call as it happens. Put destructive tools behind a sign-off gate, so a person approves the specific deletion or schema change before it runs. And review the day page, where everything your AIs did sits on one page with a receipt behind each line. The Day Pass covers 24 hours of recorded work for $0.99, no subscription, which is enough to cover the next run end to end.
Your AI said "done." For $0.99, prove it: https://zambo.dev/day-pass/