The plumbing works. The inspection doesn't exist.

In the span of a few months, the agent payment stack went from theoretical to production-grade. x402 turned HTTP 402 into a payment primitive — Coinbase incubated it, Stripe integrated it. Coinbase shipped Agentic Wallets with TEE-backed custody and spend controls. Google announced A2A payments with 60+ partner firms. Lightning Labs open-sourced L402 agent tools for Bitcoin-native payments.

This is real infrastructure. Billions in engineering effort. And all of it solves the same problem: how does money move between machines?

None of it solves the next problem: should the money have moved?

The current model is pay-and-pray

A typical agent transaction today: Agent A needs 50 earnings calls summarized. It finds Agent B on a marketplace, agrees on $25 USDC, and pays via x402. Agent B returns a JSON blob. Agent A parses it, uses it, and moves on.

Except three of the companies in Agent B's output don't exist. The revenue figures are hallucinated. Two summaries are duplicates of each other with slightly different wording. Agent A has no idea. The money is gone. There's no recourse mechanism because there was no verification step.

This isn't a hypothetical. It's the default. Every agent payment system in production today works this way. Payment releases on delivery, not on verified completion.

Why guardrails aren't verification

Coinbase's Agentic Wallets are a serious piece of engineering. Spend caps, session limits, policy controls, all running inside a TEE. They answer an important question: can this agent spend this much on this type of transaction?

But that's authorization, not verification. Knowing that Agent B is allowed to receive $25 tells you nothing about whether Agent B's output was worth $25. Spend limits prevent overspending. They don't prevent paying for garbage.

KYA protocols like ERC-8004 registered tens of thousands of agents in their first weeks. Good — you know who the agent is. You still don't know if its output was any good.

The stack right now:

Layer Who's building it What it answers
Identity KYA, ERC-8004, Sumsub Who is this agent?
Communication A2A (Google), MCP, ACP How do agents talk?
Payment x402 (Coinbase), A2A (Google) How does money move?
Custody Coinbase Agentic Wallets Who controls the funds?
Settlement USDC on Solana & Base, BTC on Lightning Where does it settle?
Verification ___ Was the work actually done?

Every layer has serious teams building serious infrastructure. Except verification.

What verification looks like in practice

A structured data extraction needs different validation than a creative writing task. The right approach is layered.

Schema validation is the fast, cheap first pass. Does the output have the right structure? Are required fields present? Is the data the right type? This catches the obvious garbage in single-digit milliseconds at near-zero cost. Most bad outputs fail here.

Validator agents handle the subjective part. A separate AI model — with its own prompt and scoring criteria — evaluates the quality of the output. Did the summary actually capture the key points? Is the translation accurate? Does the code review identify real issues? This runs in 2-10 seconds and costs a fraction of the original job.

Composite verification chains them together. Run the schema check first. If it passes, run the validator. Fail fast on the cheap stuff. Only spend money on expensive checks for outputs that pass the basics.

// create a payment with composite verification
const payment = await client.payments.create({
  sender_wallet_id: wallet.id,
  amount: "25.00",
  memo: "Summarize 50 earnings transcripts",
  verification_config: {
    type: "composite",
    operator: "sequential",
    verifiers: [
      {
        type: "schema",
        schema: {
          type: "object",
          required: ["summaries", "metadata"],
          properties: {
            summaries: { type: "array", minItems: 50 }
          }
        }
      },
      {
        type: "validator_agent",
        prompt: "Verify each summary is factually grounded and cites the original transcript. Score 0-1.",
        threshold: 0.8
      }
    ]
  }
});

Funds lock in escrow when the job is created. The worker agent claims the job, does the work, and submits output. Verification runs automatically. Pass releases funds to the worker. Fail refunds the buyer. No human in the loop.

Escrow makes verification enforceable

Verification without escrow is just monitoring. You can check the work, but the money already moved. You're left writing a strongly worded log entry.

Escrow is what turns a quality signal into a financial gate. Funds lock before work begins. Verification runs before funds move. Pass releases. Fail refunds. The result is a new payment primitive: conditional payment. Not pay-for-access. Not pay-on-delivery. Pay on verified completion.

This is what we built. A REST API for programmable AI agent payment verification. Escrow, verify, and release — on any settlement rail. USDC on Solana today. The API is live. Try it →

The cost of not verifying

At small scale, unverified payments are a nuisance. You overpay for a few bad outputs. An agent wastes $5 here and there. Nobody notices.

An enterprise running 10,000 agent transactions per day with a 5% failure rate is losing $12,500 daily on work that doesn't meet spec. That's $4.5 million a year. And 5% is generous — early benchmarks put quality failures at 15-30% for complex outputs.

The first time a Fortune 500 company audits their agent spending and finds seven figures in payments for hallucinated garbage, verification becomes a board-level priority. That moment is closer than most people think.

Why the rails won't build this

Payment rail providers won't build verification for the same reason Visa doesn't tell you whether your SaaS subscription is worth the money. It's not their layer.

Payment rails optimize for moving money reliably, quickly, and cheaply. Verification is application logic — domain-specific, opinionated, endlessly configurable. The schema for validating a legal contract summary is completely different from the schema for a code review or a data extraction. A payments company that tries to be a verification company does both badly.

What the ecosystem needs is a verification layer that sits between the work and the settlement. Rail-agnostic. Define your rules, escrow the funds, verify the output, settle on whatever protocol you're already using.

What happens next

Stripe shipping machine payments was a starting gun, not a finish line. The payment infrastructure is built. The next question — the one nobody's answering yet — is what happens between "work submitted" and "funds released."

The answer is verification. Programmatic, composable, enforceable. The companies and protocols that build this layer will own the trust infrastructure of the agent economy. And trust is where the value accrues.

The rails are live. Time to inspect the cargo.