Agent Self-Verification Protocol — Why "Deployed" Isn't "Working" Until the Agent Walks the User's Path
The agent doesn't trust its own "done." It walks the user's path and reports what the user would see.
What was getting in the way.
Every tool in a modern deploy pipeline is happy to tell the agent the work is finished. The code-review tool reports a merge. The build pipeline reports green. The hosting platform reports a deploy. The agent's own session reports an edit landed. Each report is accurate about its narrow surface and silent about the thing that actually matters — whether a human visiting the live site at the normal URL sees the change the request asked for. A chain of green lights is not a verification; it is a chain of green lights. The failures that survive in that gap are the expensive ones: edits that persisted in a scratch working tree but never committed to the branch that deploys; deploys that completed on a stale commit because the fix landed between CI and release; cache layers serving the pre-fix version on the exact URL the user types; a conversion tag that typechecked and rendered but silently stopped firing on the form submit. Each of these looked fine on every intermediate report. Each of them reached a human only because the agent "verified" by reading the reports instead of walking the path.
Context
Universal — the pattern applies to any AI agent that ships work to a surface a human will see, in any stack.
How the work runs.
- 01
Define the check before writing the fix
Before an edit is drafted, the agent writes down what will prove the edit works on the live site: a distinctive copy phrase that can only exist if the new text shipped, a route that must return 200, a slug that must appear exactly once in the gallery index, a served-asset byte hash that must match the source file. The checks become part of the brief, not an afterthought bolted on at the end. A check invented after the deploy is a check that explains the result it already has.
- 02
Trust tool reports only as inputs, never as evidence
"The agent reports success," "the pipeline reports green," "the dashboard shows deployed" are intake signals the real verification uses to decide when to run — not the verification itself. The agent treats every intermediate green as a reason to start checking, not as a reason to stop.
- 03
Walk the user's path at the public URL
The agent fetches the final URL a human would type — not a cache-busted debug variant, not a staging preview, not an internal admin view. For a page edit, that means the deployed route; for a content asset, the hashed CDN URL the deployed page actually references; for a form, a scripted submit through the real form on the real page. The surface being verified is the surface a human will see.
- 04
Grep for the phrase only the fix could produce
The served HTML is scanned for the exact distinctive string the fix would have introduced: the new headline, the new price, the new slug, the new asset hash. A soft check like "page loaded" proves the server is up; a hard check for a phrase that can only exist post-fix proves the fix is on the page. Phrase hits are counted — zero means the fix didn't ship; a wrong count means something else is contaminating the result.
- 05
Prove the bytes, not the pointer
For any shipped asset — image, PDF, script — the agent fetches the served bytes and hashes them, then compares to the source file the fix produced. A matching hash proves the user is seeing what the agent built; a mismatch means a cache layer, a stale pointer, or a scratch-tree edit that never persisted is sitting between source and user.
- 06
Check what shouldn't be there as hard as what should
Robots meta, 404s on required routes, accidental leakage of client identifiers, broken anchors, console errors, raised alerts the fix should have cleared. The agent runs a short standing checklist of absences on every verification — the gap between "the thing we wanted" and "nothing we didn't want" is where silent regressions live.
- 07
Report every failed check as a deviation, not a to-do
If any check fails, the agent flags the deviation in the completion message to the human — plainly, with the check that failed, the evidence, and the next action — instead of writing "deployed, will follow up on the X check." A failed verification cancels the "done"; it does not become a footnote.
- 08
The checklist evolves with every incident
Each time a check misses a class of failure, the standing checklist gets a new line and a lesson entry explaining what the previous checklist couldn't catch. The verification protocol is the single thing that compounds across engagements, so the same silent failure can't recur.
Evidence from the workflow.
Each system has a role.
Action (walks the user's path at the public URL)
Headless browser
Intake (reports green as the signal to start checking, never as the verification)
Deploy pipeline / hosting
Record of truth (the standing checklist that evolves with every incident)
Agent playbook
Signal (where the pass or deviation is reported with evidence)
Team chat
Why this is Operator.
Owns a workflow end to end, running the process inside the authority you set.
- 01
The agent never claims "done" on the strength of a tool report. The only evidence that counts is bytes served to the public URL and the agent's own grep of that response. A deviation is reported plainly in the same message, not softened and not deferred. The standing checklist is the agent's own; a human adds a line only when a new class of failure demands one.
Impact / Outcomes
A failed deploy that reported green on every intermediate step gets caught by the live-path check — the agent reports the deviation in the same turn, not after a human notices.
Scratch-tree edits that didn't land in the deploying branch show up as a zero-count distinctive-phrase grep on live, within seconds of the deploy — before the "it's live" message reaches a human.
The verification is the single checklist that compounds: every incident adds one line that a future deploy can't skip.
"It's live" in a status message carries weight because the agent only sends it after walking the path a human would walk.
Find where a workflow like this fits.
Start with the systems, work, constraints, and authority already present in your operation.