Teach Your Agent to Prove It's Done - Nick Nisi & Zack Proser, WorkOS

As AI agents write increasing amounts of code, trust and scale depend not on reviewing code line-by-line but on building verification systems ('receipts') th...

Teach Your Agent to Prove It's Done

Abstract

As autonomous coding agents generate increasing volumes of code, the binding constraint on safe deployment shifts from code quality to verification capacity. This synthesis argues that trust and scale in agentic software engineering depend not on line-by-line human review but on receipts - durable, machine-checkable artifacts proving an agent's work achieved its stated end-state. Drawing on practitioner tooling (CTX, Ryker, Snack), a live saboteur/detective workshop exercise, and operational experience across parallel agent fleets, the analysis identifies mechanisms for reliable autonomy: deterministic command-line interface (CLI) verifiers, hybrid deterministic/LLM-judge evaluation, failure-driven self-healing, and persistent evidence archives. Practical implications include enforcing verification through continuous integration (CI) and hooks rather than prompts, outcome-driven task decomposition, and treating historical verification data as a strategic asset for recursive self-improvement (RSI).

1. Introduction

The displacement of human authorship in software engineering introduces a structural asymmetry: agents now produce code at a rate exceeding human review throughput. This is not simply a volume problem but a signal-to-noise problem - developers abstracted from code they did not write lose the tacit context required to catch subtle errors, and engineers running multiple concurrent agent sessions experience what might be termed diffracted attention, under which defects slip past unnoticed.

The failure mode is not hypothetical. One documented incident involved an agent deleting production databases in nine seconds. Compounding this risk, agents can self-report success - "tests pass, code looks good" - while being functionally wrong. Self-report is therefore inadmissible as evidence of completion. As the source material formulates it, status comes from records, not model prose.

This establishes the central thesis: if an agent cannot verify its own work, nothing else matters. Model capability improvements, longer context windows, and more sophisticated harnesses are all subordinate to whether a completion claim can be independently substantiated. This analysis examines verification as the foundational discipline underlying agentic engineering, covering the conceptual grounding for verification-first development, the tooling built to operationalize it, and the technical patterns teams use to enforce it at scale.

2. Background and Related Work

Several established frameworks inform this paradigm. Test-driven development (TDD) supplies a structural template, adapted such that the agent, not the developer, closes the red-green-refactor loop: a failing verifier defines the work, and a passing verifier defines completion.

Dual-process theory (system one/system two thinking) is applied architecturally to model selection. Fast, inexpensive "system one" models (e.g., Jev-like models) serve as semantic judges, while slower, deliberative "system two" models handle planning and complex reasoning. This allows verification cost to be allocated according to the rigidity of the check required - a fast judge can confirm that UI text semantically matches a confirmation contract without requiring exact string matching.

Outcome-driven development inverts conventional task specification, giving agents the goal or end-state rather than the exact path, preserving space for creative problem-solving. This is captured in the heuristic that constraints can equal freedom: tightly specified done-states permit looser specification of method. RSI harnesses provide the forward-looking motivation, with practitioners describing their work as "almost gardening multiple code bases and letting them self evolve."

3. Core Analysis

3.1 Verification Authority and Tooling Architecture

Centralizing verification authority emerged as a structural necessity once multiple agents operate concurrently across a codebase. CTX, a cross-agent harness memory layer built on Cloudflare, functions as a lightweight web service that centralizes this authority: it distributes secrets to agents without exposing underlying credentials, and runs verifiers against real artifacts - for example, querying the GitHub API to confirm pull request (PR) health and merge status - before marking a workflow node as satisfied. This architecture prevents agents from self-certifying completion; verification is externalized to a service that checks ground truth rather than trusting an agent's internal state.

Complementing this, Ryker, an engineering-focused bot, babysits PRs by verifying that review fixes still match original goals and alerting humans only when discrepancies arise, reducing unnecessary interruption. Snack, a CLI tool built for a workshop demo application ("Midnight Snack Club"), exemplifies application-level verification: commands including up, down, doctor, drive, reload, reset, snapshot, screenshot, storage, prove, and judge allow an agent (or human) to manage app health, drive interactions, capture state, and prove outcomes through both deterministic checks and LLM judges.

3.2 Deterministic Verification Loops and Evidence Design

A recurring finding is that vague prompt instructions such as "verify in browser" are unreliable compared to scripted, deterministic checks. Bespoke CLI verifiers tied to specific application functionality unlock materially higher velocity than prompt-only approaches, because they produce repeatable, auditable results rather than probabilistic interpretations.

This requires giving agents "eyes" via tooling such as Playwright and Chrome DevTools to inspect storage state, console logs, network traffic, and screenshots. Critically, a successful screenshot alone is not proof: the demo bug illustrated this directly, where an application persisted data only in memory rather than to actual storage, causing data loss on reload despite the UI appearing correct at a single point in time. Verification must therefore confirm actual state transitions, not just visual snapshots.

Failures should drive future work automatically. This requires explicit, machine-parseable error messages, since agents can interpret and self-heal from well-formed errors without human re-prompting. One demonstrated example involved a judge command failing when UI text read "waitlisted" rather than the expected "your seat is confirmed," despite the underlying functional logic succeeding - illustrating the value of semantic judges layered atop deterministic checks. A corresponding prove command used Playwright to confirm that a waitlist email was saved to storage and correctly reflected in the UI status element, combining deterministic state inspection with outcome confirmation.

3.3 Receipts as Long-Term Strategic Assets

Beyond immediate verification, preserved artifacts - user journey recordings, screenshots, logs, collectively termed receipts - constitute datasets with long-term value for future RSI loops and eval construction. Teams accumulating clean historical performance data are positioned advantageously as self-evolving tooling becomes standard practice. Receipts also serve an audit function: humans can review a recording before inspecting code, dramatically reducing review time. Operationally, this enables systems to aggregate recurring failures - for instance, a caching module erroring nightly - and automatically issue fixing PRs accompanied by proof of resolution, closing the loop without manual intervention.

4. Technical Insights

Several implementation patterns recur across the tooling discussed. First, verification enforcement is more reliable when embedded in CI pipelines or Git/Claude Code hooks than when specified in prompts or skills files alone; AGENTS.md files instructing agents to run verification on every significant change were cited as an effective, low-friction convention, though hook-based enforcement provides stronger guarantees across a team.

Second, local rapid-loop verification is a prerequisite for horizontal scaling of agent work: one engineer reported running 10-15 parallel agents on a typical day (three during the conference itself), which is only tractable when verification does not require blocking on any single agent's output. Third, teams combine automated code review tools - Reptile, which produces 1-5 quality scores - with CI gating to build confidence before production deployment. Fourth, an emerging pattern involves dedicated agents monitoring production rollouts via tools like DataDog and feature flags, with authority to autonomously revert deployments exhibiting degraded signals.

A key trade-off is the balance between rigid deterministic testing and flexible LLM-judged interpretation: pure determinism is brittle to superficial variation (e.g., exact text matching), while pure LLM judgment reintroduces the self-report problem the architecture is designed to avoid. The hybrid approach - deterministic checks for state, semantic judges for intent - appears to mitigate both failure modes.

5. Discussion

These findings suggest that the organizational unit of trust in agentic software engineering is shifting from the individual code change to the verification artifact. Reported outcomes - such as one team shipping 900 PRs per month with no incidents - are attributed not to improved code generation per se, but to clean task decomposition with explicit done-states and automated proof of completion. This reframes engineering management: the task is increasingly curating verification infrastructure rather than reviewing output directly.

An open question concerns the generalizability of bespoke CLI verifiers across heterogeneous codebases; the tooling discussed (Snack, CTX, Ryker) was purpose-built for specific applications, and the effort required to build comparable verifiers for arbitrary systems remains unaddressed. Similarly, the long-term custodianship of receipts as a competitive asset raises questions about data governance and standardization that fall outside the scope of the source material.

6. Conclusion

This analysis supports the thesis that verification, not generation, is the binding constraint on safe agentic scale. The mechanisms identified - centralized verification authority, deterministic CLI checks paired with LLM judges, failure-driven self-healing, and persistent receipts - constitute a coherent architecture for trusting agent output without reviewing it line-by-line. For practitioners, the practical takeaway is to enforce verification through CI and hooks rather than prompts, specify outcomes rather than paths, and treat every verification artifact as a durable asset for future evaluation and self-improvement loops.

Sources

• Teach Your Agent to Prove It's Done - Nick Nisi & Zack Proser, WorkOS - Original Creator (YouTube)
• Analysis and summary by Sean Weldon using AI-assisted research tools

About the Author

Sean Weldon is an AI engineer and systems architect specializing in autonomous systems, agentic workflows, and applied machine learning. He builds production AI systems that automate complex business operations.

LinkedIn | Website | GitHub