DEV Community: Peter

Which UCP version is your validator actually checking against?

Peter — Thu, 24 Sep 2026 10:28:33 +0000

If you have a UCP profile at /.well-known/ucp, you have probably run it through a validator and got a score. The question almost nobody asks next is which version of the spec that score was measured against.

It matters more than it sounds. UCP has four published releases: 2026-01-11, 2026-01-23, 2026-04-08 and 2026-08-25. The profile shape changed completely in April, and the signing-keys field was renamed in August. A validator pinned to an older release does not just miss the new features. It can fail a correct profile and pass one that stopped being valid months ago, and both results look like any other report.

We learned this the hard way. Earlier this month I wrote up how six profile builders inside our own product were still emitting the January shape in September, and how our tests agreed with them the whole time. This post is the outward-facing version of the same lesson: how to tell whether the tool you rely on is current, and how to check it without taking anyone's word for it, ours included.

What each tool says it validates against

I went through the public UCP validators and wrote down the spec version each one states on its own site. As of September 24, 2026:

Tool	Spec version stated
UCPChecker	every published version, including `2026-08-25`
UCPtools	`2026-08-25`
Rankly	`2026-01-23`
aicommerceaudit	`2026-04-08`
spck.dev	`2026-04-08`
UCPhub	`2026-04-08`
Nextwaves UCP Tester	not stated

A few caveats before anyone reads this as a leaderboard. These are claims from each tool's own pages, not results of a test I ran against each of them. Stating an older version is not the same as being wrong, since a tool can be deliberately pinned, and plenty of live profiles still declare 2026-04-08. And a stated version is not a guarantee either. We stated a version we did not fully implement for five months.

What the table does tell you is where to look. If your profile declares 2026-08-25 and your validator says 2026-04-08, some of what it reports is about a spec your profile is not using.

What actually changed between versions

The changes that trip validators up are structural, so a validator on the wrong side of them gives confident wrong answers rather than vague ones.

2026-04-08 changed the shape of the profile. Services went from an object with transports nested under their name to an array of entries with a flat transport field. Capabilities went from an array of objects carrying their own name to a map keyed by name. Payment handlers moved from root $.payment into $.ucp.payment_handlers.

// 2026-01-11 / 2026-01-23
"services": {
  "dev.ucp.shopping": {
    "rest": { "schema": "...", "endpoint": "https://shop.example/ucp" }
  }
},
"capabilities": [{ "name": "checkout", "spec": "..." }]

// 2026-04-08 and 2026-08-25
"services": {
  "dev.ucp.shopping": [
    { "transport": "rest", "endpoint": "https://shop.example/ucp", "schema": "..." }
  ]
},
"capabilities": { "checkout": [{ "spec": "..." }] }

A validator built for January can read a current profile as malformed from the first key, and every later check that depends on finding the services is either skipped or fails.

2026-08-25 renamed signing_keys to keys, and removed the old name entirely. A validator on 2026-04-08 can look for signing_keys in a current profile, not find it, and report that your signing keys are missing. It can also accept a profile that still uses signing_keys while declaring 2026-08-25, which is exactly the profile it should be flagging.

2026-08-25 also moved and renamed a lot of smaller things: payment extensions from dev.ucp.shopping.* to dev.ucp.common.payment.*, the allows_ prefix dropped from fulfillment flags, buyer consent booleans replaced by a reverse-DNS map. It added new capabilities too, including location search and lookup, permalink and loyalty. An older validator will treat all of them as unknown.

Schema URLs became version-scoped. Unversioned https://ucp.dev/schemas/... URLs return 404 today, and https://ucp.dev/2026-08-25/... returns 200. A validator that does not fetch the schemas it is pointed at will never notice this. One that fetches the wrong ones will fail on a network error that has nothing to do with your profile.

One warning if you plan to check these details yourself: read the schemas, not the release notes. The 2026-08-25 notes get three field names wrong. They say $requestConstraints, ap2_mandates and payment_terms, while the schemas define request_constraints, dev.ucp.common.payment.ap2_mandate and dev.ucp.common.payment.terms. A validator written from the notes is wrong in exactly those places.

How to check your validator yourself

You do not need to trust a comparison table, including the one above. Three tests take about twenty minutes and will tell you more.

1. Build a fixture from the spec, not from anyone's sample. Clone the spec repository at the release tag and take the business profile example from docs/, cross-checked against source/schemas/:

git clone --depth 1 --branch v2026-08-25 \
  https://github.com/Universal-Commerce-Protocol/ucp.git

Do not use the samples repository for this. It has no tags, and its reference server still serves a 2026-04-08 profile. Run the fixture through your validator. A current validator should report zero errors on it. Anything it flags is either a real finding you can confirm in the schema, or a sign that the validator is modelling a different version.

2. Run the keys canary. Take that same fixture and rename keys to signing_keys. Against 2026-08-25, this is now wrong, and a current validator should say so. Then put keys back and remove it entirely. keys is optional in the schema, so a validator that hard-errors on its absence is inventing a requirement. The two results together tell you whether the tool knows about the August rename and whether it knows what is actually required.

3. Check what it calls required. In a /.well-known/ucp business profile, the required fields are ucp, ucp.version, ucp.services and ucp.payment_handlers. Capabilities are optional, and so are signing keys. If your validator errors on something outside that list, look the field up in the schema at the tag. We shipped a hard error for a field called supported_mechanisms that does not exist in any published version. Grepping source/ and docs/ at every tag returns nothing. Nobody noticed until we tested against the real schemas.

If a tool passes all three, it is current, whatever its site says. If it fails one, you know which of its findings to discount.

Why this is the question to ask

Scores are the part everyone looks at, and they are the part that hides this problem best. A 62 and a 25 look like a difference in your profile. In our case they were a difference in our validator: our own site went from F/25 to D/62 without the profile changing, purely by removing false negatives that came from modelling the wrong version.

So before you act on a report, whoever it came from, find out which spec it measured you against. If the answer is not written down anywhere, the fixture test above will tell you in a few minutes.

UCP is an open standard co-developed by Google and Shopify. UCPtools is an independent community tool and is not affiliated with either company. Every schema detail above was read from the published specification in the Universal-Commerce-Protocol/ucp repository at the release tags, not from the release notes. Tool versions were taken from each tool's public site on September 24, 2026.

You can check a profile against v2026-08-25 with the free validator at ucptools.dev, or run it in CI with the UCP validate GitHub Action. The story of how our own builders drifted is in Five months, six profile builders, one silent spec drift.

Five months, six profile builders, one silent spec drift

Peter — Wed, 09 Sep 2026 08:27:56 +0000

We build tooling for UCP, the Universal Commerce Protocol: validators, a generator, a WordPress plugin, an npm package, a GitHub Action. Staying current with the spec is the whole product.

On August 31 I ran our own AI Agent Test against ucptools.dev and it came back an F, 25 out of 100. Transport 0/6. Schema Loaded 0/12. Endpoint 0/12. Signing Keys 0/7.

None of it was broken. Every one of those zeros was a false negative, produced by our validator disagreeing with our generator while both modelled a version of UCP that had stopped existing in April.

The audit that followed took the rest of the day. If you build anything that reads or writes a versioned spec, the mechanism that hid this is worth recognising.

The drift was older than the release that exposed it

UCP shipped v2026-08-25 in late August, which is where the investigation started. The gap turned out to be five months wide rather than six days.

The profile shape changed in 2026-04-08:

// 2026-01-11: services keyed by namespace, transports nested under their name,
// capabilities an array of objects carrying their own `name`.
"services": {
  "dev.ucp.shopping": {
    "rest": { "schema": "...", "endpoint": "https://shop.example/ucp" }
  }
},
"capabilities": [{ "name": "checkout", "spec": "..." }]

// 2026-04-08 and later: services are arrays, transport is a field,
// endpoint is flat, capabilities are a map keyed by name.
"services": {
  "dev.ucp.shopping": [
    { "transport": "rest", "endpoint": "https://shop.example/ucp", "schema": "..." }
  ]
},
"capabilities": { "checkout": [{ "spec": "..." }] }

Payment handlers moved from root $.payment into $.ucp.payment_handlers in the same release, and signing_keys became keys in 2026-08-25.

We were still emitting the January shape in September.

Six builders, and the change had to be made in all of them

The audit was scoped to one defect in the validator. It found the same stale shape in six independent places:

Surface	What it was doing
`POST /v1/profiles/generate`	`2026-01-11` shape, declaring `"version": "2026-04-08"`, schema URLs returning 404
Web `GeneratorTool`	a second builder, `2026-01-11` hardcoded
Dashboard hosting-setup flow	a third builder, `2026-01-11` hardcoded
WooCommerce guide snippet	a fourth, copy-pasted
Our own `/.well-known/ucp`	declared `2026-01-14`
`POST /generate`	stamped `new Date()` as the version

There was more outside the table: a WordPress plugin live on wp.org declaring 2026-01-15 and failing our own validator with nine errors, an npm package five weeks behind its own repo, and a Shopify app depending on that package at a version from March.

The table is the root cause. A spec change had to be made in six places, so it was made in zero. Each builder was written for a different surface at a different time, each looked reasonable on its own, and no single change ever felt like the migration.

Why the tests were green

Three things kept this invisible, and all three are worth checking for in your own repo.

The first was a fixture that agreed with the code. We had a file called official-sample-profile-2026-04-08.json, with a header comment citing the upstream samples repository. It was not official. It was a 2026-01-11-shaped profile with the version strings swapped, and it passed because it agreed with the validator while both disagreed with the spec. A fixture built from your own output records your behaviour instead of testing it.

The second was tolerance. Our normalize helpers already handled the current shape, under names like "Shopify style" - something met in the wild and accommodated as a vendor variant rather than recognised as the spec. Because the code could read correct profiles, nothing ever failed loudly enough to make anyone ask why two shapes existed.

The third was short-circuiting. Our pipeline skips rules and network validation whenever structural validation reports an error. Two of the validator's three defects were errors, so they did more than add noise: they suppressed every real check behind them. One false error, and no analysis at all. If your validation pipeline has stages, find out which failures silence the later ones.

What actually caught it

A fixture built from the published spec repository at the tag, cross-checked against source/schemas/, rather than from our own samples or from the release notes.

The method turned out to matter more than I expected. Across this work, suspicions taken from the changelog were overturned five times by reading the published schemas or exercising the running code, and four of the six items on my original checklist did not survive contact with the real fixture. Two of them:

We hard-errored when identity linking omitted config.supported_mechanisms. Grepping source/ and docs/ at all three published tags returns zero hits for that field. We had invented it.
We warned that EdDSA was an unsupported signing algorithm. The spec lists it as well-known, recommends Ed25519 for Web Bot Auth interop, and says verifiers MUST tolerate algorithms they do not recognise. We replaced the closed-set check with a rule the spec does state as a MUST, that alg must agree with a well-known crv, so a real check took the place of the wrong one instead of leaving a gap.

Grep could not have found the worst cases either. Three surfaces declared version strings that are not UCP releases at all: 2026-01-14, 2026-01-15, and a generator stamping today's date. The real releases are 2026-01-11, 2026-01-23, 2026-04-08 and 2026-08-25, so a search for known versions matches none of those three. Reading the files and validating what they produced did.

Fix 1: one assembler, and versions as data

All six builders now call one pure, isomorphic module, and it is the only thing that knows how a profile is laid out:

export function assembleProfile(parts: ProfileParts): UcpProfile {
  const ucpVersion = parts.ucpVersion || CURRENT_UCP_VERSION;
  const defaults = ucpProfileDefaultsFor(ucpVersion);
  // ... shape services, capabilities and payment handlers per `defaults.shape`
}

The per-version facts sit in a data table rather than in branches scattered through the builder:

'2026-01-11': {
  shape: 'legacy',
  keysField: 'signing_keys',
  paymentHandlersAt: 'root.payment',
  urls: { /* the unversioned URLs that tag really specified */ },
},
'2026-04-08': {
  shape: 'map',
  keysField: 'signing_keys',
  paymentHandlersAt: 'ucp.payment_handlers',
  urls: { /* version-scoped paths */ },
},

Two decisions there are load-bearing. The generator is version-aware rather than version-bumped: ask for 2026-01-11 and you get the legacy shape, because profile_schema.json at that tag really does define root payment. The old output was correct for its own version. And the next spec release becomes an entry in a table instead of a rewrite.

Re-versioning six builders in place would have produced the same output and set up a seventh divergence later. Collapsing them was the fix.

Fix 2: guards that fail the next time

Self-validation on its own would not have been enough. The WooCommerce guide's stale snippet nearly passed our validator, because the validator and the content shared the same wrong model. So the guards look for disagreement with an external source, and for disagreement between our own surfaces:

own-surfaces-validate.test.ts requires that what we publish passes what we sell. Our /.well-known/ucp has to declare a real, current version and validate with zero errors.
tools-shape-alignment.test.ts runs identical input through every builder and requires one answer.
plugin-zip.test.ts checks that the plugin declares nothing it cannot honour.
npm-publish-drift.yml fails CI when package.json is ahead of the registry. It caught its own case on day one.

The outcome

Our own AI Agent Test went from F/25 to D/62, entirely by removing false negatives. Every generated profile now points at schema URLs that resolve. We published npm 2.1.0 after five weeks of unpublished fixes, moved the Shopify app off its March build, and shipped version 1.2.0 of the WordPress plugin.

We checked legacy profiles explicitly and they still validate clean. Merchants on the old shape were not asked to do anything.

Three things to take away

Count your builders before you plan a migration. If the same artifact is constructed in more than one place, the spec bump is a refactor, and the duplication is what will make you miss it.
A fixture from your own output tests nothing. Build it from the published spec, at the tag, and record where it came from. Ours ships with a PROVENANCE.md.
Audit artifacts rather than identifiers. A per-surface audit finds only the surfaces you point it at, and a grep for version strings finds only the versions you already know. The two worst offenders here declared versions that were never released.

None of this was hard once it was visible. It stayed invisible for five months because every individual piece looked fine and nothing in the system was ever required to compare them.

You can check a profile against v2026-08-25 with the free validator at ucptools.dev, or run it in CI with the UCP validate GitHub Action. If you are migrating from an older version, the silent breaking changes in v2026-08-25 is the companion piece to this one.

UCP v2026-08-25 Breaks Quietly: 4 Changes That Still Pass Validation

Peter — Sat, 29 Aug 2026 12:58:57 +0000

On August 25, 2026, the Universal Commerce Protocol shipped v2026-08-25. It is the first
new spec version in four and a half months, and it is a big one: a multi-vertical refactor
laying groundwork for Food and Lodging, grocery and location capabilities, 3D Secure via a
new Actions primitive, split payments and installment terms, a loyalty extension, and Web
Bot Auth interop.

The release notes carry a clearly labelled "Breaking Changes" section. Good.

The problem is that the most dangerous changes in it are not the ones that break loudly.
They are the ones where your profile still parses, still validates against a naive checker,
and agents quietly stop working.

I know, because our own validator got this exactly wrong. More on that below.

Why this release breaks quietly

Look at source/schemas/profile.json at tag v2026-08-25. The base definition ends like this:

{
  "type": "object",
  "required": ["ucp"],
  "properties": {
    "ucp": { "$ref": "ucp.json#/$defs/base" },
    "keys": {
      "type": "array",
      "items": { "$ref": "#/$defs/jwk_public_key" }
    }
  },
  "additionalProperties": true
}

Two things matter here.

required is ["ucp"] and nothing else. And additionalProperties is true.

That combination means a profile carrying removed fields is not invalid. It parses. It
validates. It just contains members that nothing reads any more. When a spec renames a field
under additionalProperties: true, the old name does not become an error. It becomes
decoration.

That is the failure mode to hunt for in this release. Not "my profile is rejected" but "my
profile is accepted and ignored".

Silent breaker 1: `signing_keys` became `keys`

This is the big one, and it is the cleanest example of the pattern.

Before v2026-08-25, a profile published its signing keys in a root-level signing_keys
array. As of this release, signing_keys is gone from profile.json entirely and keys
is the sole canonical field. The schema is blunt about it:

When a profile publishes signing keys, they MUST appear here; this is where every UCP
verifier reads them.

So:

// Before - v2026-04-08
{
  "ucp": { "version": "2026-04-08", "...": "..." },
  "signing_keys": [
    { "kty": "EC", "kid": "key-1", "crv": "P-256", "x": "...", "y": "..." }
  ]
}

// After - v2026-08-25
{
  "ucp": { "version": "2026-08-25", "...": "..." },
  "keys": [
    { "kty": "EC", "kid": "key-1", "crv": "P-256", "x": "...", "y": "..." }
  ]
}

The array contents do not change. It is the same JWK Set under a different name.

Now put that next to additionalProperties: true. If you bump your version to
2026-08-25 and leave signing_keys where it is, your profile is still schema-valid.
Nothing rejects it. But no verifier looks at signing_keys any more, so signature
verification fails against a profile in which nothing looks wrong. You will be debugging
your signing code, not your field names.

The fix is a rename. The hard part is knowing you need it.

We got this wrong in the opposite direction

Worth being straight about this, because it is the same trap from the other side.

Our validator hard-required signing_keys and had no concept of keys at all. So when the
spec moved, we started emitting a hard error on profiles that were correctly migrated. A
merchant who did the right thing got told their profile was broken.

It got worse. Our pipeline skips rules and network validation whenever structural validation
reports an error. So the bogus error did not just add noise, it suppressed every real check
behind it. One false error, and no actual analysis.

We shipped the fix on August 29. Both spellings are now accepted, keys is treated as
canonical from 2026-08-25, and a leftover signing_keys on a new-version profile raises a
warning that tells you it will be ignored rather than an error claiming it is invalid.

The lesson generalises past our bug: a validator that hard-codes a field name is a
validator that will eventually fail correct input. If you have written any internal UCP
checking, go look at how it resolves keys today.

Silent breaker 2: fulfillment config lost its `allows_` prefix and changed shape

The file was renamed from merchant_fulfillment_config.json to
business_fulfillment_config.json, and two properties were renamed. But this is not just a
rename, and that is what makes it dangerous. multi_destination also changed type.

// Before - v2026-04-08: a map of method -> boolean
"allows_multi_destination": {
  "shipping": true,
  "pickup": false
}

// After - v2026-08-25: an array of objects, listing = permitting
"multi_destination": [
  { "method": "shipping" }
]

Now trace what happens if you skip this migration. The old schema set
additionalProperties: false, so a stray key there used to be a hard error. The new
business_fulfillment_config does not, so allows_multi_destination is now simply an
unrecognised member that nothing reads. And the new field's own rule is explicit:

Listing a method permits it; an omitted method does not.

So your untouched config does not fail. It resolves to an empty permission set. You silently
stop allowing split shipping across addresses, and nothing anywhere says so. That is a
capability you believe you advertise quietly turning off.

method_combinations kept its array-of-arrays shape, but its enum restriction to
["shipping", "pickup"] was removed in favour of an open vocabulary with those as
well-known values. That one is a loosening, so it will not break you.

While you are in these files: fulfillment_option.description was upgraded from a flat
string to a structured object (it now $refs common/types/description.json). That one
does change type on a required-ish field, so it is more likely to fail loudly, which
honestly makes it the safer of the two.

Silent breaker 3: buyer consent went from booleans to a reverse-DNS map

This one changes shape rather than just names.

// Before - v2026-04-08: four fixed booleans
"consent": {
  "analytics": true,
  "marketing": false,
  "preferences": true,
  "sale_of_data": false
}

In v2026-08-25, consent is a dynamic map keyed by reverse-DNS identifiers, where each
purpose is an object requiring granted, source, and description:

// After - v2026-08-25
"consent": {
  "dev.ucp.consent.marketing": {
    "granted": false,
    "source": "platform",
    "description": "Promotional communications across all channels",
    "segments": {
      "dev.ucp.consent.marketing.email": {
        "granted": true,
        "source": "platform",
        "description": "Email marketing only"
      }
    }
  }
}

The source field is the interesting addition: it distinguishes a business default
("business") from an explicit buyer decision captured by the platform ("platform"). If
you are handling consent for compliance reasons, that distinction is probably one you have
been reconstructing by hand. Now it is in the protocol. Segments let you scope a decision to
a channel without inventing your own convention, and UCP predefines
dev.ucp.consent.marketing.email and .sms.

Silent breaker 4: payment extensions moved namespace

Payment extensions migrated out of the shopping vertical:

dev.ucp.shopping.split_payments becomes dev.ucp.common.payment.split_payments
the same move applies to payment_terms and ap2_mandates

Related, and easy to miss: shared primitive schemas (amount.json, price.json,
line_item.json) moved under common/types/, which changes their $id URLs. If you
pin, cache, or fetch those schemas by URL anywhere, those references are now stale.

This is the change most likely to bite tooling rather than merchants. Anything that walks
capability extension chains by prefix will read migrated extensions as orphaned.

The migration checklist

Rename signing_keys to keys at the profile root. Delete the old key. Do not keep both - two sources of truth for signing keys drifting apart is precisely the failure this change was made to eliminate.
Move to business_fulfillment_config.json, drop the allows_ prefix, and convert multi_destination from a method-keyed boolean map to an array of { "method": "..." } objects. Do not just rename it - an unconverted map reads as "nothing permitted".
Convert fulfillment_option.description from a flat string to the structured common/types/description.json object.
Restructure buyer consent into the reverse-DNS map with granted / source / description.
Repoint payment extensions to dev.ucp.common.payment.*.
Update any pinned $id URLs for amount, price, and line_item to common/types/.
Bump version to 2026-08-25 last, after the above. The version field is the part agents read to decide how to interpret everything else.

Then re-validate. And validate with something that actually knows about 2026-08-25 - a
checker still targeting an older version will happily tell you a half-migrated profile is
fine.

The broader point

Date-based protocol versions make it easy to think of a spec bump as a number you increment.
This release is a good argument against that. The changes that will cost you time are not in
the "Breaking Changes" heading you read once. They are in the gap between "my JSON is valid"
and "an agent can actually transact with me", and additionalProperties: true is exactly
where that gap lives.

If you maintain UCP tooling, the practical takeaway is narrower: stop hard-coding field
names, and make your validator report which layout it detected rather than silently
assuming one.

UCP is an open standard co-developed by Google and Shopify. UCPtools is an independent
community tool and is not affiliated with either company. Every schema detail above was read
from the published specification at tag v2026-08-25 in the
Universal-Commerce-Protocol/ucp
repository, not from the release notes.

You can check a profile against v2026-08-25 with the free validator at
ucptools.dev, or run it in CI with the
UCP validate GitHub Action.

Is Your UCP Validator Lying to You About Cart and Catalog?

Peter — Wed, 29 Jul 2026 10:06:16 +0000

Is Your UCP Validator Lying to You About Cart and Catalog?

You ran validation. Your store got a "FAIL" on Cart and Catalog capabilities. The report says your catalog endpoint returns an invalid response shape. You spend an afternoon debugging endpoints that look fine when you test them manually.

The problem isn't your store. It's your validator. Here's why.

The draft-spec trap nobody talks about

The Universal Commerce Protocol isn't static. As of the April 2026 release:

Identity Linking is stable. The spec is finalized. Agents expect a specific response shape, and that shape won't change without a new protocol version.
Cart and Catalog are draft. The endpoints exist and work. Agents interact with them in production. But the schema, response shapes, and exact field names are still evolving. The spec explicitly says they "MAY version independently when breaking changes are required."

When a validator doesn't distinguish between stable and draft capabilities, here's what happens:

Your Catalog endpoint returns products correctly. An AI agent asks "show me hiking boots under $200" and your store responds with actual products. But the response includes an optional metadata field that the draft spec didn't mention six months ago, or it nests variant data differently than the current draft expects.

A spec-unaware validator flags this mismatch as a failure. Hard stop. Red X. "Catalog validation failed."

The agent, meanwhile, browses your catalog just fine. It reads the products that matter, ignores the extra fields, and builds a cart. Your store works in practice. But your validator says it doesn't.

What a hard-fail actually costs you

False negatives aren't just annoying - they steer you toward the wrong work.

When your validator says Cart validation failed, you investigate. You compare your endpoint response to the draft schema. You spend hours figuring out whether the mismatch is on your side or the spec's. You might even modify your endpoint to match a draft schema that changes next month.

Meanwhile, the actual problems - signing keys that rotated, a CDN that changed how it serves .well-known/ucp, payment handlers referencing an old gateway endpoint - go unnoticed. These are genuine, production-breaking failures that get buried under draft-spec noise.

The validator that flags everything with equal severity trains you to ignore all of it.

The fix: draft-aware validation

As of July 2026, UCPtools handles draft capabilities differently:

Stable spec requirements: checked as before. If your Cart endpoint returns a 4xx, if your Catalog doesn't serve JSON, if a required stable-spec field is missing - those are real failures.
Draft-spec mismatches: produce warnings, not failures. If your response shape doesn't match the current draft schema, you get a clear warning explaining what's different - not a red X that blocks everything else.

You still see the mismatch. You still know something changed. But you're not punished for a moving target.

Three things to check in your current validation workflow

1. Does your tool report spec status for each capability?

If every failure looks the same - same severity, same color, same urgency - you can't tell a broken endpoint from a draft-spec evolution.

2. Does a Cart/Catalog failure block your entire validation run?

A genuine signing_keys failure and a draft-spec Catalog warning are not the same problem. If your tool treats them identically, you're spending time on the wrong one.

3. When was your tool last updated against the current UCP spec?

The April 2026 update was the largest spec release since January. If your validator hasn't been updated since then, it's validating against a version of the protocol that no longer reflects what agents expect.

The spec is moving. Your validation should move with it.

Google shipped the April 2026 update with Cart, Catalog, and Signals. Shopify Editions Spring '26 made UCP the default on every store. The protocol is in active development - and that's a good thing. It means agentic commerce is real enough that the spec keeps improving.

But point-in-time validation tools that don't distinguish between draft and stable create more noise than signal. You end up debugging spec evolution instead of fixing what actually breaks agent interactions.

Check if your validation handles draft specs correctly: Validate your UCP profile - free, no account needed.

Running validation across multiple domains? Start a free 7-day trial for monitoring and multi-domain dashboards. No credit card required.

ChatGPT Can Shop Now. Is Your Store Ready to Sell to It?

Peter — Mon, 20 Jul 2026 10:05:06 +0000

ChatGPT Can Shop Now. Is Your Store Ready to Sell to It?

OpenAI shipped the Agentic Commerce Protocol (ACP) and ChatGPT's shopping agent is live. Target, Sephora, Nordstrom, Best Buy, and Home Depot are already integrated. When a user asks ChatGPT to find them a product, those stores show up.

If your store isn't ACP-visible, ChatGPT users can't find you. Period.

Here's the thing most e-commerce developers don't realize: your store might already be ACP-compatible and you just haven't checked. If you're on Shopify with Stripe, HTTPS, and proper policy pages, you could be one product feed away from ChatGPT discoverability.

What ACP Actually Checks

ACP is the open standard (Apache 2.0) that OpenAI and Stripe built for AI commerce. It's not proprietary and it's not Stripe-only - Adyen shipped "Adyen Agentic" and PayPal announced ACP support for 2026.

The protocol checks four things on your store:

Platform (25 pts) - Shopify/Etsy auto-eligible path, or custom integration needed
Payment infrastructure (30 pts) - Stripe is the easiest path (Shared Payment Token), but seller-backed instruments (gift cards, store credit) also work
Policy pages (25 pts) - Terms, privacy, and return policy are required by spec. Agents need these.
Security (20 pts) - HTTPS with modern TLS. Hard requirement.

You get a 0-100 score with letter grades (A through F) and finding codes for every failure - not "you failed," but exactly what to fix.

ACP vs UCP: Don't Confuse Them

Two protocols, two AI agent ecosystems:

Protocol	ACP (OpenAI + Stripe)	UCP (Google + Shopify)
Primary agents	ChatGPT	Google AI Mode, Gemini, Copilot
Discovery	`/.well-known/acp.json` + product feed	`/.well-known/ucp` manifest
Checkout	Stripe delegated tokens or merchant app	Merchant-hosted endpoints
Focus	Payment + discovery	Full commerce (browse, cart, checkout)

Microsoft Copilot already consumes both. checkout.com data shows dual-protocol stores capture 40% more agentic traffic. The recommendation for 2026: implement both if you can. But start by checking what you already have.

The March 2026 Pivot (And Why ACP Matters More, Not Less)

OpenAI deprioritized in-ChatGPT checkout in March 2026. Users browsed but didn't buy in-chat. Purchases moved to merchant storefronts.

But here's what most people missed: the ACP spec had its biggest release after that pivot. April 17, 2026 brought public product feeds, Cart capability, delegate authentication with 3DS2, and mandatory idempotency keys.

The takeaway: ACP now governs discovery inside ChatGPT. If your products aren't ACP-surfaced, ChatGPT users never see them. The purchase completes on your site, but the discovery happens inside the agent. And discovery requires ACP readiness.

The Numbers

McKinsey: up to $1T in US agentic commerce by 2030
Morgan Stanley: 126M AI shopping-agent users by 2030
Shopify: 13x YoY growth in AI search orders

The retailers showing up today didn't wait. They integrated early. Every week your store isn't checked is a week ChatGPT users buy from someone else.

Test It in 30 Seconds

I built a free ACP Readiness Checker that scans your domain and gives you a 0-100 score across all four categories. No account required.

Run the ACP check on your store →

If you score A, you're ChatGPT-ready. If not, you get specific finding codes and fix recommendations for every failing category.

Your products should show up wherever customers shop. In 2026, that includes ChatGPT.

Also published on ucptools.dev

Run UCP + ACP Validation in Your CI/CD Pipeline

Peter — Fri, 10 Jul 2026 05:26:39 +0000

You deploy a change to your storefront. The JSON still parses. The linter is happy. Tests pass.

Two weeks later you notice AI agents have been silently skipping your store, because a capability schema endpoint started returning a 404 and nothing anywhere told you.

This is the failure mode of agentic commerce readiness: it degrades quietly. There is no 500 page, no error rate spike, no angry customer email. Agents just move on to a merchant whose profile resolves.

The fix is the same as for every other class of quality problem in software. Stop checking it by hand. Put it in CI.

What actually breaks

UCP profiles are not simple documents. They carry namespace bindings, HTTPS requirements, signing keys, and extension chains that reference capabilities elsewhere in the file. A profile can be perfectly valid JSON and still be broken in ways that matter:

UCP_NS_ORIGIN_MISMATCH - your declared namespace does not match the origin serving it
UCP_ENDPOINT_NOT_HTTPS - agents require HTTPS, without exception
UCP_MISSING_SIGNING_KEYS - required before order and fulfillment capabilities will be trusted
UCP_SCHEMA_FETCH_FAILED - a capability schema URL returns an error
UCP_ORPHANED_EXTENSION - an extension points at a capability that no longer exists

Every one of these survives JSON.parse(). Every one of these makes you invisible to some agent. And the last two are exactly the kind of thing a refactor breaks without touching the profile file at all, because the breakage lives at the other end of a URL.

That is the argument for CI. Not "validate once at launch" - validate on every push, against the environment you are about to ship.

The GitHub Action

If you are on GitHub, this is four lines of YAML:

- uses: Nolpak14/ucp-validate-action@v1
  with:
    domain: 'yourstore.com'
    fail-on-grade: 'C'

The action runs four-level validation (structural, rules, network, SDK compliance) against the live domain and scores AI readiness. fail-on-grade fails the build at that grade or worse; fail-on-score does the same against a 0-100 number. Use whichever matches how your team talks about quality.

It exposes score, grade, ucp-found, passed, and result-json as outputs, so you can branch on the result rather than just pass or fail:

- uses: Nolpak14/ucp-validate-action@v1
  id: ucp
  with:
    domain: 'yourstore.com'

- run: echo "UCP score: ${{ steps.ucp.outputs.score }}"

- if: steps.ucp.outputs.ucp-found == 'false'
  run: echo "::warning::No UCP profile at /.well-known/ucp"

On pull requests it posts a comment with the score, a category breakdown, and any validation issues with their error codes, updating in place rather than piling up duplicates. Set comment: 'false' if you would rather have step summaries only.

The pattern that actually pays: gate the deploy

Validating on push is useful. Gating the deploy on it is what stops a broken profile reaching production:

name: Deploy
on:
  push:
    branches: [main]

jobs:
  validate-ucp:
    runs-on: ubuntu-latest
    steps:
      - uses: Nolpak14/ucp-validate-action@v1
        with:
          domain: 'staging.yourstore.com'
          fail-on-grade: 'C'

  deploy:
    needs: validate-ucp   # deploy only runs if validation passed
    runs-on: ubuntu-latest
    steps:
      - run: echo "Deploying to production..."

Point it at staging. If staging's profile does not clear your bar, the deploy job never runs. You catch the regression before customers see it, and before agents quietly reroute around you.

Not on GitHub? Use the CLI

The validator ships as an npm package, so it drops into any runner with Node.js 20+. It exits non-zero when validation fails, which is all a CI system needs.

GitLab CI:

ucp-validation:
  image: node:20-alpine
  script:
    - npx -p @ucptools/validator ucp-validate validate --remote yourstore.com
  rules:
    - if: $CI_COMMIT_BRANCH == "main"

CircleCI:

jobs:
  ucp-validation:
    docker:
      - image: cimg/node:20.11
    steps:
      - run:
          name: Validate UCP profile
          command: npx -p @ucptools/validator ucp-validate validate --remote yourstore.com

Or wire it into your test suite so it runs wherever your tests already run - Jenkins, Bitbucket Pipelines, a Makefile, a pre-commit hook:

npm install --save-dev @ucptools/validator

{
  "scripts": {
    "test:ucp": "ucp-validate validate --remote yourstore.com"
  }
}

You can also validate the file before it ever ships, which is faster and catches structural errors without a network round trip:

npx -p @ucptools/validator ucp-validate validate --file ./public/.well-known/ucp

The other protocol: ACP readiness

UCP is not the only spec agents care about. The Agentic Commerce Protocol - OpenAI and Stripe's standard, the one behind checkout inside ChatGPT - has its own readiness surface: platform detection, payment integration, policy endpoints, security posture.

Worth being precise about how this runs, because it is different: the GitHub Action and the CLI check UCP. ACP readiness is a public REST endpoint. No key, no install, so it works in any CI that has curl and jq.

curl -sX POST https://ucptools.dev/api/acp-check \
  -H 'Content-Type: application/json' \
  -d '{"domain":"yourstore.com"}' > acp.json

SCORE=$(jq -r '.score' acp.json)
GRADE=$(jq -r '.grade' acp.json)
echo "ACP readiness: $GRADE ($SCORE/100)"

[ "$SCORE" -ge 70 ] || {
  jq -r '.recommendations[]? | "[\(.priority)] \(.title) - \(.action)"' acp.json
  exit 1
}

One trap worth knowing: the endpoint answers 200 OK even when a domain fails, with "ok": false in the body. A reflexive curl --fail gate would pass every grade, including an F. Read .score or .grade from the response, not the HTTP status.

The response also carries score_breakdown across platform, payment, policies, and security, plus recommendations as structured objects with priority, title, description, and action - which is why the snippet above prints something a developer can act on rather than a wall of JSON.

Where to set the bar

Resist the urge to start at fail-on-grade: 'A'. You will spend a week fighting your own pipeline and then disable the check, which is worse than never adding it.

Start where you are. Run the validator once, take the grade it gives you, and set the threshold one notch below. Now the build fails only on regression, which is the thing you actually care about. Ratchet the bar upward as you fix the backlog. A gate that fires on real regressions and stays quiet otherwise is a gate people keep.

For ACP, 70 is a reasonable opening threshold. For UCP, fail-on-grade: 'C' catches the profile-level breakage without blocking on Schema.org polish.

Getting started

Add the action, or the npx one-liner, to a workflow you already run
Point it at staging, not production
Set a threshold one notch below your current grade
Add the ACP curl step if you care about ChatGPT checkout
Make the deploy job needs: the validation job

Copy-paste recipes for GitHub Actions, GitLab CI, CircleCI, npx, and the ACP endpoint live at ucptools.dev/ci. If you would rather call validation from your own code than from a CI step, the API and npm reference covers the public REST endpoints and the typed package.

The point is not the score. The point is that a profile which silently stopped resolving should break your build, not your revenue.

UCPtools is an independent community tool. UCP is an open standard by Google and Shopify; ACP is an open standard by OpenAI and Stripe. We are not affiliated with any of them.

The Agentic Commerce Stack Is Complete - Here's Your July 2026 Implementation Checklist

Peter — Mon, 06 Jul 2026 10:07:25 +0000

The Agentic Commerce Stack Is Complete - Here's Your July 2026 Implementation Checklist

Three infrastructure changes in the last 30 days turned agentic commerce from a spec to a live channel:

Mastercard backed UCP. Their Agent Pay network now runs on Google's Universal Commerce Protocol. The payment layer converged on the discovery layer.
Shopify shipped Agentic Storefronts in Summer '26 Editions. Every Shopify merchant now has an AI shopping channel, active by default, manageable from the admin.
Google AI Mode is in production. Gemini browses stores via UCP. ChatGPT shops through Shopify's agentic storefronts.

The stack is live: Discovery (Google AI Mode, Gemini, ChatGPT) + Storefront (Shopify, BigCommerce) + Payment (Mastercard Agent Pay, Visa Intelligent Commerce, Adyen Agentic).

If your store doesn't have a valid UCP profile, you are invisible to every layer. Not "less visible." Invisible. The agents read protocols, not websites.

Here's the 5-item checklist to fix that. Each step takes 10-30 minutes.

1. Validate at All 4 Levels

A structural JSON check tells you the manifest parses. It doesn't tell you whether an AI agent can actually shop.

You need all four:

Structural - valid JSON, required fields, schema compliance
Rules - capability consistency, namespace/origin match, business logic
Network - HTTPS on all endpoints, live response codes, reachability
SDK/Simulation - end-to-end agent interaction (browse, cart, checkout, pay)

Most free checkers stop at Level 1. The failures that make your store invisible live at Levels 3 and 4.

Run a free 4-level validation

2. Run the AI Agent Simulator

Validation says your manifest is correct. Simulation says whether an agent can actually use it.

The simulator sends real agent-style requests: browse catalog, add to cart, initiate checkout. Failures it catches that validators miss:

Payment handlers declared but unreachable (302 redirect, CORS block)
Identity Linking endpoints that return 200 but fail cross-domain
Cart where add works but remove doesn't
Signing keys present but cryptographically invalid

Run the AI agent simulator

3. Fix the Top 3 Failures

Production scan data shows three issues cause most agent-visible failures:

Missing signing_keys - Without them, agents can't verify your manifest. They walk. This is the single most common failure.

Namespace/origin mismatch - Your manifest says origin: "store.example.com" but the agent requested from www.store.example.com. The agent sees a contradiction and aborts.

Broken payment_handlers - The manifest declares checkout but doesn't tell agents what payment methods exist, or lists handlers that don't work. Cart fills, purchase fails.

4. Set Up Monitoring

Your UCP profile will break. Not because you made a mistake - because infrastructure changes:

TLS certs rotate and the new CA isn't trusted
Your platform ships an update that changes the manifest shape
Payment gateway config drifts from what the manifest declares
A caching plugin starts serving /.well-known/ucp as text/html

When this happens, you won't get an error. You'll just stop appearing in AI shopping results. Silent, invisible failure.

Monitoring re-validates on a schedule, compares to baseline, and alerts on regression. Same principle as uptime monitoring - but for AI agent discoverability.

Set up monitoring

5. Test All Three Layers

The stack works as a chain. Break any link and it fails:

Discovery - Can Google AI Mode find your store? Search your products in AI Mode.
Storefront - Is your Shopify Agentic Storefront active? Check admin under Sales Channels.
Payment - Can Mastercard Agent Pay process a payment through your store? Test the handler endpoints.

Why This Matters

Shopify reported 13x year-over-year growth in AI search orders before Agentic Storefronts shipped. Cloudflare reports bots have surpassed human traffic. McKinsey projects up to $1T in US agentic commerce by 2030.

The protocol war is effectively settled. UCP has the discovery layer, the storefront layer, and now the payment layer. Implementing it isn't a competitive advantage - it's table stakes.

Five steps. One afternoon. The difference between being visible to the agentic commerce stack and being invisible to it.

Start your free validation - no account required.

Building a Dual-Protocol Checkout with Agorio SDK: Support UCP and ACP in Your AI Commerce Agent

Peter — Fri, 26 Jun 2026 15:53:12 +0000

Building a Dual-Protocol Checkout with Agorio SDK: Support UCP and ACP in Your AI Commerce Agent

The AI commerce landscape is rapidly standardizing around two open protocols: Google's Universal Commerce Protocol (UCP) and OpenAI's Agentic Commerce Protocol (ACP). By holiday 2026, Visa and Mastercard will enable all US cardholders for agent transactions, while Shopify's 4.8M merchants are discoverable via UCP and Stripe's 1.5M merchants can accept ACP payments with one line of code.

For developers building AI shopping agents, this creates a critical challenge: should you implement UCP, ACP, or both?

In this step-by-step tutorial, you'll learn how to build a dual-protocol checkout system using the Agorio SDK — the only open-source toolkit that supports both UCP and ACP with auto-detection. We'll walk through setting up a TypeScript project, discovering merchants via UCP, managing checkout sessions via ACP, and assembling a full-featured shopping agent.

Why Dual-Protocol Support Matters

UCP and ACP solve different problems:

Protocol	Lead Developers	Primary Use Case	Discovery Method	Payment Model
UCP	Google, Shopify, 25+ partners	Full commerce lifecycle (discovery, cart, checkout, order tracking)	Decentralized (`/.well-known/ucp`)	Multiple handlers (Google Pay, Shop Pay, tokenization)
ACP	OpenAI, Stripe	Checkout-focused, delegated payment	Centralized (merchant application)	Any PSP via delegated payment (Stripe first)

Merchants are adopting both. If your agent only supports one protocol, you'll miss transactions on the other. The smart solution: support both, but avoid writing twice the code.

What Agorio Provides

Agorio abstracts the protocol differences behind a unified API:

UcpClient – Discovers merchants via /.well-known/ucp, normalizes capability formats, handles REST/MCP/A2A transports.
AcpClient – Manages ACP checkout sessions (create, get, update, complete, cancel) with Bearer auth and request tracing.
ShoppingAgent – 17 built‑in tools that work across both protocols via automatic detection.
MockMerchant – A full UCP‑compliant test server, plus ACP‑only and MCP‑only variants.
LLM adapters – Gemini, Claude, OpenAI, Ollama — swap without changing your agent logic.

With Agorio, you write commerce logic once; the SDK adapts to the merchant's supported protocol.

Step 1: Project Setup

Start a new TypeScript project and install Agorio:

npm init -y
npm install typescript ts-node @types/node --save-dev
npm install @agorio/sdk

Create a tsconfig.json:

{
  "compilerOptions": {
    "target": "ES2022",
    "module": "NodeNext",
    "moduleResolution": "NodeNext",
    "esModuleInterop": true,
    "outDir": "./dist",
    "strict": true
  }
}

Step 2: Discover a Merchant via UCP

First, let's discover a merchant's capabilities using the UcpClient. The client automatically fetches the /.well-known/ucp manifest and normalizes the capability format.

import { UcpClient } from '@agorio/sdk';

const client = new UcpClient();

async function discoverMerchant(domain: string) {
  try {
    const result = await client.discover(domain);
    console.log(`Merchant ${domain} supports:`);
    result.capabilities.forEach(cap => {
      console.log(`  - ${cap.name} (${cap.version})`);
    });
    return result;
  } catch (error) {
    console.error(`Discovery failed:`, error);
    return null;
  }
}

// Example: discover a UCP-enabled merchant
await discoverMerchant('shop.example.com');

The result object contains normalized services, payment handlers, and transport bindings. You can now invoke any UCP capability (catalog, cart, checkout) using the client's REST or MCP transport.

Step 3: Create an ACP Checkout Session

For merchants that support ACP (like Stripe‑enabled stores), you'll manage checkout sessions via the AcpClient. ACP uses delegated payment: the user's payment method stays with their PSP (Stripe, PayPal), and the agent acts as an operator.

import { AcpClient } from '@agorio/sdk';

const acp = new AcpClient({
  baseUrl: 'https://api.stripe.com/acp/v1', // Replace with merchant's ACP endpoint
  apiKey: process.env.STRIPE_API_KEY!,
});

async function createAcpCheckout(productId: string, quantity: number) {
  const session = await acp.createCheckout({
    lineItems: [{
      productId,
      quantity,
      price: {
        amount: 2999, // $29.99 in minor units (cents)
        currency: 'USD',
      },
    }],
    merchantDomain: 'shop.example.com',
  });

  console.log(`ACP checkout session ${session.id} created`);
  console.log(`Status: ${session.status}`); // "not_ready_for_payment"
  return session;
}

const session = await createAcpCheckout('prod_123', SB_1);

The AcpClient handles all required headers (Authorization, API‑Version, Idempotency‑Key, Request‑Id) and validates responses against the ACP schema.

Step 4: Build a Dual-Protocol Shopping Agent

Now combine both clients into a single ShoppingAgent. The agent automatically detects whether a merchant speaks UCP or ACP and uses the appropriate client.

import { ShoppingAgent, GeminiAdapter } from '@agorio/sdk';

const agent = new ShoppingAgent({
  llm: new GeminiAdapter({ apiKey: process.env.GEMINI_API_KEY! }),
  verbose: true,
  // ShoppingAgent automatically instantiates UcpClient and AcpClient
});

async function runShoppingTask(task: string) {
  const result = await agent.run(task);

  console.log(result.answer);           // Natural language summary
  console.log(result.checkout?.orderId); // Order ID if purchase completed
  console.log(result.usage?.totalTokens); // LLM token usage

  return result;
}

// This single command works for both UCP and ACP merchants:
await runShoppingTask('Go to shop.example.com and buy wireless headphones');

The agent's 17 built‑in tools handle the entire flow: merchant discovery, product search, adding to cart, submitting shipping and payment, and order tracking. You can extend with custom tools via plugins.

Step 5: Test with Mock Merchants

Before hitting real merchants, test with Agorio's mock servers. MockMerchant provides a full UCP‑compliant server; MockAcpMerchant provides an ACP‑only server.

import { MockMerchant, MockAcpMerchant } from '@agorio/sdk';

// Start a UCP merchant
const ucpMerchant = new MockMerchant();
await ucpMerchant.start();
console.log(`UCP mock merchant running at ${ucpMerchant.domain}`);

// Start an ACP merchant
const acpMerchant = new MockAcpMerchant();
await acpMerchant.start();
console.log(`ACP mock merchant running at ${acpMerchant.domain}`);

// Test your agent against the mock
const result = await agent.run(`Go to ${ucpMerchant.domain} and buy a laptop`);
console.log(`Order placed:`, result.checkout?.orderId);

// Clean up
await ucpMerchant.stop();
await acpMerchant.stop();

Both mocks simulate realistic latency, support configurable error rates for chaos testing, and provide structured product catalogs (10 products by default).

Step 6: Deployment Considerations

When moving to production, keep these points in mind:

LLM cost control – Set maxIterations in AgentOptions to limit agent loops.
Observability – Use the onLog callback to stream logs to your monitoring system, or integrate with Agorio Cloud for full tracing.
Session storage – Swap MemorySessionStorage for FileSessionStorage or @agorio/session-redis in multi‑process deployments.
Idempotency – Always pass idempotencyKey on completeCheckout to prevent duplicate charges.
Compliance – If you handle EU users, enable the built‑in EU AI Act compliance export (GET /api/compliance/export).

Conclusion: Why Agorio is the Right Choice

Building dual‑protocol AI commerce agents from scratch requires deep knowledge of both UCP and ACP specs, plus months of implementation work. Agorio gives you:

Protocol agnosticism – Write once, run on UCP, ACP, or both.
Production‑ready tooling – Mock merchants, LLM adapters, observability, CLI.
Enterprise hardening – RBAC, audit logs, compliance exports, security posture.

The SDK is open‑source (MIT), has zero runtime fees, and already powers agents handling real purchases.

Get started today:

npm: npm install @agorio/sdk
GitHub: github.com/Nolpak14/agorio
Docs: agorio.dev/docs
Playground: agorio.dev/playground

If you're building AI commerce agents, join the 10+ GitHub stars and 46+ weekly npm downloaders who've chosen Agorio as their foundation. Ship your agent in 20 lines, not 20 weeks.

We Tracked Every AI Agent That Visited Our Site. 5 Different Agents Found Us This Month.

Peter — Mon, 22 Jun 2026 10:04:50 +0000

We Tracked Every AI Agent That Visited Our Site. 5 Different Agents Found Us This Month.

Three weeks ago, I noticed something strange in our referrer logs.

A user from chatgpt.com had landed on our validator page, browsed our documentation, and — crucially — triggered tool events. Not a human clicking around. An AI agent. ChatGPT had crawled our site, loaded our tool, and used it.

That was one agent. One week. A curiosity.

This week: five.

What showed up (and what they did)

The full lineup of AI agents that visited ucptools.dev in the last month:

ChatGPT (chatgpt.com) — 4 visits this week alone. Most active of the bunch. Browsed documentation pages and the free UCP validator. Triggered actual tool events — someone asked ChatGPT about UCP validation, and it came to us to answer.

Gemini (gemini.google.com) — 1 visit this week. First time we've seen Gemini in our logs. Shorter session than ChatGPT, but it hit the same pages: validator, compare page, docs.

Perplexity (perplexity.ai) — First spotted in May. Here's the wild part: every Perplexity-referred session in May resulted in a tool user. 100% conversion rate. Someone asked Perplexity "how do I validate my UCP profile?" and Perplexity sent them straight to our tool, already knowing what to do.

Claude (claude.ai) — Returned June 14 after a multi-week gap. Browsed our UCP protocol documentation and the agent simulator page. Not using tools yet — but it's building a map.

NotebookLM (notebooklm.google.com) — Newcomer. Discovered us June 7. Google's research assistant found our site and ingested content. We don't know what question triggered it, but something in our content matched a user's research query.

Trend line: 1 → 1 → 5. Not a spike. A ramp.

This isn't about SEO as you know it

If you work in developer tools or e-commerce infrastructure, you've probably spent the last 6 months hearing about UCP, ACP, AI shopping agents, and "agentic commerce readiness." The conversation has been about protocols — can an AI agent parse your UCP manifest? Can it call your payment handlers? Can it add items to a cart?

That's the protocol layer. And it matters.

But here's what the referral data shows: AI agents are indexing your entire web presence, not just your UCP endpoint.

When ChatGPT crawled our validator tool, it wasn't reading a .well-known/ucp manifest. It was reading our documentation, our compare page, our blog posts. It was building a knowledge graph of "what tool exists for checking UCP profiles" that it can retrieve when a user asks.

When Perplexity sent us a user with a 100% tool completion rate, it had already decided — before the human ever saw our site — that UCPtools was the right answer to their question.

This is a new kind of discoverability. Not search ranking. Knowledge base ranking. The question isn't "do I rank #1 for 'UCP validator'?" — it's "when an AI agent needs to answer a UCP question, does it know I exist?"

What this means for developer tools and e-commerce platforms

Five different agents found us without us doing anything to attract them. No agent-specific SEO. No structured data markup for AI crawlers. Just a website with clear, specific content about a niche protocol.

The implication: AI agents are actively hunting for authoritative sources in specialized domains. If you build something in the UCP/ACP/agentic commerce space, the agents will find you — but only if your content is in their corpus.

Three patterns we can already see:

Agents prefer documentation over marketing. Every agent that visited us hit our docs and tools. None touched our pricing page. None visited our blog homepage. They went straight for substance.
Tool usage is the strongest signal. Perplexity's 100% tool-user rate tells us the agent pre-qualified the user — it already knew our tool was the answer. The human didn't browse; they executed.
Multi-agent coverage compounds. One agent finding you is luck. Five agents finding you means your content is propagating across knowledge bases. ChatGPT, Gemini, Perplexity, Claude, and NotebookLM use different indexes and different retrieval strategies. If you're in all five, you're discoverable regardless of which agent a user chooses.

The protocol layer matters too — here's how they connect

We built UCPtools to validate UCP profiles. The core insight was: an AI shopping agent needs a valid UCP manifest to buy from your store. But the protocol layer and the knowledge layer are connected in ways that aren't obvious yet.

Consider this sequence:

A developer asks ChatGPT: "How do I set up UCP for my Shopify store?"
ChatGPT searches its knowledge base, finds our documentation (because we're in its corpus), and recommends our validator.
The developer uses the free validator, finds 3 broken endpoints, and fixes them.
Now their store is both UCP-valid (protocol layer) AND indexed by the agents that will send them customers (knowledge layer).

Without step 2, the developer might never find the validator. Without step 3, their UCP profile stays broken and AI shopping agents can't transact.

You need both. A valid UCP profile that no AI agent knows about is useless. And an AI agent that knows about your store but can't transact because your payment handlers are broken is equally useless.

How to check if AI agents can find you (and transact with you)

There's no all-in-one dashboard for this yet. But here's what you can do right now:

Check your referrer logs for these domains:

chatgpt.com / chat.openai.com
gemini.google.com
perplexity.ai
claude.ai
notebooklm.google.com

If you see any of them, AI agents are already building knowledge about your site.

Check your UCP profile — because being discoverable is pointless if agents can't transact. Our free validator runs 4 levels of checks: structural, rules, network, and an AI agent simulator that actually tests whether an agent can complete a purchase flow.

Run the free UCP validator →

Check your robots.txt. Most AI crawlers respect robots.txt. If you're blocking GPTBot, ClaudeBot, or Google-Extended, you're opting out of AI discoverability. That might be intentional — but it's worth knowing what you're blocking.

One thing I'm still figuring out

The data is real but the sample is small. Five agents, a handful of visits, one site. This isn't a research paper — it's an observation from our referrer logs that I think matters for anyone building in this space.

What I don't know yet:

How frequently agents re-crawl and refresh their knowledge
Whether agent referral traffic converts differently than organic search
Whether NotebookLM ingestion leads to downstream discoverability in other Google products

If you're seeing AI agents in your own referrer logs, I'd love to compare notes. Drop a comment — especially if you're seeing patterns I haven't mentioned.

The one thing I'm confident about: the agents are here, they're indexing, and they're already making decisions about which tools and services to recommend. The question isn't whether to care about AI discoverability. It's whether you're already invisible.

Google's Universal Cart Is Live. Here's the Checklist to Make Sure Agents Can Actually Check Out on Your Store

Peter — Sat, 13 Jun 2026 13:35:37 +0000

At Google Marketing Live on May 20, 2026, Universal Cart stopped being a demo. Google announced that shoppers can now save products across retailers and check out - with Google Pay or the retailer's own flow - directly inside Search, AI Mode, the Gemini app, and YouTube shopping ads. The launch list is not a pilot: Nike, Sephora, Target, Walmart, Wayfair, and Shopify merchants like Fenty and Steve Madden, with Affirm and Klarna wired in for financing and hotels and food delivery slated next.

The plumbing under all of it is UCP (Universal Commerce Protocol) - the open standard that gives an AI agent a machine-readable entry point to a store at /.well-known/ucp. (Quick disclaimer: UCP is owned and maintained by Google and Shopify. UCPtools, which I work on, is an independent community tool - not affiliated with either.)

Here is the part that matters for everyone not named in that launch list: the agent decides in milliseconds whether your store can transact. There is no "almost." Either your UCP profile answers the questions the agent asks, or the agent moves on to a merchant whose profile does. No bounce shows up in your analytics. You just quietly stop existing in the one shopping surface that is about to matter most.

So this is the readiness checklist. It maps to the four things a validator actually checks, in the order an agent hits them.

Level 1: Structure - does the profile parse at all?

Before anything semantic, the profile has to be a well-formed UCP document served correctly. This is where most "it's there but it doesn't work" failures live.

[ ] /.well-known/ucp returns 200 with Content-Type: application/json - not text/html, not a redirect to a marketing page.
[ ] The root ucp object exists. Missing it is UCP_MISSING_ROOT and the agent has nothing to read.
[ ] A version field is present and formatted YYYY-MM-DD. A stray semver string trips UCP_INVALID_VERSION_FORMAT.
[ ] The JSON is valid - no trailing commas, no CDN error page wrapped around it.

Sounds trivial. It is the single most common break, because the file is served by a platform or a CDN that nobody is watching, and a caching plugin or a security challenge can turn a clean profile into an HTML error page overnight.

Level 2: Rules - is it actually UCP-compliant?

A parseable profile can still be semantically wrong in ways that make an agent distrust it. Level 2 is the UCP compliance layer.

[ ] Namespace and origin match. The namespace your capabilities declare has to bind to the origin serving the profile. A mismatch is UCP_NS_ORIGIN_MISMATCH - a classic copy-paste-from-staging bug.
[ ] Every endpoint is HTTPS, no trailing slash. UCP_ENDPOINT_NOT_HTTPS and UCP_ENDPOINT_TRAILING_SLASH are both hard stops; agents will not POST a payment intent over http:// or to a sloppy URL.
[ ] No orphaned extensions. Every extension has to chain back to a capability that declares it. A dangling one is UCP_ORPHANED_EXTENSION and signals a profile that was hand-edited and never re-validated.
[ ] Signing keys are present. UCP_MISSING_SIGNING_KEYS is the one that quietly kills checkout: without published keys, the agent cannot verify that the offer and the payment handler are really yours. It will browse and then refuse to transact.

That last one is the difference between showing up in Universal Cart's discovery layer and actually completing a purchase in it. Discovery without signing keys gets you window-shopped, not bought.

Level 3: Network - do your references actually resolve?

Your profile points outward - to capability schemas and handler endpoints. Level 3 fetches them, the way an agent would, from outside your network.

[ ] Every referenced capability schema is reachable and self-describing. A schema host that 404s or times out is UCP_SCHEMA_FETCH_FAILED, and it is someone else's outage becoming your broken profile.
[ ] Handler endpoints respond from the public internet, not just from inside your VPC. A check that runs on your own infra can hit a warm cache and report healthy while real agents get a connection error.
[ ] TLS is valid across every edge, not just your origin. Certs renew and propagate unevenly; one stale CDN edge is enough to fail the agent that lands on it.

You cannot fully test Level 3 from a unit test, because the failures are environmental and external. This is the level that needs to be checked against your live domain, from outside.

Level 4: SDK - does it pass the official compliance pass?

The top level runs your profile through @ucp-js/sdk, the official UCP compliance kit. This is the closest a check gets to "would Google's own agent accept this?" - the same library the ecosystem builds against, applied to your live profile. Passing Levels 1 through 3 and failing here usually means a subtle shape mismatch the schema rules did not catch. If you only automate one gate, make it this one, because it is the one that tracks the spec as it evolves.

Run the whole checklist in one call

You do not have to eyeball any of this. UCPtools exposes a remote endpoint that fetches your live profile and runs all four levels server-side, the way an agent sees it:

curl -sS -X POST https://ucptools.dev/v1/profiles/validate-remote \
  -H "Content-Type: application/json" \
  -d '{"domain":"mystore.com"}' | jq

{
  "ok": false,
  "profile_url": "https://mystore.com/.well-known/ucp",
  "score": 72,
  "grade": "C",
  "issues": [
    { "severity": "error", "code": "UCP_MISSING_SIGNING_KEYS",
      "path": "$.ucp", "message": "No signing keys published",
      "hint": "Publish your Ed25519/ES256 public keys so agents can verify offers." }
  ],
  "validated_at": "2026-06-13T10:00:00Z"
}

Wire that same check into CI with the ucp-validate-action so a regression fails the build before it ships:

- uses: Nolpak14/ucp-validate-action@v1
  with:
    domain: 'mystore.com'
    min-score: 90

Where each stack tends to break

The checklist is platform-agnostic - it reads the open standard, not platform internals - but the failure that actually bites you tends to cluster by stack:

Shopify: you are largely along for the ride on what the platform serves at the well-known path, which is good until a platform change shifts the manifest shape under you. Validate after every theme or app change, because you do not control that surface directly.
WooCommerce: the usual culprit is a caching or security plugin that starts serving /.well-known/ucp from cache, behind a challenge, or as text/html. That is a Level 1 break (Content-Type) hiding behind a green admin dashboard.
BigCommerce / headless: a frontend deploy moves a handler endpoint the profile still advertises, and Level 3 starts failing while the storefront looks perfect to a human. Storefront-scope mismatches show up here too.
Custom / self-hosted: signing-key drift. The key rotates in your infra but not in the published profile, and UCP_MISSING_SIGNING_KEYS or a verification failure silently downgrades you from "can transact" to "can only be browsed."

In every case the break is invisible to a human visitor and only shows up when something fetches the live profile from outside and runs the checks. That is the entire argument for validating continuously instead of once.

The thing the launch list quietly proves

The brands Google named did not get into Universal Cart by accident. Someone on each of those teams treated the UCP profile as production infrastructure - versioned, validated, and monitored - not as a one-time SEO chore. That is the whole gap. The standard is open and the endpoint is a static file; nothing stops a mid-sized Shopify or WooCommerce store from being exactly as agent-ready as Nike. What stops most of them is that nobody ever validated past "the file exists."

Universal Cart going live is the forcing function. Agents are transacting now, in surfaces real shoppers already use every day. Run the checklist against your store - validate it free at ucptools.dev - and if it passes, set up monitoring so it stays passing at 3am when a cert renews and no one shipped a thing. The merchants who win this transition treat their UCP profile like uptime, because for agentic checkout, that is exactly what it is.

UCP is an open standard by Google and Shopify. UCPtools is an independent community tool.
Built by Peter at UCPtools.

UCP vs ACP: The Battle of AI Commerce Protocols and How to Build for Both

Peter — Thu, 11 Jun 2026 18:49:04 +0000

The AI commerce agent landscape exploded in early 2026 when both Google's Universal Commerce Protocol (UCP) and OpenAI's Agentic Commerce Protocol (ACP) launched within weeks of each other. If you're building an AI shopping agent, you now face a critical choice: which protocol should you implement? Or should you support both?

In this deep-dive, we'll compare UCP and ACP from an implementer's perspective, examine their architectural trade-offs, and show you how to get started with Agorio - the only open-source SDK that implements both with automatic detection.

The Rise of Agentic Commerce

AI agents that can shop on your behalf are no longer science fiction. With 4.8M Shopify merchants discoverable via UCP and 1.5M Stripe merchants ready for ACP, the infrastructure for autonomous commerce is already in place. Visa and Mastercard are enabling all US cardholders for agent transactions by holiday 2026.

But to tap into this ecosystem, your agent needs to speak the right protocol. Let's look at the two contenders.

UCP: Google & Shopify's Decentralized Approach

The Universal Commerce Protocol is an open standard co-developed by Google, Shopify, Etsy, Wayfair, Target, Walmart and endorsed by Stripe, PayPal, Visa, Mastercard.

Key Architecture

Discovery: Merchants publish a JSON manifest at /.well-known/ucp that tells agents what they support - capabilities, endpoints, payment handlers.
Capabilities: Modular capabilities like dev.ucp.shopping.checkout (cart, tax, session handling), dev.ucp.shopping.order (post-purchase), and extensions for fulfillment, discounts, buyer consent.
Payment Architecture: The "trust triangle" separates business, payment credential provider, and platform. Multiple handler types: Google Pay, Shop Pay, Direct Tokenization, AP2 (autonomous agent mandates).
Transport Bindings: REST (OpenAPI), MCP (OpenRPC for LLM tools), and Agent Card (A2A).

// Example .well-known/ucp manifest
{
  "ucpVersion": "2026-01-11",
  "capabilities": [
    {
      "name": "dev.ucp.shopping.checkout",
      "version": "2026-01-11",
      "restEndpoint": "https://api.example.com/ucp/checkout",
      "paymentHandlers": ["google_pay"]
    }
  ]
}

When to Choose UCP

You need decentralized discovery (any merchant can self-host)
Your agents need rich shopping workflows (cart, catalog, order tracking)
You're building for Google's AI Mode or Gemini
You need multiple payment handler types

ACP: OpenAI & Stripe's Delegated Payment Model

The Agentic Commerce Protocol is an open standard (Apache 2.0) by OpenAI and Stripe, primarily powering ChatGPT Instant Checkout.

Key Architecture

Discovery: Centralized - merchants apply at chatgpt.com/merchants and provide product feeds
Payment Model: Delegated payment - any PSP can implement the spec (Stripe first, PayPal second)
Endpoints: 5 REST endpoints for the full checkout lifecycle: create, get, update, complete, cancel
States: not_ready_for_payment → ready_for_payment → completed (with optional authentication steps)

// Example ACP checkout session flow
POST /checkout_sessions
{
  "line_items": [
    {
      "product_id": "prod_123",
      "amount": 2999, // $29.99 in cents
      "quantity": 1
    }
  ],
  "return_url": "https://example.com/return",
  "success_url": "https://example.com/success"
}

When to Choose ACP

You're building for ChatGPT or other OpenAI-agent ecosystems
You prefer a centralized, vetted merchant pool
Your transactions are single-item purchases (current limitation)
You want delegated payment through any PSP

Head-to-Head Comparison

Feature	UCP	ACP
Developers	Google, Shopify, 25+ partners	OpenAI, Stripe
Discovery	Decentralized (`/.well-known/ucp`)	Centralized (merchant application)
Payment	Multiple handlers (Google Pay, Shop Pay, etc.)	Delegated via any PSP
Extensibility	Namespace-based extensions	RFC-based extensions
Transport	REST, MCP, A2A	REST only
Merchant Footprint	4.8M Shopify merchants + any self-hosted	1.5M Stripe merchants + 35M PayPal (coming)
License	Open spec	Apache 2.0
Current Limitations	Complex capability negotiation	US-only, single-item only

Why Choose? Build Both with Agorio

The reality is that most serious commerce agents will need to support both protocols to reach the maximum number of merchants. That's where Agorio comes in.

Agorio is an open-source TypeScript SDK that implements both UCP and ACP with automatic protocol detection. Here's how you can use it:

Example: UCP Client

import { UcpClient } from '@agorio/sdk';

// Discover merchant capabilities
const ucp = new UcpClient('https://api.example.com');
const profile = await ucp.discover();

// Check if they support checkout
if (profile.supportsCheckout()) {
  const session = await ucp.createCheckoutSession({
    cartId: 'cart_123',
    paymentHandler: 'google_pay'
  });
}

Example: ACP Client

import { AcpClient } from '@agorio/sdk';

const acp = new AcpClient({
  apiKey: 'your_stripe_key',
  merchantId: 'merch_123'
});

const session = await acp.createCheckoutSession({
  lineItems: [{ productId: 'prod_123', amount: 2999, quantity: 1 }]
});

The ShoppingAgent: Auto-Detection Magic

Agorio's ShoppingAgent automatically detects which protocol a merchant supports and uses the appropriate client:

import { ShoppingAgent, GeminiAdapter } from '@agorio/sdk';

const agent = new ShoppingAgent({
  llm: new GeminiAdapter({ apiKey: process.env.GEMINI_API_KEY }),
  verbose: true,
});

// Agent automatically handles protocol detection
const result = await agent.run(
  'Go to store.example.com and buy me wireless headphones'
);

// Works with both UCP and ACP merchants
console.log(`Order placed: ${result.checkout?.orderId}`);

Implementation Complexity Analysis

Implementing UCP from scratch requires:

JSON-LD manifest parsing
Capability intersection algorithm
Payment handler abstraction
Multiple transport bindings

Implementing ACP from scratch requires:

Bearer auth with API versioning
Payment token delegation
Product feed management
Strict state machine adherence

Agorio handles all of this for you, providing:

UcpClient with discovery + REST/MCP auto-transport
AcpClient with full session lifecycle management
ShoppingAgent with 12 built-in tools for commerce workflows
MockMerchant for testing (UCP, ACP, and MCP variants)
LLM adapters for Gemini, Claude, OpenAI, Ollama

Practical Recommendations

Start with ACP if you're building for ChatGPT or want the simplest integration with Stripe/PayPal.
Start with UCP if you need decentralized discovery, multi-item carts, or Google AI Mode integration.
Use Agorio if you want to support both protocols from day one (recommended).

Remember: merchants should support both protocols for maximum AI agent coverage, and so should your agent.

Try It Yourself

The fastest way to experiment is Agorio's interactive playground:

Agorio Playground

Or install the SDK:

npm install @agorio/sdk

Check out the GitHub repository (MIT licensed) and star it if you find it useful.

The Future of Agentic Commerce

Both UCP and ACP are evolving rapidly. UCP's AP2 mandates will enable cryptographic payment authorization for autonomous agents, while ACP is expanding to multi-item purchases and international markets.

The key takeaway: protocol literacy is your moat. Understanding these standards will make you a more effective agent builder, whether you're working on a personal shopping assistant or an enterprise procurement agent.

Have you started building with UCP or ACP? Share your experiences in the comments below!

Build a UCP Watchdog: Catch the Production Breaks Your CI Never Will

Peter — Fri, 05 Jun 2026 14:50:32 +0000

You wired UCP validation into CI. Every push runs the checks, every PR gets a score, and a bad profile fails the build before it merges. Good - that is the right baseline.

Here is what it does not catch: the break that happens when nobody touches the code.

The standard here is UCP (Universal Commerce Protocol) - an open standard that gives AI shopping agents a machine-readable entry point to a store at /.well-known/ucp. (Quick disclaimer: UCP is owned and maintained by Google and Shopify. UCPtools, which I work on, is an independent community tool - not affiliated with either.)

A CI gate is triggered by your commits. But a UCP profile is a live production surface, and most of the things that break it are not commits at all:

A TLS certificate renews and propagates to your origin but not to every CDN edge.
A capability schema host your profile references goes down - someone else's outage, your broken profile.
A CDN or DNS change starts serving a cache page or a redirect at /.well-known/ucp.
Your platform (Shopify, BigCommerce, a WooCommerce plugin update) quietly changes the served manifest or strips the Content-Type: application/json header.
A signing key rotates in your infra but not in the published profile.

None of these trips a build, because there is no build. Your CI is green. Your store works fine for human browsers. The only thing that regressed is the machine-readable layer that no human ever visits - and the AI agent that hits it does not file a bug. It just leaves for the next merchant whose profile answers.

CI catches what you break on merge. A watchdog catches what breaks itself. You need both.

What a Watchdog Actually Watches

A pre-merge gate asks "is the profile I'm about to ship valid?" A watchdog asks a different question on a schedule: "is the profile that is live right now still valid, from outside, the way an agent sees it?"

Two design rules make the difference:

Check from outside your network. A check that runs inside your own infra can hit a warm cache or an internal route and report healthy while external agents get errors. Fetch your public URL over the public internet.
Compare against a baseline, not just against pass/fail. A profile can stay technically valid while its score quietly slides from A to C. Alert on regression from a known-good baseline, not only on hard failures.

Let's build it two ways: a dependency-free cron version, and a GitHub Action with Slack alerts.

The 10-Line Version: cron + curl

UCPtools exposes a public remote-validation endpoint that fetches a live domain's profile and runs the checks server-side. You can hit it from anything that runs curl and jq:

#!/usr/bin/env bash
# ucp-watch.sh - alert if the live UCP profile is broken
DOMAIN="mystore.com"

resp=$(curl -sS -X POST https://ucptools.dev/v1/profiles/validate-remote \
  -H "Content-Type: application/json" \
  -d "{\"domain\":\"$DOMAIN\"}")

ok=$(echo "$resp"     | jq -r '.ok')
errors=$(echo "$resp" | jq -r '[.issues[] | select(.severity=="error")] | length')

if [ "$ok" != "true" ] || [ "$errors" -gt 0 ]; then
  codes=$(echo "$resp" | jq -r '[.issues[] | select(.severity=="error") | .code] | join(", ")')
  curl -sS -X POST "$SLACK_WEBHOOK_URL" -H 'Content-type: application/json' \
    -d "{\"text\":\":rotating_light: UCP profile for $DOMAIN is broken: ${codes}\"}"
fi

The endpoint returns the live result, shaped like this:

{
  "ok": false,
  "profile_url": "https://mystore.com/.well-known/ucp",
  "issues": [
    { "severity": "error", "code": "UCP_SCHEMA_FETCH_FAILED",
      "path": "$.ucp.capabilities[0]", "message": "...", "hint": "..." }
  ],
  "validated_at": "2026-06-05T14:33:57Z"
}

Schedule it and you have a watchdog:

*/15 * * * * SLACK_WEBHOOK_URL=https://hooks.slack.com/... /opt/ucp-watch.sh

Now UCP_SCHEMA_FETCH_FAILED or UCP_ENDPOINT_NOT_HTTPS showing up at 3am - hours after a cert renewal, with no deploy in sight - pages you instead of silently costing you agent traffic.

The GitHub Action Version: scheduled, with a baseline

If your store already lives in GitHub, you can run the same idea on a schedule: trigger and reuse the existing ucp-validate-action - the same action people put in CI - but pointed at your live production domain and run on a clock instead of on push. The difference is entirely in the trigger and what you do with the result.

name: UCP Watchdog
on:
  schedule:
    - cron: '*/30 * * * *'   # every 30 minutes
  workflow_dispatch:          # let me run it by hand too

jobs:
  watch:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - id: ucp
        uses: Nolpak14/ucp-validate-action@v1
        with:
          domain: 'mystore.com'   # your LIVE domain, not staging

      - name: Alert on regression
        env:
          SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }}
        run: |
          score="${{ steps.ucp.outputs.score }}"
          grade="${{ steps.ucp.outputs.grade }}"
          found="${{ steps.ucp.outputs.ucp-found }}"
          baseline=$(cat .ucp-baseline 2>/dev/null || echo 0)

          echo "Live: score=$score grade=$grade found=$found | baseline=$baseline"

          if [ "$found" = "false" ] || [ "$score" -lt "$baseline" ]; then
            curl -sS -X POST "$SLACK_WEBHOOK_URL" -H 'Content-type: application/json' \
              -d "{\"text\":\":rotating_light: UCP regression on mystore.com - score ${score} (grade ${grade}), baseline ${baseline}\"}"
            exit 1
          fi

Commit a one-line baseline file the first time you go green:

echo 90 > .ucp-baseline   # your known-good score

The action exposes score, grade, ucp-found, passed, and result-json, so you can build whatever alerting logic you want on top. The point is that the trigger is a clock, the target is production, and the comparison is against your last known-good state.

Alert Hygiene (so you don't train yourself to ignore it)

A watchdog that cries wolf gets muted, and a muted watchdog is worse than none. Three things keep it honest:

Baseline, don't just pass/fail. A slow slide from grade A to grade C is the regression you most want to know about, and a binary "still valid?" check will miss it entirely. Diff the score.
Debounce flaps. A single failed fetch can be a transient network blip. Require two consecutive bad checks before paging, or alert on a sustained drop rather than one data point.
Bump the baseline when you improve. When you legitimately raise your score, update .ucp-baseline in the same PR. The baseline is a ratchet - it should only move up on purpose.

Platform Notes

The watchdog is platform-agnostic - it reads the open /.well-known/ucp standard, not platform internals - but the regression that pages you tends to differ by stack:

WooCommerce: a caching or security plugin update that starts serving /.well-known/ucp from cache, behind a challenge, or as text/html.
BigCommerce / headless: a frontend deploy or app change that moves an endpoint the profile still advertises, or a storefront-scope mismatch.
Shopify: the platform changing what it serves at the well-known path out from under you.

In every case the failure is invisible until something fetches the live profile from outside and compares it to what you expect. That is the whole job of the watchdog.

CI proves the profile you wrote is correct. A watchdog proves the profile your customers' agents actually hit is still correct - at 3am, after a cert renewal, when no one shipped a thing. Both are a few lines of YAML. The merchants who win the agentic-commerce transition will treat the second one like uptime, because that is exactly what it is.

If you would rather not run your own, UCPtools does hosted monitoring with break-alerts across all four validation levels - start here. Either way: watch the live profile, not just the build.

UCP is an open standard by Google and Shopify. UCPtools is an independent community tool.
Built by Peter at UCPtools.

DEV Community: Peter

Which UCP version is your validator actually checking against?

What each tool says it validates against

What actually changed between versions

How to check your validator yourself

Why this is the question to ask

Five months, six profile builders, one silent spec drift

The drift was older than the release that exposed it

Six builders, and the change had to be made in all of them

Why the tests were green

What actually caught it

Fix 1: one assembler, and versions as data

Fix 2: guards that fail the next time

The outcome

Three things to take away

UCP v2026-08-25 Breaks Quietly: 4 Changes That Still Pass Validation

Why this release breaks quietly

Silent breaker 1: signing_keys became keys

We got this wrong in the opposite direction

Silent breaker 2: fulfillment config lost its allows_ prefix and changed shape

Silent breaker 3: buyer consent went from booleans to a reverse-DNS map

Silent breaker 4: payment extensions moved namespace

The migration checklist

The broader point

Is Your UCP Validator Lying to You About Cart and Catalog?

Is Your UCP Validator Lying to You About Cart and Catalog?

The draft-spec trap nobody talks about

What a hard-fail actually costs you

The fix: draft-aware validation

Three things to check in your current validation workflow

The spec is moving. Your validation should move with it.

ChatGPT Can Shop Now. Is Your Store Ready to Sell to It?

ChatGPT Can Shop Now. Is Your Store Ready to Sell to It?

What ACP Actually Checks

ACP vs UCP: Don't Confuse Them

The March 2026 Pivot (And Why ACP Matters More, Not Less)

The Numbers

Test It in 30 Seconds

Run UCP + ACP Validation in Your CI/CD Pipeline

What actually breaks

The GitHub Action

The pattern that actually pays: gate the deploy

Not on GitHub? Use the CLI

The other protocol: ACP readiness

Where to set the bar

Getting started

The Agentic Commerce Stack Is Complete - Here's Your July 2026 Implementation Checklist

The Agentic Commerce Stack Is Complete - Here's Your July 2026 Implementation Checklist

1. Validate at All 4 Levels

2. Run the AI Agent Simulator

3. Fix the Top 3 Failures

4. Set Up Monitoring

5. Test All Three Layers

Why This Matters

Building a Dual-Protocol Checkout with Agorio SDK: Support UCP and ACP in Your AI Commerce Agent

Building a Dual-Protocol Checkout with Agorio SDK: Support UCP and ACP in Your AI Commerce Agent

Why Dual-Protocol Support Matters

What Agorio Provides

Step 1: Project Setup

Step 2: Discover a Merchant via UCP

Step 3: Create an ACP Checkout Session

Step 4: Build a Dual-Protocol Shopping Agent

Step 5: Test with Mock Merchants

Step 6: Deployment Considerations

Conclusion: Why Agorio is the Right Choice

We Tracked Every AI Agent That Visited Our Site. 5 Different Agents Found Us This Month.

We Tracked Every AI Agent That Visited Our Site. 5 Different Agents Found Us This Month.

What showed up (and what they did)

This isn't about SEO as you know it

What this means for developer tools and e-commerce platforms

The protocol layer matters too — here's how they connect

How to check if AI agents can find you (and transact with you)

One thing I'm still figuring out

Google's Universal Cart Is Live. Here's the Checklist to Make Sure Agents Can Actually Check Out on Your Store

Level 1: Structure - does the profile parse at all?

Level 2: Rules - is it actually UCP-compliant?

Level 3: Network - do your references actually resolve?

Level 4: SDK - does it pass the official compliance pass?

Run the whole checklist in one call

Where each stack tends to break

Silent breaker 1: `signing_keys` became `keys`

Silent breaker 2: fulfillment config lost its `allows_` prefix and changed shape