The short answer
Do not judge the clock. Read the record.
Open the job record and read four things. Count the steps against the shape of the job. Read the per-step times and the gaps between them. Check the inputs on each step against what you actually asked. Read the saved results for detail only the job itself could produce. If all four line up with the ask, the run happened, however fast it felt. If any one is missing or thin, you have found exactly where the run stopped being real, and exactly what to rerun.
The three ordinary causes of a too fast finish
A suspicious finish rarely means a dishonest agent. It means one of three ordinary failures, and each leaves a different fingerprint in the record:
- Steps were skipped. The job needed forty reads and the agent did six, then wrote up the six as if they were the forty. Fingerprint: the step count is short against the job's shape, while the summary's confidence is full size.
- It answered from memory instead of running the tools. The model produced a fluent answer from what it already believed, and the tool calls never happened. Fingerprint: few or no steps at all, and results with no job-specific detail, no live figures, no quotes from the actual sources.
- It ran a smaller job than the one asked. A narrower search, a sample instead of the full set, last year's version of the question. Fingerprint: steps exist and look real, but their inputs describe a smaller job than yours. The inputs are where this one shows.
All three read identically in the summary. They are unmistakable in the record, which is why the record is where the question gets answered.
The four tells, read in order
- Step count against the job's shape. Before opening anything, write down how many steps the job honestly requires: sources to read, files to touch, checks to run. Then count the steps in the record. A short count is the fastest possible finding, and it needs no expertise to read.
- Per-step times. Real calls take real time: a fetch, a search, a computation each leave a duration, and the gaps between steps match thinking and tool latency. A record whose steps all land inside one second, for work that cannot, is a record of a summary being written, not a job being run.
- Inputs against the ask. Read what each step was actually given: the query, the file, the range, the product name. Skipped scope hides here. The steps can be genuine and still be steps of a smaller job.
- Saved results with job-specific detail. Read two or three saved results end to end. Real results carry the texture of the actual sources: exact figures, exact wording, the awkward specifics no memory invents in matching detail. Then recompute each step's verifiable receipt, or run it through zambo.dev/verify, to confirm the saved result is the one the run produced.
The step by step receipt flow lives on how to verify AI work. The output versus record distinction, for a single suspicious call, is on did my AI agent actually run it.
What no record means
If the run left no record at all, the question answers itself in the worst way: there is nothing to verify with. The summary is the only artifact, and the summary is the thing under suspicion. You cannot distinguish a brilliant fast run from an invented one, and neither can anyone you hand the output to. That is not a reason to distrust every fast finish. It is a reason to change the default so the next run arrives with its evidence attached, which is a one time setup, below.
Run the work so the question answers itself
- Route the calls through a record layer. Point your agent at the Zambo MCP endpoint, https://zambo.dev/mcp. It works with the agent you already run: Claude, ChatGPT, Gemini, Cursor, Grok, and other MCP clients. Setup is one step at zambo.dev/add.
- Let the receipts accumulate. Every call through the endpoint leaves a verifiable AER-1 receipt as it runs, including calls that fail or get refused, gathered under the job in order, with the step, its time, its inputs, and its saved result. Zambo is the verifiable work layer for AI: 153 tools behind the one endpoint, 20 free calls per day, then they upgrade, a $0.99 Day Pass for 24 hours, or the Zambo Pass at $29 for 30 days, one payment.
- Check before you act, and hand the record over with the output. When a finish feels too fast, read the four tells. When the output goes to a client or a teammate, send the record with it, closed as one link with HANDOVER, so they can run the same read instead of wondering the same thing you wondered.
The fixed target underneath the check
A checking method is only as good as the format it checks against, which is why the receipts follow an open, published one. AER-1 (draft-zambo-aer1-26) ships with a public conformance corpus of 126 vectors and 129 checks, kit v1.5.7, published at zambo.dev/aer1/corpus.json and archived on Zenodo under DOI 10.5281/zenodo.23677115. Any verifier can run the same vectors and get comparable results, because the inputs and expected outcomes were fixed in advance. The receipt you recompute at home and the receipt a stranger recomputes are the same check, which is what makes the trust transferable instead of personal.
What the check settles, and what it never settles
It settles whether the run happened: which calls were made, when, with what inputs, and what they returned, against a record that holds still. It does not settle whether the agent chose the right calls or read the results fairly. Stated exactly: a verifiable receipt proves the saved result was not changed since it was saved, not that the result was right. Speed stops being the question. The record becomes the answer.
Questions, answered
My AI agent finished suspiciously fast, how do I verify it really ran?
Open the run's record and read four things. Count the steps against the shape of the job you asked for. Read the per-step times: real calls take real time and leave gaps that match the work. Check the inputs on each step against your ask. Read the saved results for detail only the job itself could produce. A run that really happened has steps, times, inputs, and results that line up with the ask. A run that was summarized into existence has a gap where one of those should be.
How fast is too fast for an AI agent task?
There is no universal number, because jobs differ. The test is relative: compare the record to the job's shape. A task that requires reading forty pages cannot honestly finish in the time two page reads take, and its record will show two steps, not forty. A short lookup can honestly finish in seconds, and its record shows the lookup. Judge the finish against the steps the job required, never against a stopwatch alone.
Can an agent fake the record of a fast run?
Not for calls that never went through the record layer. Receipts are issued by the endpoint as each call happens, and each one binds the exact saved bytes of that call's result to its SHA-256 digest. An agent writing a summary afterward cannot mint steps for calls the endpoint never saw. The honest limit runs the other way: work that ran outside a record layer leaves nothing to check, and that absence is itself the finding.
What should I do when the record shows steps are missing?
Rerun the missing slice, not the whole job. The record names the gap precisely: which sources were never read, which checks never ran, which inputs never matched the ask. Send the job back with the gap named, or rerun just that slice through the record layer. Then change the default: route the work through an endpoint that leaves a receipt for every call, so the next suspicious finish answers itself from the record.
What does a verifiable receipt prove about a run?
It proves the saved result was not changed since it was saved. A receipt carries the exact saved bytes of a call and their SHA-256 digest, so anyone can recompute the digest and confirm the record they are reading is the record the run produced. A chain of receipts under one job proves which calls happened and what they returned. It does not prove the agent chose well or reasoned fairly. Those judgments stay with the person checking.