Your UCP Profile Is Valid. Here's What AI Agents Actually See When They Browse Your Store.

You ran the validator. It came back green. Your .well-known/ucp file parses as valid JSON. The required fields are present. The schema checks pass.

Congratulations. Your store exists. But here's what the validator didn't tell you.

An AI shopping agent doesn't stop at "valid JSON." It reads your manifest, then it actually tries to use your store. It browses your catalog. It adds items to your cart. It checks your identity flow. It attempts to complete a purchase. And at every step, it encounters things the validator never checked.

Last week, 39 people validated their UCP profiles on UCPtools. Their manifests passed. But when those same people ran the AI agent simulator - the tool that actually sends agent-style requests to their endpoints - only 4 of them did. That's a 90% drop-off between "is my profile valid?" and "does my store actually work for AI agents?"

The gap between those two questions is where stores become invisible. Let me show you what lives in that gap.

What the Simulator Actually Reveals

The validation scan checks your manifest. The simulator checks your store. It sends real agent-style HTTP requests to your endpoints - the same requests Google AI Mode, Gemini, and ChatGPT shopping agents would send. It doesn't just read your profile. It acts on it.

Here are five things the simulator catches that structural validation never will.

1. Can Agents Cryptographically Trust Your Manifest?

Your manifest declares signing_keys - cryptographic keys that let AI agents verify your identity and the integrity of your responses. Without them, an agent can read your profile but it can't trust it. It will browse your catalog. It might even add items to a cart. But when it reaches checkout? It walks away.

This is the single most common failure across UCP profiles. It's not a JSON error. The manifest is valid. The keys are just missing - or they're present but cryptographically invalid, or they don't match the keys that signed your responses. A structural validator sees a complete manifest. The simulator sees the trust chain break.

Your signing keys are valid today. Are they still valid next week when a certificate rotates? When your platform pushes an update that regenerates them? When your CDN changes the response signature? If the answer is "I don't know," the agent doesn't either - and it errs on the side of walking away.

2. Does Your Manifest URL Match Your Declared Origin?

Your manifest lives at https://store.example.com/.well-known/ucp and declares "origin": "https://store.example.com". That's correct. But your CDN serves the manifest from https://www.store.example.com/.well-known/ucp. Or your platform redirects store.example.com to www.store.example.com but the manifest still says store.example.com. The agent requests one URL and gets a manifest that claims it came from somewhere else.

The namespace doesn't match the origin. The validator sees a file that parses correctly. The simulator sees a contradiction, and the agent aborts the session. No browsing. No cart. No checkout. The store is technically "valid" and completely unreachable.

3. What Payment Methods Do Agents Actually Find?

Your manifest declares checkout and cart capabilities. It lists a payment_handlers array. The JSON is correct. But when the agent tries to POST a payment intent to your handler endpoint, it gets a 302 redirect to a page the agent can't render. Or a CORS block. Or a 200 response with an HTML body instead of a JSON payment confirmation.

The simulator doesn't just verify that payment_handlers exists in the manifest. It calls the handler. It follows the redirect. It inspects the response. A payment handler that validates but doesn't transact is the difference between "profile is correct" and "money moves."

4. Can Agents Recognize Returning Users?

You set up Identity Linking. Your endpoint returns 200. The validator says the capability is present and responding. But when the simulator sends a cross-domain identity request - simulating a user who browsed your store through Google AI Mode last week and is now returning through Gemini - the recognition fails. The endpoint works in isolation but breaks across domains.

The validator tests whether Identity Linking exists. The simulator tests whether it actually links identities. Those are two different things, and the second one is what matters to an AI agent trying to serve a real customer.

5. Can Agents Do More Than Just Add Items to Cart?

Your Cart capability works: the agent can add a product. But can it remove one? Can it view the current cart contents? Can it update quantities? In production UCP profiles, add-to-cart often works while remove-from-cart doesn't. The capability is "functional" by structural standards. It's broken by functional standards.

The simulator runs the full cart lifecycle - add, view, modify, remove. Each step must complete. A cart that only does half the operations creates a terrible agent experience: the AI adds an item the user asked for, then can't remove it when they change their mind. The agent abandons the session.

What Changes Between Now and Next Week?

Here's the uncomfortable reality: every one of those checks can pass today and fail tomorrow. Without anyone touching your code.

Your TLS certificate renews and the new CA isn't in the agent's trust store. Your platform ships an update that changes the manifest shape. Your payment gateway configuration drifts from what the manifest declares. A caching plugin starts serving /.well-known/ucp as text/html instead of application/json. A signing key rotates in your infrastructure but not in your published profile.

None of these trip a build alert. Your CI is green. Your dashboard shows no errors. Human visitors browse your store without issue. The only thing that broke is the machine-readable layer that no human ever visits - and the AI agent that hits it doesn't file a bug report. It just moves on to the next merchant whose profile responds correctly.

The simulator caught it this time because you ran it. What catches it next time?

Monitoring: The Same Checks, Running Automatically

This is the bridge between "I validated once" and "I know my store is agent-ready right now."

Monitoring runs the same comprehensive checks that the simulator runs - structural, rules, network, SDK-level agent simulation - but it runs them on a schedule. Every week. Every domain. It compares the results against a known-good baseline and alerts you when something changes: what was green, what turned red, and how to fix it.

Each simulator finding maps directly to a monitoring scenario:

• The simulator confirmed your signing_keys are valid today. Monitoring verifies they're still valid next week, and the week after - catching key rotation drift before agents notice.
• The simulator verified your namespace and origin match. Monitoring catches the day your CDN configuration changes and they stop matching.
• The simulator tested your payment handlers end-to-end. Monitoring detects when a payment gateway update breaks that chain.
• The simulator proved your Identity Linking works across domains. Monitoring catches the platform update that silently breaks cross-domain recognition.
• The simulator confirmed your full cart lifecycle. Monitoring catches the deployment where a new feature breaks remove-from-cart.

You validated your profile. That's step one. Now you know what AI agents actually see when they browse your store. Step two is making sure they see the same thing next week.

Run the simulator on your store now - see exactly what AI agents see when they try to shop from you: ucptools.dev/tools/simulator

Start monitoring your domains - catch breaks before agents stop finding you: ucptools.dev/pricing