Your UCP Validator Says PASS. AI Agents Still Can't Buy From You. Here's Why.

You ran your profile through a validator.

Green checkmark. "Valid UCP profile." You're done, right?

Then a Google AI Mode agent tries to browse your catalog and exits silently. No error. No explanation. Just... nothing.

This is happening to most merchants who think they're UCP-ready. The problem isn't their profile - it's what their validator checked.

There are four distinct levels of UCP validation. Most tools - including basic UCP checkers - only implement Level 1. Levels 2, 3, and 4 are where real-world agent failures hide.

Why This Matters Now

Microsoft announced general availability of UCP feeds in Merchant Center on April 21, 2026, with Target as the launch partner. Ulta Beauty went live with agentic commerce the same day, linking 46 million loyalty members through the UCP Identity Linking capability.

The spec is no longer theoretical. AI agents from Google and Microsoft are querying /.well-known/ucp files against real stores right now. According to the UCP consortium, over 12,000 merchants have published UCP profiles as of Q1 2026.

A profile that "passes" a basic validator but fails in production means your store is invisible to that traffic - with no feedback loop telling you why. If you're managing UCP implementations across client domains, multiply these failure modes by every store in your portfolio.

Level 1: Structural Validation (What Most Tools Check)

This is JSON schema validation. It answers: Is this valid JSON? Does it have the required fields? Is the version format correct?

{
  "ucp": {
    "version": "2026-01-11",
    "services": { ... },
    "capabilities": [ ... ]
  }
}

What Level 1 catches:

• Missing ucp root object (UCP_MISSING_ROOT)
• Missing or malformed version (UCP_INVALID_VERSION_FORMAT)
• Missing required fields in capabilities or payment handlers
• Basic type errors

What Level 1 misses: Everything else. A profile can be structurally perfect and completely broken for agent commerce. Level 1 tells you the envelope is addressed. It says nothing about whether the letter inside makes sense.

Level 2: UCP Compliance Rules (Where It Gets Interesting)

This is where the spec's logic comes in - rules that go beyond JSON structure into protocol correctness.

Namespace/Origin Binding

UCP uses reverse-domain namespaces (dev.ucp.shopping.checkout). Schema URLs must originate from a domain matching the namespace authority.

{
  "name": "dev.ucp.shopping.checkout",
  "schema": "https://ucp.dev/schemas/shopping/checkout.json"     // correct
  "schema": "https://example.com/schemas/checkout.json"           // UCP_NS_ORIGIN_MISMATCH
}

The first passes. The second triggers UCP_NS_ORIGIN_MISMATCH. This prevents a spoofing attack where a malicious profile redefines what a "checkout" is.

Extension Orphans

Declaring a Fulfillment extension without its parent Checkout capability creates an orphan:

"capabilities": [
  {
    "name": "dev.ucp.shopping.fulfillment",
    "extends": "dev.ucp.shopping.checkout"
  }
]

Agents prune orphaned extensions during capability negotiation. You think you're offering fulfillment options. The agent sees nothing.

HTTPS Everywhere + Trailing Slashes

One HTTP endpoint fails the entire profile. The spec also forbids trailing slashes on endpoint URLs. A basic JSON validator catches neither:

"endpoint": "http://api.example.com/ucp"    // fails - not HTTPS
"endpoint": "https://api.example.com/ucp/"   // fails - trailing slash

Missing Signing Keys

Webhook payloads must be signed. No signing keys means agents can't verify webhook authenticity, which means they can't trust order confirmations.

What Level 2 catches: Profiles that look valid but violate protocol rules - namespace mismatches, orphaned extensions, HTTPS gaps, trailing slashes, missing keys.

What Level 2 misses: Whether any of your declared endpoints actually exist and respond.

Level 3: Network Validation (The One That Bites in Production)

This is where most validators stop building. Remote validation requires making actual HTTP requests - it's infrastructure, not just logic. A full UCP validator needs to go beyond static analysis.

Level 3 checks:

• Do your declared schema URLs actually resolve?
• Do your API endpoints respond to requests?
• Are your signing keys in valid JWK format?
• Do your schemas match what you declared in the profile?

A common failure pattern:

Profile declares:
  "schema": "https://ucp.dev/schemas/shopping/checkout.json"

Reality: URL returns 404 - CDN misconfiguration from a deploy last week
Result: Agent fetches schema, gets error, abandons negotiation

The profile is structurally perfect. It passes Level 1 and Level 2. But the agent can't complete discovery because a CDN cache is serving a stale 404.

Another common Level 3 failure: signing keys that are syntactically present but malformed. If the JWK's x or y values are invalid base64url, the key is useless. A Level 1/2 validator sees a signing key object and passes. A Level 3 validator parses it and fails.

What Level 3 catches: Broken deployments, CDN misconfigurations, stale schemas, malformed keys, unreachable endpoints.

What Level 3 misses: Whether your checkout flow actually works end-to-end.

Level 4: Agent Simulation (The Real Test)

Level 4 simulates an AI agent's full interaction with your UCP endpoint - not just the profile, but the checkout lifecycle.

The UCP checkout state machine:

incomplete -> requires_escalation -> ready_for_complete -> completed

A simulation runs through all of these:

1. Discovery - fetch /.well-known/ucp, parse profile, compute capabilities
2. Capability negotiation - compute the intersection between agent and merchant capabilities
3. Cart/session creation - POST to checkout endpoint with line items
4. State progression - submit address, select shipping, apply payment handler token
5. Completion - attempt ready_for_complete state transition

Most implementations fail at step 3 or 4 - not because the profile is wrong, but because the backend diverges from what the profile advertises. A profile declares dev.ucp.shopping.cart, but the backend returns a 500 when the agent tries to create a cart.

Level 4 doesn't just validate your profile. It validates your implementation.

Where Failures Actually Cluster

Across the profiles we've validated with the UCPtools validator, a clear pattern emerges:

• Level 1 passes about 90% of the time if the profile was generated by a tool or built by someone who read the spec once. These are table-stakes.
• Level 2 issues show up in roughly 60% of profiles - most commonly missing signing keys (42% of all Level 2 failures) or namespace mismatches introduced by custom capabilities. These are spec-reading problems, fixable in minutes once identified.
• Level 3 failures are the most surprising to teams. A recently-working endpoint that broke silently after a deploy. A CDN that cached a 404. A certificate renewal that didn't propagate. These aren't code bugs - they're infrastructure drift. About 35% of profiles that pass Level 2 fail Level 3.
• Level 4 failures almost always point to incomplete backend implementations rather than profile errors. The profile says "I support cart," but the cart endpoint returns a 500. You can test this with the AI Agent Simulator.

The pattern: developers validate during setup, then never re-validate after subsequent deploys. Level 3 and Level 4 failures accumulate silently over weeks. By the time someone notices, they've been invisible to AI agents for an entire release cycle.

What To Do

1. Run a full 4-level validation against your profile, not just a schema check. A Level 1 pass with no deeper checks is worse than no validation - it gives you false confidence.
2. Re-validate after every deploy - Level 3 failures are deployment artifacts, not code problems. The profile didn't change; the infrastructure underneath it did.
3. Add UCP validation to your CI/CD pipeline - catch regressions before agents do. The ucp-validate GitHub Action fails the build if your AI readiness score drops below a threshold.
4. If you're a GEO consultant managing multiple client domains, run validation across all of them regularly. Level 3 failures are per-deployment, not per-profile - each client's hosting stack, CDN config, and certificate chain breaks differently. A reporting dashboard that tracks validation scores across domains is the closest thing to "measurable AI discoverability outcomes" that exists today.

If your profile passes Level 1 but you're not sure about levels 2-4, that's probably the gap. The spec is good. The tooling around it is still catching up.

UCPtools is an independent community tool - not affiliated with Google, Shopify, or the UCP consortium.