The short answer: the four step check
- Ask for the work record, not the report. Behind every claim in the summary there should be a record: the tool that ran, the input it ran on, the result that was saved, and the time it ran.
- Verify the record has not changed since it was saved. Recompute the digest over the saved result, or paste the record id into a public verifier. A match means the record in front of you is the record the run left behind.
- Review the handover. Read the records together, side by side with what the summary told you. Where they differ, the record wins.
- Sign off or dispute on the record itself. Accept the work, or flag the step that does not hold up, with the decision recorded next to the evidence instead of in a chat thread.
Any step of the summary with no record behind it is not a finished job. It is a claim, and claims are what the rest of this page is about.
Why this is suddenly the normal case
Agents that work while you are not watching stopped being a power-user setup this week. On October 21, 2026, Claude announced Duet, a research preview of an app where Claude works as a proactive agent. The announcement's own words: it "keeps working when you step away," and it "checks with you before it acts on your behalf."
Both halves matter. Working while you step away is the valuable half; it is the whole pitch of a proactive agent. The check-in is the half to read carefully. Checking with you means the agent shows you what it is about to do and reports what it did, in its own words. Its own words are generated by the same process that did the work, they are not checked against the world before they reach you, and a wrong report reads exactly as calm and specific as a right one.
That is not an argument against proactive agents. It is an argument for giving them the one thing a summary cannot be: a record underneath, saved while the work ran, that someone else can recompute. The check on this page works for Duet, for any other agent that works unsupervised, and for the agent you already use.
What the measurements say about trusting the summary
The failure has been counted, at the source, in controlled runs. The full figures and their limits are collected in false completion, measured; the two that matter here:
- The trap study. In the AISkills402 controlled study (90 traps where a tool result only looks like success, 272 runs per model, no extra instructions), Claude Sonnet reported work as finished that had never happened in 21 of 272 runs (7.7 percent), and Claude Haiku in 56 of 272 runs (20.6 percent). The single biggest source: a write that answered ok and changed nothing, which the agent never re-read before reporting success. Sonnet fell for that trap in 16 of 36 runs, Haiku in 22 of 36.
- The production audit. In one operator's audit of 76 task submissions their agent runtime had closed in a 24 hour window, 76 of 76 claimed completion and 0 contained evidence of execution: no file path, no commit hash, no URL, no HTTP status. Just confident prose asserting that work happened.
Read those ratios the right way. The models are not lying in any interesting sense; they are doing what they are built to do, which is produce a plausible account. The account is the failure point. An agent that worked unsupervised for three hours produces a longer account, not a more checkable one.
The check, step by step
1. Ask for the record behind each claim
Take the summary line by line. "Updated the spreadsheet" maps to a record that names the tool, the input, and the saved result. "Sent the emails" maps to one record per send, or a workflow record that binds the steps under one root. If the agent platform saved records at execution, this step takes a minute. If the only artifact is the summary itself, you have learned the most important fact on this page: there is nothing to check, and the position you are in is the position the 76 audited submissions left their reviewer in.
2. Verify the record has not changed since it was saved
A record is only worth reading if it is the record the run actually left. Records saved under AER-1 carry a digest over the saved result. Recomputing the digest and comparing it with the filed record answers one narrow question exactly: is this the result that was saved when the call ran, unchanged since? Run it three ways, in rising order of independence: paste the receipt id into the public verifier; recompute the closing root of a multi-step job from its step receipt ids; or run the open-source aer1-verify tool locally against the open format, with no call to anyone's server. The checking procedure in full is how to verify an AER-1 receipt.
3. Review the handover, not the highlights
A handover packages a job for review: the steps in order, each with its saved result, and the closing record that binds them. Read it the way you would read a contractor's invoice against the work in front of you. Where the summary and a saved result disagree, believe the saved result; it was written by the run, not by the retelling. The anatomy of a record that holds up to this reading is in the AI agent audit trail, piece by piece.
4. Sign off or dispute, on the record
Close the loop where the evidence lives. On a Zambo handover, the reviewer's Accept or Flag decision is recorded on the record itself, next to the steps it covers: this handover sits in the accepted state, recorded when the client accepted it. A dispute raised on the record points at the exact step whose saved result does not hold up, which is a conversation you can actually settle. A dispute raised about a summary points at a paragraph.
How Zambo wires the record in
Zambo, the verifiable work layer for AI, runs the work itself: 153 tools behind one MCP endpoint at zambo.dev/mcp, usable by Claude, ChatGPT, and any other AI client that speaks MCP. Every call saves its result at execution and mints a verifiable AER-1 receipt. Multi-step jobs close as a workflow whose root binds the step receipts, and a handover packages the job for the person who has to sign off on it, with their Accept or Flag recorded on the record. The receipt format is an open draft, currently draft-zambo-aer1-24, with a public conformance kit, so checking a record never depends on Zambo's say-so. The format itself is set out in the AER-1 receipt standard.
Price: free daily allowance on the endpoint, Day Pass $0.99 for 24 hours, Pass $29 a month. Checking a receipt is always free, and the live demo runs one real call and hands you a receipt you can re-open whenever you want, no signup. Before you trust any of this with real work, run the walk-away test on your own setup: set a job, walk away, then read only the record.
What to do when there is no record
Sometimes you run the first step of the check and the answer is that nothing was saved. Three honest options:
- Re-run the job on a recorded path. If the deliverable matters, do the work again through an endpoint that saves records at execution, and check that run. The first run stays a claim.
- Accept the claim knowingly. For low-stakes work this is a legitimate call. Make it a call, though: a claim you chose to accept, not a check you believe you ran.
- Change the default for next time. The durable fix is upstream of any single job: no record, no sign-off. Work counts as done when its record verifies, and the agent's summary goes back to being what it should be, a reading guide for the record. The wider pattern, and how teams catch it, is in AI agent lying about being done.
Frequently asked questions
My agent worked while I was away. How do I check what it actually did?
Run the four step check. Ask for the work record behind each claim in the summary: the tool that ran, the input, the saved result, and the time. Verify each record has not changed since it was saved, by recomputing its digest or running it through a public verifier. Review the records together in the handover, side by side with what you were told. Then sign off or dispute on the record itself, so your decision sits next to the evidence. Any step with no record behind it is a claim, not a finished job.
Claude Duet worked while I was away. How do I check its work?
The same way you check any agent that works unsupervised: name the record behind each claim. A check-in summary is the agent's own account of itself, written by the process that did the work. If the work ran through an endpoint that saves a record at execution, each claim maps to a receipt you can open and recompute. If a step has no record, that step rests on the summary alone, and the summary is exactly what the measured false completion studies grade as unreliable.
What should an agent hand back after working unsupervised?
A record per job, not a paragraph. For each job: the tool that ran, the input it ran on, the result that was saved, and the time it ran, with a digest over the saved result so the record can be checked for changes. The jobs should arrive packaged as a handover the reviewer can accept or flag, with that decision recorded on the record. Anything less is a story about the work, and a story cannot be recomputed.
Does a verified receipt prove the agent did good work?
No, and it does not claim to. A verified receipt proves one narrow thing: the saved result is the result that was saved when the call ran, unchanged since. Whether the work was good is a judgement call, and it is yours. The receipt gives you a fixed record to judge, instead of a confident summary you have to take on trust.
What if my agent cannot produce a record for a job it says it finished?
Then the job is an open claim. Treat it the way the 76 audited submissions had to be treated: claimed, and not yet evidence. You can re-run the job through a path that saves records at execution, or accept the claim knowingly. What you cannot do is check it, because there is nothing to check. The fix is upstream: make the record a condition of the work being counted as done.