The merge gate, in four steps
An AI coding agent finishes and reports: change ready, tests pass. The pull request shows a diff and a confident summary. Neither one tells you whether the tests actually ran, whether the diff is the work the agent really did, or whether a step the agent claims was skipped in silence. The fix is not more trust and it is not reading the diff harder. The fix is a record: verify the change against evidence that was saved while the work happened.
- State the checks before the run. What must be true for this change to merge: the named tests pass, only the named files change, the build is clean. Written before the agent starts, not negotiated after it reports.
- Run the agent with its tool calls recorded. Route the work through a recording layer such as the Zambo MCP at https://zambo.dev/mcp, so each call returns its result plus a verifiable receipt at a public link. Zambo is the verifiable work layer for AI: 153 tools behind one endpoint, each call receipted.
- Check the record before the merge, by hand or in CI. Every claimed step should have a receipt, and every receipt should verify. The check is mechanical and takes seconds per receipt.
- Keep the record with the pull request. Paste the receipt links into the PR. A reviewer next month can re-open the same evidence and re-derive the same decision.
How do I verify an AI-generated code change before merging?
Verify it against the recorded work, not the summary. Open the receipt trail for the run and walk it: the files the agent read, the edits it made, the commands it ran, the test output it got back. Each entry is a verifiable receipt under AER-1, published as IETF Internet-Draft draft-zambo-aer1-26: the receipt keeps the exact saved bytes of the result and their sha-256 digest, so anyone can check the saved result was not changed since it was saved. Then apply your pre-written checks to that record. Steps with no receipt are claims, and claims do not merge. To run a change this way, add Zambo to your AI: new users get 20 free calls per day, then they upgrade when the job needs more.
Can CI check whether an AI agent actually ran the tests it claims?
Yes, and this is where the record earns its keep. Attach the receipt ids for the run to the pull request, then give CI one job: for each id, call the verify endpoint and require the verdict.
curl -s https://zambo.dev/api/v2/receipt/RECEIPT_ID/verify
The endpoint returns an overall verdict of verified when the saved record checks out, with the individual checks listed. Fail the CI job when any receipt fails to verify, and fail it when the agent's summary claims a test run that has no receipt in the trail. That second rule is the one that changes behavior: an agent whose claims are gated by a record stops making claims the record cannot carry. What CI cannot do is check work that was never recorded, which is why the recording layer goes in before the work starts, not after the PR opens.
What is proof of work for AI-generated pull requests?
It is the recorded trail behind the change, kept in a form a stranger can check. For each tool call the agent made: the call, the saved result, and a verifiable receipt binding the two. The format is AER-1, and it ships with a public conformance corpus, 126 vectors and 129 checks, kit v1.5.7, archived on Zenodo under DOI 10.5281/zenodo.23677115, so the receipt format itself is tested in the open and any verifier can be checked against the same vectors. A reviewer with the trail can answer the questions a summary cannot: did the tests run, what did they output, which files did the agent actually touch, in what order. The receipt proves the saved result was not changed. Whether the change deserves to merge stays a human call, made on evidence.
How do I gate a release on AI agent verification?
Turn the release checklist into recorded steps and make the gate mechanical. The test suite, the build, the migration dry run, the smoke check: each one runs through the recording layer and leaves a verifiable receipt. The release proceeds when every step has a receipt and every receipt verifies; anything else holds the release. There is no meeting about it and no screenshot to argue with, because the gate reads the same record anyone else can open. Keep the checklist, the receipt links, and the release version together in the release notes, so the state of the gate on release day can be re-checked at any later date.
Should AI-generated code require a verification receipt before deploy?
In proportion to the cost of being wrong. A receipt requirement is cheap: recording happens during the run, and verification is one automated pass in CI. For production deploys, payments, data migrations, and anything hard to roll back, that small cost buys the end of the unverifiable deploy claim. For a prototype nobody will keep, record the calls and skip the hard gate. The honest limit cuts the other way too: a receipt proves the saved result was not changed since it was saved. It does not prove the code is correct, well designed, or safe. Teams still need review and tests. What the receipt removes is the argument about what actually ran.
How do teams prove an AI agent followed the deployment checklist?
By making the checklist out of recorded work instead of recollections. Each checklist item is a step the agent executes through the recording layer, and completion means a verifiable receipt exists with the saved output. At sign-off, the team walks the trail: this item ran, here is what came back, here is the time. An item without a receipt reads as open, not as done, no matter what the run summary says. That single convention, done means recorded, is what turns a deployment checklist from a ritual into evidence. Zambo handovers carry exactly this shape: steps, saved results, and a state a second person can check. See receipting a CI run, step by step for the build-side version of the same pattern.
Try the check yourself on a real recorded call
This recorded call was run live through https://zambo.dev/mcp: a live_price call whose saved result, digest, and receipt are public. Open the run record, then check it at zambo.dev/verify/. That two minute exercise is the whole merge gate in miniature: a claim, a record, and a check anyone can repeat. When a full day of agent work is the job, the paid rungs are plain: a $0.99 Day Pass for 24 hours; the Zambo Pass at $29 for 30 days, one payment, or $290 for 365 days; and $19 for 30 days, one payment for $ZAMBO holders.
Honest limits: what a receipt does not do
Read this before you rely on any of it. A verifiable receipt proves the saved result was not changed since it was saved. It never proves the code was good, the tests were the right tests, or the deploy was wise. A recorded trail only covers work that ran through the recording layer, so route the run through it before the work starts. And a gate is only as strong as its checklist: checks can only test what they name.
Questions, answered
How do I verify an AI-generated code change before merging?
Verify the change against the recorded work, not the agent's summary. Before the run, state the task and the checks the change must pass. Run the agent with its tool calls recorded, so every file read, edit, and test run leaves a verifiable receipt. Before merging, open the receipts: confirm the tests the agent claims to have run appear as recorded calls with saved results, confirm the saved diff matches the files the change touches, and run each receipt through the verifier. Merge on the record. If a claimed step has no receipt, it did not happen as far as the review can tell.
Can CI check whether an AI agent actually ran the tests it claims?
Yes, if the test runs were recorded when they happened. A CI job can take each receipt id attached to the pull request and call the verify endpoint, for example GET https://zambo.dev/api/v2/receipt/{id}/verify, which returns an overall verdict of verified when the saved record checks out. Fail the job when any receipt does not verify, and fail it when a claimed test run has no receipt at all. CI cannot check a run that was never recorded, so the recording has to happen during the agent's work, not after it.
What is proof of work for AI-generated pull requests?
Proof of work for an AI-generated pull request is the recorded trail behind the change: for each tool call the agent made, a verifiable receipt that keeps the exact saved bytes of the result and their sha-256 digest, at a public link anyone can open. The reviewer checks the trail the way they would check any evidence: the commands that ran, the outputs that came back, the tests that passed, each one checkable after the fact. It proves the saved results were not changed since they were saved. It does not prove the code is good. That judgment stays with the reviewer, now working from evidence instead of a summary.
How do I gate a release on AI agent verification?
Write the release checklist as steps that each leave a record: the test suite run, the build, the migration check, the smoke test. Run the release work through a recording layer so each step produces a verifiable receipt. The gate is mechanical: the release proceeds only when every checklist step has a receipt and every receipt verifies. Any step without a verifying receipt holds the release. Keep the checklist and the receipts with the release notes so the gate can be re-checked later by anyone.
Should AI-generated code require a verification receipt before deploy?
For code that ships to production, yes, in proportion to the risk. The receipt requirement costs little: the agent's calls are recorded as they run, and checking them is one automated pass. What it buys is the end of the unverifiable claim: no more 'tests pass' that nobody can re-check, no more deploy steps asserted after the fact. For throwaway prototypes the full gate is overhead and a lighter version, record the calls and spot check, is enough. The rule that scales is simple: the harder a change is to undo, the stronger the record it should carry.
How do teams prove an AI agent followed the deployment checklist?
They keep the checklist as recorded steps instead of as a form someone fills in afterward. Each checklist item is executed as work the agent does through a recording layer, so the item's completion is a verifiable receipt with the saved result, not a checkbox. At review time the team opens the trail: item by item, the receipt shows what ran, what came back, and when. An item with no receipt is an item that was not proven, and it stays visibly open until the work is actually done and recorded.