AgentVerify

Google built how agents talk (A2A). Stripe built how agents pay (ACP). Nobody built how agents trust each other. AgentVerify is the trust verification and dispute resolution layer for agent commerce

Comment

AgentVerify

The trust and adjudication control plane for agent commerce.

The One-Liner

Google built how agents talk (A2A). Stripe built how agents pay (ACP). Nobody built how agents trust each other. AgentVerify is the trust verification and dispute resolution layer for agent commerce — verifying authorization, assessing deliverables, and arbitrating disputes so payment rails know when to release funds. Payment-rail agnostic. Protocol-native. The piece the agent economy is missing.

The Problem

AI agents are beginning to transact on behalf of humans and businesses. Visa completed hundreds of controlled agent-initiated transactions in 2025 and projects millions by the 2026 holiday season (Visa Intelligent Commerce announcement, Dec 2025). Gartner predicts 90% of B2B purchasing will be AI-intermediated by 2028, flowing through an estimated $15 trillion in agent-mediated exchanges (Gartner, "Predicts 2025: Autonomous Agents Will Redefine Enterprise Operations"). McKinsey projects $3–5 trillion in global agentic commerce by 2030 (McKinsey Global Institute, 2025). This isn't speculative — Danfoss has automated 80% of its purchase order decisions, saving $15 million annually (Danfoss case study, 2025), and Walmart runs 68% of its supplier negotiations through AI (Walmart investor briefing, 2025).

To support this shift, major players have built the infrastructure for agents to communicate and transact. Google released A2A (Agent-to-Agent protocol), the open standard for how agents discover each other and exchange messages. Stripe launched ACP (Agentic Commerce Protocol, Sep 2025) and an Agentic Commerce Suite (Dec 2025) powering checkout in ChatGPT. Google released AP2 (Agent Payments Protocol, Sep 2025) with 60+ partners including Mastercard, PayPal, Coinbase, and Adyen, defining how agents carry cryptographic proof of a user's payment authorization. Visa developed the Trusted Agent Protocol for verifying agent identity at the point of sale.

But there is a critical gap in this stack. None of these protocols or products answer three fundamental questions:

  1. Should this transaction happen? When an AI procurement agent commits $50,000 of company budget to a supplier's agent, who verifies the agent was actually authorized to make that commitment, that the spending falls within approved limits, and that the principal hasn't revoked the agent's authority since the negotiation started?

  2. Was the deliverable acceptable? When Agent B delivers a research report, a code module, or a data analysis that Agent A paid for, who evaluates whether the output actually meets the agreed specification? Stripe explicitly leaves fulfillment verification to the merchant. Payment rails know money moved — they have no concept of whether value was delivered.

  3. Who's right when things go wrong? When two autonomous agents disagree about whether a contract was fulfilled, the evidence isn't a shipping receipt or a tracking number. Instead it's a negotiation transcript between two LLMs, an AP2 mandate chain, and a deliverable that needs qualitative assessment against a specification. No existing dispute resolution system is designed to handle this kind of evidence.

Stripe itself states that "escrow has a precise legal definition, and Stripe doesn't provide escrow services or support escrow accounts" (Stripe documentation, Manual Payouts). Their Agentic Commerce Suite explicitly leaves dispute management to the merchant. AP2's own specification asks the open question: "If a fraudulent or incorrect transaction occurs, who is accountable?" (AP2 Specification, google-agentic-commerce/AP2). The legal landscape confirms the urgency; the Air Canada chatbot case (2024) established that companies are liable for their AI's misrepresentations, the ABA's Task Force concluded that "a human must always bear ultimate responsibility" for AI agent actions (ABA Task Force on AI & Law, Dec 2025), and Harvard Law research found that conventional agency law solutions are insufficient for AI agents making uninterpretable decisions at unprecedented speed and scale (Noam Kolt, Harvard Law School, 2025).

Every layer of the agent commerce stack is being built except the trust layer. That's what AgentVerify provides.

What AgentVerify Is

AgentVerify is a payment-rail-agnostic trust verification and dispute resolution control plane that sits between any two transacting AI agents. It issues signed, verifiable trust decisions and provides evidence-linked reasoning that external systems can execute. It answers the three questions above before money moves.

What it does:

  • Verifies that both agents are authorized to make the deal they're making
  • Assesses whether the deliverable meets the agreed specification
  • Resolves disputes using agent-native evidence when parties disagree
  • Issues cryptographically signed verdicts (release, refund, split) that payment systems execute

What it does not do:

  • Hold funds or process payments (that's Stripe's job, or PayPal's, or Visa's, or a smart contract's)
  • Replace payment rails (it integrates with all of them via adapter interfaces)
  • Require any specific payment method (works equally well with fiat, crypto, or any future rail)

AgentVerify is the brain that decides. The payment rail is the bank that executes. This architecture lets developers plug AgentVerify into Stripe, PayPal, Visa, or custom rails without changing trust logic. The same decision plane can be reached via REST or A2A, while agent cards and reputation scoring provide pre-transaction trust signals for counterparty discovery and routing.

How It Works

Layer 1: Pre-Transaction Authorization Verification

Before a transaction settles, AgentVerify verifies that both agents hold valid authorization from their principals. In the AP2 protocol, this authorization takes the form of Intent Mandates — cryptographically signed Verifiable Digital Credentials that specify what an agent is allowed to buy, how much it can spend, and under what conditions. AgentVerify parses these mandates, verifies their cryptographic signatures, checks that they haven't expired or been revoked, and confirms that the specific transaction falls within the authorized parameters.

Because AP2 is still early in production adoption, AgentVerify also supports a "mandate-lite" path, a degraded but functional authorization system using API keys with spending policies, OAuth delegation tokens, or simple signed attestations. This lets companies use AgentVerify today without waiting for full AP2 infrastructure, while the mandate-lite system produces the same type of evidence artifacts (authorization records, scope, timestamps, signatures) used in disputes. As AP2 adoption grows, agents with full AP2 mandates receive higher trust scores, creating a natural market incentive to upgrade. This is the same mechanic Chrome used to drive HTTPS adoption by showing "Not Secure" warnings on HTTP sites.

Every verified mandate is hashed and stored as immutable evidence, which is the foundation for any future dispute.

Layer 2: Post-Transaction Deliverable Assessment

After an agent delivers work but before payment finalizes, AgentVerify evaluates whether the deliverable meets the agreed specification. The system supports multiple verification methods depending on the task type:

  • Hash-match verification for deterministic outputs (did this computation produce the expected result?)
  • Schema validation for structured data (does this API response match the agreed JSON schema?)
  • LLM-based assessment for subjective deliverables (does this research report cover the topics specified in the acceptance criteria, with proper citations, at the quality level agreed upon?)
  • External oracle verification for programmatically testable deliverables (does this code pass the buyer's test suite?)
  • Composite verification combining multiple methods (schema validation must pass AND LLM assessment must score above threshold)

The LLM assessment is the core differentiator. When two agents agree on a research task with specific acceptance criteria — "must cover market size projections from 3+ analyst firms, must include competitive landscape, must be properly cited" — AgentVerify evaluates the deliverable against each criterion independently, produces a weighted score, flags specific deficiencies, and generates a confidence level for the overall assessment. The default assessment and arbitration engine runs on Amazon Nova foundation models via Amazon Bedrock, chosen for cost-efficient structured evaluation at scale while maintaining the quality needed for trust decisions. The provider abstraction supports multiple models — assessments and arbitrations can be routed to different providers based on session value, verification complexity, or customer preference. The full assessment is stored as evidence.

If the deliverable scores above the buyer's threshold, AgentVerify issues an automatic "approve release" verdict. If it scores below, the buyer agent is notified and can accept, reject, or dispute.

Layer 3: Dispute Resolution with Agent-Native Evidence

When disputes arise, AgentVerify resolves them through a three-tier arbitration system:

Tier 1 — Automated Rules Engine. Handles objective, unambiguous cases. Deadline expired with no deliverable? Automatic refund verdict. Hash-match verification passed but buyer disputes quality? Automatic release verdict — the hash is deterministic. Both parties agree to cancel? Immediate refund. Tier 1 is designed to handle the majority of straightforward disputes instantly with high confidence.

Tier 2 — AI-Assisted Arbitration. For disputes that can't be resolved by rules alone, AgentVerify compiles a full evidence bundle — the verified mandate chain, the signed agreement specification, the deliverable content, the AI quality assessment, both parties' dispute submissions, reputation histories, and a complete timeline of events — and submits it to an AI arbitrator. The arbitrator evaluates the evidence against the original acceptance criteria and produces a verdict (release, refund, or a specific percentage split) with detailed reasoning citing specific evidence. This approach is informed by the AAA-ICDR's (American Arbitration Association) work on AI-assisted dispute resolution, which has demonstrated significant speed and cost improvements over traditional arbitration.

Tier 3 — Human Arbitration. For high-value disputes or cases where the AI arbitrator's confidence is below threshold, the case escalates to human review. The arbitrator receives the full evidence bundle plus the AI's recommendation and reasoning, providing a structured starting point rather than a blank-slate investigation.

Every verdict is cryptographically signed by AgentVerify and publicly verifiable — any party, including the payment rail, can independently confirm that a verdict is authentic and untampered via a proof-minimal public verification endpoint.

What's Built

AgentVerify is not a concept; the core trust infrastructure is implemented:

Trust flows. Agent registration with API keys and webhook configuration. Session lifecycle with enforceable state transitions covering the full verification journey from agreement registration through verdict issuance. Mandate verification supporting both mandate-lite and AP2-style submissions. Deliverable assessment pipeline with all five verification methods (hash-match, schema-validation, LLM-assessment, external-oracle, composite). Three-tier dispute resolution with escalation logic. Signed verdict issuance (release, refund, split) with public proof verification.

Security. Idempotency enforced on all mutating routes. Authentication and route-level rate limiting. SSRF-aware webhook delivery controls. Tier 3 arbiter authorization gates. Proof-minimal public verification endpoint that exposes only verdict validity — full session details are restricted to participants.

Integration surfaces. REST API for agents, sessions, disputes, and verdict verification. A2A routes (feature-flagged) for verified session creation, deliverable submission, verdict checking, and dispute actions. Reputation endpoint with computed trust scores. TypeScript and Python SDKs with idempotent mutation behavior and verdict/webhook verification helpers.

Why This Is Different from Existing Solutions

It's not Stripe's dispute system. Stripe's dispute handling automates how a single merchant responds to credit card chargebacks. It's post-hoc, single-party, and reactive — it kicks in after money has already moved and a chargeback has been filed. AgentVerify is pre-emptive, multi-party, and neutral — it verifies authorization and assesses deliverables before settlement, preventing disputes from arising.

It's not the AgentEscrowProtocol SDK. A Solidity smart contract exists on Base mainnet for USDC-based agent escrow. It's a research project with no live service, crypto-only (excluding the entire fiat enterprise market), has primitive binary dispute resolution, no authorization verification, no deliverable assessment, no protocol interoperability, and a flat 2.5% fee that doesn't scale for enterprise transactions. It validates that the problem is real — someone else identified the same gap — but the distance between a weekend hackathon smart contract and enterprise trust infrastructure is vast.

It's not OpenAI's dispute triage cookbook. OpenAI published a cookbook showing how to build AI agents that automate a merchant's response to Stripe chargebacks. It operates within one party's internal data (their own order database, email logs, phone records), has no concept of agent identity or authorization verification, and handles disputes about shipping and fulfillment — not about the quality of AI-generated deliverables assessed against agreed specifications.

It's payment-rail agnostic by architecture, not just by intent. AgentVerify issues verdicts, not payment instructions. The verdict object (release, refund, split with percentages, confidence, reasoning, cryptographic signature) is the same regardless of whether the underlying rail is Stripe, PayPal, Visa, or a smart contract. Payment rail adapters translate this verdict into rail-specific actions. This means AgentVerify doesn't compete with any payment rail — it complements all of them. It also means AgentVerify isn't exposed to the risk of any single payment method winning or losing the agent commerce market.

Architecture

AgentVerify is built as a modular control plane with clear separation between transport (routes/API), domain logic (services), async side effects (workers), and shared types/schemas:

Mandate Verification Service — Parses and validates AP2 Verifiable Digital Credentials (SD-JWT format, Ed25519 signatures), checks spending caps, category restrictions, expiration, and revocation. Falls back to mandate-lite verification for agents without AP2 infrastructure. Both paths produce identical evidence artifact structures for downstream dispute resolution.

Deliverable Assessment Service — Pluggable verification engine supporting hash-match, schema validation, LLM-based assessment, external oracle, and composite methods. The default LLM provider for assessment and arbitration is Amazon Nova via Amazon Bedrock, with a provider abstraction that allows routing to alternative models based on session value or complexity. Produces structured assessment results stored as evidence artifacts.

Dispute Resolution Service — Compiles evidence bundles from the other two services, runs three-tier arbitration (automated rules → AI arbitration → human review), and issues cryptographically signed verdicts. Evidence bundles include the full mandate chain, agreement specification, deliverable content, assessment results, dispute submissions, reputation histories, and event timeline.

Verdict & Proof System — Verdicts are signed with Ed25519 and verifiable via a public endpoint. Any party — including payment rails — can independently confirm that a verdict is authentic without accessing session details.

These services are exposed via REST API with Zod-validated requests, idempotent mutations, and authenticated/rate-limited access. A2A endpoints (feature-flagged) provide protocol-native access for agents in Google's ecosystem. Webhook delivery with retry logic and HMAC signatures notifies agents of state changes. Payment rail adapters (Stripe Connect + generic webhook) translate verdicts into settlement actions.

The tech stack is TypeScript/Node.js (Fastify), PostgreSQL (Drizzle ORM), Redis (caching, rate limiting), and Amazon Nova foundation models on Amazon Bedrock as the default provider for deliverable assessment and dispute arbitration, with a provider abstraction supporting alternative models.

Market Positioning

AgentVerify occupies the only unbuilt layer in the emerging agent commerce stack:

Layer Who's Building It Status
Agent Communication Google (A2A), Anthropic (MCP) Shipped, production
Agent Payment Execution Stripe (ACP, SPTs), Visa (TAP), Mastercard (Agent Pay) Shipped, early production
Agent Payment Authorization Google (AP2) with 60+ partners Shipped, reference implementations
Agent Identity Visa (TAP), Trulioo (Digital Agent Passport), Skyfire (KYAPay) Shipped, early production
Agent Trust Verification & Dispute Resolution Nobody AgentVerify

The competitive moat is trust data. Every session that flows through AgentVerify generates authorization patterns, deliverable quality benchmarks, dispute outcomes, and reputation signals. This data compounds — after thousands of verified sessions, AgentVerify can predict which agent transactions are likely to dispute, which verification methods catch quality issues most reliably, and which agents are trustworthy counterparties. No competitor can replicate this dataset without processing equivalent transaction volume.

The expansion path follows the data: agent transaction insurance (underwriting agent errors using dispute data), agent credit scoring (which agents are reliable transactors?), and agent compliance certification (regulatory attestation for enterprises deploying autonomous purchasing agents). Each adjacent product is enabled by the trust data that only a high-volume verification layer accumulates.

Accomplishments That We're Proud Of

The accomplishment we keep coming back to isn't any single feature — it's the reframe.

This project started as "Agent Escrow," a crypto-native smart contract on Base that would hold USDC between transacting agents. Over the course of building it, we realized we were solving the wrong problem in the wrong way. The value was never in holding funds — Stripe Connect, PayPal, and a dozen other services already do that. The value was in the decision of whether funds should move. That realization — that the gap in the agent commerce stack is trust verification, not payment plumbing — changed everything about the architecture. We ripped out the blockchain layer, made the system payment-rail agnostic, and refocused entirely on the three questions no one else is answering: is this authorized, was this acceptable, who's right.

The result is a working trust control plane, not a concept. Agent registration, session lifecycle with enforced state transitions, mandate verification (both AP2-style and a mandate-lite fallback for real-world adoption), five pluggable deliverable verification methods including LLM-based qualitative assessment powered by Amazon Nova foundation models on Amazon Bedrock, three-tier dispute resolution with escalation, cryptographically signed verdicts with public proof verification, and both TypeScript and Python SDKs. The security posture is real — idempotent mutations, rate limiting, SSRF-aware webhook delivery, proof-minimal public endpoints that don't leak session data.

We're also proud of the mandate-lite design. It would have been easy to build exclusively for AP2 mandates and have a technically pure system that nobody can use yet because AP2 isn't in production. Instead, we built a graduated authorization path — API keys with spending policies today, OAuth tokens tomorrow, full AP2 mandates when the ecosystem catches up — where every step produces the same evidence artifacts for dispute resolution. This means AgentVerify can onboard real users now while being architecturally ready for the protocol-native future. That pragmatism feels like the right instinct for infrastructure that needs to exist before the market fully forms.

What We Learned

The agent commerce stack has a trust gap, and it's intentional. When we dug into AP2, ACP, Stripe's Agentic Commerce Suite, and Visa's Trusted Agent Protocol, we expected to find that trust verification was being built somewhere and we'd missed it. The opposite was true. Each protocol explicitly scopes itself to avoid trust decisions. AP2 defines the mandate format but asks "who is accountable?" as an open question. Stripe states it doesn't provide escrow and leaves dispute management to the merchant. Visa's TAP verifies agent identity but not authorization scope. These aren't oversights — they're deliberate boundaries. Each player is building their piece and leaving the trust adjudication layer for someone else. That "someone else" doesn't exist yet.

The hard problem isn't technical — it's the chicken-and-egg between protocols and adoption. AP2 mandates are beautifully designed. They solve the authorization problem with cryptographic rigor. But almost no agents carry them in production today. If we'd built AgentVerify exclusively for AP2, we'd have a perfect verification engine with zero throughput. The mandate-lite fallback was the single most important design decision we made, and it came from understanding that infrastructure has to meet the market where it is, not where you want it to be. HTTPS didn't win because browsers refused HTTP — it won because browsers degraded HTTP visibly while making HTTPS easy.

Deliverable verification is harder and more valuable than we initially thought. We started thinking of it as a simple quality check — does the output match the spec? In practice, assessing whether a research report, a code module, or a data analysis meets an agreed specification is a genuinely hard problem that requires structured evaluation prompts, per-criterion scoring, confidence calibration, and careful handling of edge cases where the deliverable is technically complete but substantively poor. Amazon Nova on Bedrock proved to be the right default engine for this — it handles structured JSON evaluation output reliably at a cost profile that makes per-session assessment economically viable, which matters when the goal is to verify every agent transaction, not just expensive ones. Building this well is the core differentiator. Payment rails can add mandate checks relatively easily. No payment rail is going to build a pluggable, multi-method deliverable assessment engine with LLM-based qualitative evaluation — it's outside their domain expertise and business model. That's where AgentVerify's moat actually lives.

Dispute resolution for agent commerce requires fundamentally different evidence than traditional disputes. We studied Stripe's dispute system, OpenAI's dispute triage cookbook, and the AAA-ICDR's approach to AI-assisted arbitration. The existing systems all assume human-generated evidence — shipping receipts, email threads, phone logs, tracking numbers. Agent-to-agent dispute evidence is entirely different: mandate chains proving authorization scope, negotiation transcripts between LLMs, deliverable assessments against machine-readable acceptance criteria, and reputation histories built from prior verified transactions. Building the evidence bundle compiler — the system that assembles all of this into a structured package that both AI and human arbitrators can evaluate — was one of the most technically interesting pieces of the project.

Payment-rail agnosticism is an architectural discipline. Early in the project, we almost built a Stripe-specific integration as the core flow. Every time we caught ourselves writing Stripe-specific logic in the trust layer, we had to step back and ask: would this work if the payment rail were PayPal? A smart contract? A wire transfer? That discipline forced cleaner abstractions. Verdicts are self-contained signed objects. Settlement is an adapter concern. The trust logic knows nothing about payment mechanics. This separation is what makes AgentVerify genuinely rail-agnostic rather than rail-agnostic-in-theory-but-Stripe-in-practice.

What's Next for AgentVerify

Payment rail adapters turn verdicts into settlement. AgentVerify currently issues signed verdicts — the trust decision is made, but execution is left to the developer. The next step is a payment adapter interface with concrete implementations: a Stripe Connect adapter mapping verdicts to PaymentIntent captures, transfers, and refunds; a generic webhook adapter for custom integrations; and a settlement orchestration worker that tracks execution state, handles retries, and reconciles outcomes. The architecture is already designed for this — verdicts carry session IDs, idempotency anchors, and payment-action-friendly decision types (release, refund, split with percentages). The adapter layer is engineering, not research.

Agent Cards turn reputation into a discovery signal. The reputation system currently produces trust scores from transaction history. The next step is a formal Agent Card — a signed, structured identity document combining an agent's capabilities, trust profile, policy limits, and verification level. When an agent discovers a counterparty via A2A, the Agent Card answers "should I do business with this agent?" before any session is created. A rating pipeline with anti-gaming controls (volume weighting, counterparty diversity, recency windows) ensures scores can't be manufactured. This is where AgentVerify transitions from a point-of-transaction tool into a network-layer trust signal.

A2A native integration makes trust invisible. The A2A endpoints are currently feature-flagged. The expansion path is the transparent proxy model. AgentVerify sits in the A2A communication path between two agents, intercepting task creation to verify mandates, intercepting task completion to assess deliverables, and issuing verdicts without either agent explicitly calling a separate API. Trust verification becomes ambient infrastructure rather than an opt-in step. This is the end-state architecture: agents transact via A2A as normal, and trust just works.

The trust data enables adjacent products. Every session generates authorization patterns, deliverable benchmarks, dispute outcomes, and reputation signals. This data compounds into products that no one else can build without equivalent transaction volume: agent transaction insurance (underwriting agent errors using actuarial data from thousands of verified sessions), agent credit scoring (probabilistic assessment of which agents will fulfill commitments), and agent compliance certification (attestation that an enterprise's agents meet regulatory standards for autonomous purchasing). Each product is gated on trust data that AgentVerify is uniquely positioned to accumulate.

The trajectory is clear: trust API → trust network → trust economy.

Why Now

The window is specific and narrow. Agent commerce infrastructure is being built right now — AP2 launched September 2025, Stripe's Agentic Commerce Suite launched December 2025, Visa's TAP is in beta. Enterprise deployments are transitioning from pilot to production. But Gartner warns that 40%+ of agentic AI projects may be cancelled by end of 2027 due to inadequate risk controls ("Predicts 2025: Autonomous Agents Will Redefine Enterprise Operations"). The trust and dispute resolution layer is the risk control that enterprises will demand before authorizing agents to commit real budget autonomously. Build in 2026, capture early adopters in 2027, scale with mainstream adoption in 2028.

Built With

  • .well-known-jwk-keyset-endpoint
  • aes-256-gcm-cloud/llm-services:-aws-bedrock-(amazon-nova-models)
  • argon2id
  • javascript
  • languages:-typescript
  • mcp
  • optional-a2a-api-surface
  • optional-anthropic/openai-provider-routing-platform/infra:-docker-+-docker-compose-testing:-vitest-(unit/integration/abuse)
  • pnpm-workspaces-backend-framework:-fastify-validation/typing:-zod-orm/db-access:-drizzle-orm-databases/state:-postgresql
  • pytest-(python-sdk)-apis/protocols:-rest-apis
  • python
  • redis-queues/workers:-bullmq-security/crypto:-jose-(eddsa-jws)
  • shell-(bash/zsh)-runtime/package-tooling:-node.js-20+
  • sql
  • webhook-signing/verification
Share this project:

Updates

Submission history