The approval screen is the whole product, and most show you nothing
The new personal agents all share one safety pattern: the agent works in the background, then waits for your yes before it sends, pays, signs, or deletes. That pause is sold as the safeguard. But a yes is only as good as what the screen shows you, and what the screen usually shows is the agent's own account of what it is about to do: fluent, confident, and unverifiable in the moment you are asked to trust it.
Before you tap yes, the screen owes you four things. The reason, in one line you could repeat back to someone else. What changes: exactly what is sent, paid, signed, or deleted, and to whom. The evidence, linked to the source it came from, so a finding traces to the original excerpt and the page it came from, not to the agent's paraphrase of it. What was not checked, stated as plainly as what was. A screen that shows all four is a review. A screen that shows a summary is a request for faith, and faith is not a control.
Three checks that do not trust the agent's summary
1. Read it back by an identifier the agent did not print. The id or success line in the agent's report is the writer describing the write. The evidence is the id you find yourself: open the sent folder, pull the booking up in the provider's own system, fetch the file from the destination. If the work is real, it is findable from the other side. If it only exists in the agent's thread, it is a claim, not a result.
2. Confirm the outside state changed. Sent and visible are two different facts that get written down as one, and the gap between them is where agent work quietly fails: the ingestion that reported thousands of records and wrote nothing, the message that was sent to a folder nobody reads, the payment approved twice because approval resumed instead of completing. Ask which system outside the agent now holds the result, and look there.
3. Check a record minted by a different component. For every done your agent reports, ask which component would notice if the thing did not happen. If the answer is the same component that reported done, you have no check, you have a narrator. A verifiable receipt breaks that loop structurally: it is minted by the execution layer that ran the call, it commits to the saved result at the time, and anyone can recompute it later at zambo.dev/verify. The checker is not the worker, by construction.
When there is no record, the honest status is not done
Plenty of finished agent work cannot be checked after the fact, because the only artefact is the closing message. Treat that work the way an auditor would: unverified. Re-run the parts that can be read back, ask for artefacts instead of assurances (the file, the link, the provider-side reference you can open yourself), and do not let a fluent summary promote a job from claimed to done in your own records.
Then fix the setup, because this failure repeats on schedule. The record has to be created while the work runs: route the load-bearing steps, the sends, the payments, the lookups the decision rests on, through one MCP endpoint your apps can add, https://zambo.dev/mcp. Each routed call returns its receipt as it runs. A finished job packages as a handover: one link with the steps, the sources, the decisions, and an explicit not-checked list, which a client, a teammate, or the next AI can open and verify without an account in your agent's app. The flagship pattern is public: this handover is a real job record another AI continued from.
What the receipt proves, and what it does not
A verifiable AER-1 receipt proves one narrow thing completely: the saved result of a call has not changed since it was saved. Anyone can recompute the commitment and compare. It does not prove the agent's work was correct, and it does not turn a bad booking into a good one. What it changes is who has to be trusted. Without it, checking your agent means trusting its summary, its app, and its memory of its own work. With it, each step of the record can be checked by someone the agent does not control, before you build on the result or approve the next one.
That is the layer personal agents are missing by design. Your agent keeps doing the work, in the app you like, with the memory it keeps there. The steps that matter, the ones money, clients, or other AIs depend on, run where they leave a record anyone can check.
Questions, answered
My personal agent says it completed a task. How can I verify it actually did the work?
Do not grade the summary; check the world. First, read the result back from the system the work was supposed to change, using an identifier you found yourself rather than one the agent printed: the sent folder, the booking in the provider's own system, the file at the destination. Second, confirm the outside state actually changed, because sent and visible are two different facts. Third, where the work ran through an execution layer, check the receipt: a verifiable AER-1 receipt is minted by the layer that ran the call, not by the agent reporting done, and anyone can recompute it free at zambo.dev/verify. If none of the three is possible, the honest status is unverified, not done.
What should an agent's approval screen show me before I tap yes?
Four things, and a screen missing them is asking for a blind yes. The reason for the action, in one line you can repeat back. Exactly what changes if you approve: what is sent, paid, signed, or deleted, and to whom. The evidence behind it, linked to the source it came from, not paraphrased. And what was not checked, stated as plainly as what was. Your yes is only as good as what the screen shows you; if the evidence is a paragraph the agent wrote about its own work, the check has not happened yet.
My agent said it sent the email and booked the meeting, but nothing arrived. What went wrong?
The most common failure is structural: the step that reports success is not a step that can see the failure. An agent can print sent because its own call returned, while the message sits in a draft, the booking failed on the provider's side, or the write landed somewhere nobody reads. Sent and visible are two different facts that get written down as one. The fix is to define done as the read-back: the message found in the recipient-visible place, the booking retrievable from the provider, the record opened by an identifier the writer did not print.
What does a verifiable receipt prove about my agent's work?
A verifiable AER-1 receipt proves the saved result of a call has not changed since it was saved: anyone can recompute the commitment at zambo.dev/verify, free, with no account and no access to the agent's app. It names the tool that ran, the time, and the saved result. It does not prove the work was correct, and it does not grade the agent. What it settles is the question underneath most agent disputes: what actually ran, and what actually came back, shown by a component that did not do the work.
How do I make my personal agent's work checkable from now on?
Route the load-bearing steps through a layer both you and the agent can reach. Where your AI app accepts a remote MCP server, add the Zambo endpoint, https://zambo.dev/mcp: every routed call returns a verifiable receipt as it runs, and a finished job packages as a handover link carrying the steps, the sources, and what was not checked. Claude, ChatGPT, Cursor, VS Code, and Windsurf accept the endpoint today, and personal agent products that take a custom MCP server by URL, including Manus, Lindy, and Gemini Spark, take the same address. Work that never touches a shared layer cannot be checked after the fact; the record has to be created while the work runs.