A small protocol for keeping AI coding assistants honest: one AI session does the work and declares claims, a separate session (no shared context) verifies those claims against the artifact, a human approves termination. Neither session can do the other's job.
Shared as internal practice. Works for our use. Not claimed to work for everyone.
A few weeks ago a coding assistant deleted a work folder during a migration. Tier-1 incident. We rebuilt from checkpoints, but it made us stop trusting a single session's "I'm done" report.
Writing rules into CLAUDE.md or equivalent didn't fix it — the same session that wrote the rules also decides (with mixed success) whether it's following them. What did work was a second AI session, opened fresh, with no access to the first session's reasoning, checking the first's declared claims against the actual artifact. The second session cannot fix what it finds; it files a verdict for a human to adjudicate.
We wrote it as a protocol — a short document of invariants and roles — rather than a script, because the Verifier session can be a different tool than the Generator. If your team uses more than one AI assistant (say Kiro for coding and Claude Code for review), a protocol-shaped interface lets them interoperate through a folder and a simple JSON schema, without either vendor owning the channel.
The protocol defines three roles:
- Generator produces work and declares claims about it.
- Verifier checks those claims against the artifact, without shared context.
- Supervisor (human) approves termination and adjudicates disputes.
And three deployment modes:
- Mode 1 — local folder on your laptop, convention-enforced. Two AI sessions, one channel folder, a human. No install, no accounts.
- Mode 2 — Git repo, SSH-signed commits, team-scale. Verification history lives in version control and PR workflow.
- Mode 3 — cross-account IAM, audit logging, enterprise-scale. Infrastructure-enforced role separation.
A Mode 1 verification run produces three artifacts: a package (the Generator's claims), a verification (the Verifier's findings and verdict), and an append-only handoff log.
Start with QUICKSTART — 5 minutes end-to-end, no install. Full spec in PROTOCOL-agentic-verification-v0.3.0.md. Methodology (why it works) in METHODOLOGY-agentic-verification-v1.2.md.
- Not a product.
- Not a service.
- Not a replacement for human code review.
- Not a proven solution for every workflow. We've run it in-house across a checkpoint migration, a measurement library build, and the protocol document itself — small sample size, Mode 1 primarily, one Mode 3 instance.
- Not a tool you install. It's a document your AI assistants read and interpret. The "implementation" is the agents' ability to reason about constraints plus a shared folder.
Anthropic's engineering team published "Harness design for long-running application development" in March 2026 describing a similar generator/evaluator separation, file-based handoff between agents, and the same "agents rate their own work too generously" observation that motivates AVP. The architectural direction is convergent.
The one thing AVP adds is interchangeability: the Verifier session can be a different tool than the Generator. An internal harness owned by one vendor can be generator/evaluator without this constraint; a protocol intended for cross-vendor work needs it. If your team mixes Kiro, Claude Code, Codex, Cursor, or any combination, AVP is the attempt to make the verification boundary interoperable rather than vendor-locked.
- Mode 1 has been exercised across ~8 verification rounds on our own work.
- Mode 3 has been run once, as part of the checkpoint migration that motivated this work.
- Mode 2 is specified but not yet exercised in a team setting.
- Breaking changes are possible before v1.0.
- Draft status: v0.3.0. Calibration record inside the protocol document names unresolved issues honestly.
Issues and pull requests welcome. Would be curious how the invariants line up or conflict with how other teams keep AI work honest. Open an issue, drop a comment on an existing one, or start a discussion in the issues tab.
Author: Vinson (@vsnonto), ontojoseki License: CC-BY-4.0 for documents. Code examples (when added) will be MIT. Version: v0.3.0 Status: Draft — published 2026-05-12