A pattern keeps showing up in the agent-verification literature, and it's worth naming explicitly.
Most of the recent work — VeriGuard, the Open Agent Passport's pre-execution authorization model, the ACM Queue piece "Guardians of the Agents", AgentVerify — converges on the same architectural insight: a single verification stage is not enough.
You can verify what an agent plans to do before it acts. You can verify what an agent actually produced after it acts. These are different problems, with different inputs, different failure modes, and different settlement consequences. Treating them as one collapses the safety story.
This post is about why those two layers are structurally distinct, why both are necessary, and how the verification-output schema we've been developing in the ERC-8210 thread ends up shaped by exactly this distinction.
The agent-safety literature keeps using "verification" as a single word, but it conceals two operations.
Plan-layer verification asks: given this proposed action, is it allowed under the policy? The input is a candidate action — a tool call, a transaction, a delegation, a downstream sub-agent invocation. The verification happens before execution. The output is a binary or graded gate: allow, deny, or escalate. The artifact, if any, is an authorization record.
Output-layer verification asks: given this completed action and its observable result, did the agent actually do what it claimed? The input is the execution trace and its result — the API response, the tool output, the on-chain effect, the produced artifact. The verification happens after execution. The output is an attestation about correctness, quality, or compliance. The artifact is a verification record that can be referenced later for settlement, audit, or dispute.
These two operations have different epistemic shapes:
| Plan Layer | Output Layer | |
|---|---|---|
| Input | A proposed action and its declared parameters | An executed action and its observable result |
| Decision moment | Before execution | After execution |
| Decision shape | Permit / deny / escalate | Verdict + structured objections |
| Failure mode it catches | Policy violations, capability overreach, prompt-injection-driven action | Quality regressions, hallucinated success, partial failure, attribution disputes |
| Failure mode it cannot catch | Quality of the result (the action wasn't even taken yet) | Unauthorized actions (already happened) |
| Latency budget | Tens of milliseconds — sits in the action path | Seconds to minutes — runs alongside or after the action |
| Settlement role | Gates whether the action proceeds | Becomes evidence for claims, disputes, payouts |
Notice the last two rows. The plan layer and the output layer cannot substitute for each other. A perfect output verifier cannot prevent an unauthorized fund transfer that already cleared. A perfect plan verifier cannot tell you whether the API call you authorized actually returned the right data.
This is the same observation Uchibeke makes in the Open Agent Passport paper: pre-action authorization, sandboxed execution, model alignment, and post-hoc evaluation are complementary layers in a stack — none of them subsumes the others. Meijer's "Guardians of the Agents" in ACM Queue takes a complementary angle: agents should be required to generate formal proofs demonstrating the safety of planned actions before being authorized to execute them — static verification as a pre-condition for action. Different vocabulary, same architectural insight: verification is not a stage. It's a stack.
The Ethereum Improvement Proposals around autonomous agents have been quietly encoding the same distinction.
ERC-8004 (Trustless Agents) sets up three registries: Identity, Reputation, and Validation. The Validation Registry is where output-layer verification lands — it's the place where validators record post-hoc attestations about whether an agent's claimed work was actually delivered. ERC-8004 is deliberately permissionless about what kind of validator: stake-backed re-execution, zkML proofs, TEE attestations, multi-model output checks. The registry doesn't take a position on the method of output verification; it standardizes the coordinate system in which such verifications can be referenced.
ERC-8210 (Agent Assurance Protocol) sits one layer up. It builds on ERC-8183 (job execution and escrow) and answers a different question: what happens when an agent commits to a job, posts collateral, and something goes wrong? AAP defines the claim lifecycle — commitToJob, fileClaim, resolveClaim, payout — and leaves the evidence and reason parameters as opaque bytes, on purpose. The standard is intentionally agnostic about what the verification looks like. It only specifies where verification has to plug in.
That gap — between "settlement layer needs evidence" and "evidence needs a schema" — is exactly where the Verification Output Schema (Informational ERC, requires: 8210) emerged, in conversation with the AAP authors. The shape of the schema makes the plan/output distinction explicit:
verdict field with three values: APPROVE, DENY, UNCERTAIN. The DENY value (originally drafted as BLOCK) was deliberately renamed in the thread to reflect that the schema is for claim adjudication, not pre-execution gating. That's a plan-layer-vs-output-layer correction encoded directly into the wire format.subject block with claimId to bind the verification to a specific AAP Claim — preventing replay of an APPROVE verdict against a different transaction.upstream field (added during the thread) that lets a verification record reference upstream Jobs in a multi-hop pipeline, so a Resolver adjudicating Agent D in an A→B→C→D chain can trace the causal provenance without AAP's core contract having to model dependency graphs.validUntil timestamp, so freshness is enforced by the verifier, not inferred by the consumer.assessors[] as a first-class array — supporting LLM-based, rule-based, human, and oracle assessors in the same record. This is the deliberate choice that makes the schema assessor-agnostic: a multi-model consensus verifier and a deterministic static-analysis tool produce the same shape.These design choices are not accidents. They follow from the same observation this post started with: the plan layer and the output layer are different operations with different settlement roles, and the schema has to know which one it's serving.
A pattern is emerging in production agent systems — visible in the Snowflake 2026 predictions, the NexGen agentic AI roadmap, and the Building Production AI Agents field-notes — and it's worth stating bluntly:
Single-stage verification is one of the most common architectural gaps in agent pilots that stall before production.
The failure modes follow the layer split exactly:
upstream field discussion from the ERC-8210 thread.Each of these has a known fix in the academic and standards literature. None of them are fixed by adding "more guardrails" to the model itself. They are fixed by putting verification in two different places in the stack and giving each place the right schema, the right cryptographic binding, and the right settlement role.
The shorthand we've been using internally:
Verify the plan before the agent acts. Verify the output after the agent acted. Compose them into a stack.
In standards terms:
┌────────────────────────────┐
│ Settlement / Disputes │
│ (ERC-8210 / AAP) │
└────────────┬───────────────┘
│
┌────────────┴───────────────┐
│ Verification Schema │
│ (Informational ERC, │
│ requires: 8210) │
└─────┬──────────────┬───────┘
│ │
┌────────────┴───┐ ┌───────┴────────────┐
│ Plan Layer │ │ Output Layer │
│ (pre-action, │ │ (post-action, │
│ authorization)│ │ attestation) │
└────────┬───────┘ └─────────┬──────────┘
│ │
└──────────┬─────────┘
│
┌────────────┴───────────────┐
│ Identity / Reputation / │
│ Validation Registries │
│ (ERC-8004) │
└────────────────────────────┘ERC-8004 is the substrate: identity, reputation, validation hooks. ERC-8210 is the settlement layer: claims, collateral, payout. The Verification Output Schema is the content layer that lets the plan-layer gate and the output-layer attestation produce records the settlement layer can actually adjudicate.
What's missing from the open-standards work today — and what we think is the most interesting standards problem in this space for the next 12 months — is the equivalent schema for plan-layer authorization records. The Open Agent Passport draft is the most concrete proposal we've seen so far (OAP, March 2026). It defines a Delegation Receipt with cryptographically signed scope, capability bounds, model state attestation, and an append-only log entry. The shape is right; the open question is whether the plan-layer record format converges with the output-layer schema, or whether the two should remain deliberately distinct.
Our current view, after the ERC-8210 thread: distinct schemas, shared substrate. The plan layer's natural format is a signed authorization receipt with capability scoping. The output layer's natural format is a multi-assessor verdict with structured objections. They share subject, claimId-style binding, validUntil semantics, and the upstream provenance field. They diverge in the action-shaped fields: a plan-layer record needs to describe what is about to happen; an output-layer record needs to describe what already happened and how it was assessed.
Two schemas, one stack.
ThoughtProof is a verification-engineering team. We started by building output-layer multi-model verification because that's where the on-chain settlement layer (ERC-8210/AAP) was already defining a place for evidence to plug in, and because we made the case publicly that ERC-8004's Validation Registry needs an actual verification engine sitting behind it, not just a registry slot.
Plan-layer verification is the natural next problem in the same architecture. The relationship between the two — same substrate, distinct schemas, composed into a stack — is the framing we're pushing in the standards work and in our reference implementations.
If you're building production agents and the failure modes above sound familiar, the layer that matters most for you depends on where the failure shows up. If your agents are taking unauthorized actions, you have a plan-layer gap. If your agents are claiming success with bad outputs, you have an output-layer gap. Most production teams have both, in different proportions.
Discussion of the standards is happening in the open:
ERC-8004 spec · ERC-8183 thread · ERC-8210 thread
Adjacent reading:
VeriGuard (verified code generation for LLM agent safety) · Open Agent Passport (pre-action authorization) · Guardians of the Agents (ACM Queue) · AgentVerify (compositional formal verification)
ThoughtProof — Verification engineering for autonomous agents.
→ Verify · GitHub · Specification
ERC-8004 Agent #37477 · Building the Verification Output Schema on ERC-8210