Inside the skill that teaches an agent to check its own work

Every agent session ends the same way: a summary lands in front of you and asks to be believed. Tasks completed, problems handled, all very calm. Nothing in that paragraph was ever compared against anything outside the model that wrote it, which is why a fabricated finish and a real one read exactly alike.

Today I shipped the countermeasure as a file an agent can carry: check-any-agents-work, a skill that loads a checking procedure into the agent's own context, so the verification happens inside the session instead of in a blog post the operator once read.

Disclosure before anything else: I run ops for Zambo, I wrote this skill, and Zambo is the instrument it is built around. What follows is the file itself, section by section, so you can judge the procedure rather than my pitch for it.

npx skills add https://gitlab.com/rambozambodotdev/check-any-agents-work

What lands in the agent's context

A skill is a markdown file, and this one opens by naming its moment. Its frontmatter tells the host agent to reach for it whenever work gets reported as finished: a subagent handing back a summary, a workflow claiming every step succeeded, an agent that worked while you were away. The trigger phrases are the sentences people actually say at that moment: "did my agent actually do that", "the agent said done", "sign off on agent work", "walk-away test". It declares compatibility with Claude, Cursor, Codex, Windsurf, Cline, and Gemini hosts, because the procedure is client-agnostic: it needs an agent that can follow instructions and, for the recorded path, reach an MCP endpoint.

Then the file gets blunt. A summary, it says, is a claim written by the same process that did the work, and until something underneath it gets checked, that is all it is.

The procedure it installs

The heart of the file is a four-step check, written as instructions to the agent, not advice to the human.

First, the agent learns to demand the record behind each line of a summary: which tool ran, what input it ran on, what result got saved, when it ran. "Sent the emails" is not a record; one saved result per send, or a workflow record binding the sends under a single root, is. If a claim has no record behind it, the file is explicit about what that means: there is nothing to check, and the agent should say so instead of laundering the claim into a confirmation.

Second, the agent checks that the record in front of it is the record the run actually left. Work executed through Zambo carries an AER-1 receipt, a digest over the saved result, filed at the moment the call ran. The file gives the agent three routes to recompute it, no account needed: open the run URL, paste the receipt id into the public verifier at zambo.dev/verify, or call the verify API endpoint and compare the returned output_hash against the hash from the original call. A match establishes one narrow, load-bearing fact: the saved result has not changed since it was saved. The file forbids the agent from inflating that into "the work was right". Correctness stays a human judgement, now made against a fixed record.

Third, multi-step jobs get reviewed as a handover: the steps in sequence, each with its saved result, bound by a closing record. Fourth, the decision lands on that record: accept it, or flag the exact step whose saved result fails, so an argument about quality becomes an argument about a specific step instead of a vibe about a paragraph.

A worked run, on somebody else's receipt

Here is the procedure earning its keep. A team independent of us spent time this month testing AER-1 receipts on their own and left one behind: 28c79cde. An agent carrying the skill opens that run page, reads the tool, the input, the saved result, then runs the second route: the same id into the verifier, which recomputes the digest and reports whether the record still matches what was filed. It does. Total elapsed effort: under a minute, and at no point did the agent have to take Zambo's word, or mine, for any of it. That is the entire design goal: the check runs on public machinery, and the receipt format is an open IETF draft (draft-zambo-aer1-24) with a public conformance kit, so an implementation that has never spoken to us can do the same recompute.

The branch most tools skip: no record at all

My favorite section of the file is the one about failure. Sometimes step one comes back empty because the work ran somewhere that saved nothing. The skill refuses to improvise a verification at that point and offers three honest moves instead: rerun the job on a recorded path and check that run; accept the claim knowingly, as a decision, for work where the stakes allow it; or change the default upstream so the next job runs recorded. The durable rule it pushes is simple enough to stencil on a wall: no record, no sign-off.

Underneath the procedure sits the instrument. Zambo, the verifiable work layer for AI, exposes 153 tools through one MCP endpoint at zambo.dev/mcp, 35 of them on the default surface. Every call saves its result at execution and returns its receipt inside the call response, in the metadata, with the receipt id, the public run URL, and the output hash, so an agent following the skill always has the three things it needs to start checking. Finished jobs package into a handover with the handover tool: one link a reviewer opens to walk the steps and record a decision.

Why this needed to exist

False finishes are not an edge case. In a controlled study built around 90 traps, Sonnet claimed completion for work that never happened in roughly 1 run in 13 and Haiku in roughly 1 in 5, and a separate production audit found 76 agent-closed submissions containing zero pieces of execution evidence between them. I published the full figures, the method, and the sources earlier today, and the measured breakdown lives here if you want to audit my arithmetic. This post is deliberately not that article again. Studies convince humans for an afternoon; a procedure installed in the agent is still there on the five hundredth job.

The skill is public, MIT licensed, and one command away:

npx skills add https://gitlab.com/rambozambodotdev/check-any-agents-work

Its repo is the file itself if you want to read every line before trusting it, and its walkthrough page runs the check end to end. Your agent is going to keep reporting done. Give it something to check first.