Editorial review/UCP, ACP, AP2/Implementability 4 of 5
UCP, ACP, AP2: The Agent Commerce Protocol Stack, Reviewed From a Builder's Seat
This is an editorial review of the three agent commerce protocols implemented on this site: UCP for discovery, ACP for checkout configuration, and AP2 for cryptographic transaction mandates. I wrote it from the seat that did the implementing, so every claim here traces to a file this domain actually serves. The verdict up front: the read-only surface of all three went live in days, honest pre-launch state was expressible throughout, and the stack still loses a point to version drift, thin tooling, and one routing trap. Implementability: 4 of 5, justified below.
The stack
What Do the Three Protocols Actually Do?
The stack splits agent commerce into three layers that a systems engineer can hold in one diagram: discovery, execution, and trust. Each layer is one JSON document at a well-known path on this domain, each is readable by any agent today, and each declares planned state as planned rather than pretending the product is live. That honesty being expressible in the wire format is the first thing the stack gets right.
What was easy
What Did the Stack Get Right for a Builder?
The read-only surface of all three protocols is deliberately cheap to stand up, and that design decision is the best one in the stack. A discovery manifest, a checkout configuration, and a trust document are each a structured JSON response from one route, which means the whole surface went live on this site in days of work, not weeks, and before any commercial infrastructure existed behind it.
What is rough
Where Does the Stack Fight You?
Three findings from the build, stated as findings. The specs drift: UCP versions itself with a date string, ACP declares version 1.0, and AP2 sits at 0.2, which are three maturity levels wearing one stack name. The tooling is thin: beyond a schema complaint when a capability lacks its URL, you are eyeballing JSON, which is why this site ships its own protocol checker. And one trap cost real debugging time, documented below so it costs you none.
The verdict
What Rating Does the Stack Earn?
Implementability: 4 of 5. The stack earns the four because one engineer took all three protocols from zero to a live, truthful, agent-readable surface on this domain in days, with a single environment variable of secret state and no database behind the parts an agent actually reads. It loses the fifth point for the costs named above: three versioning schemes across three specs, duplicate discovery documents, validation tooling thin enough that we had to write our own checker, and a routing trap that punishes a reasonable default. Every one of those is friction a maturing spec family should sand off, and none of them stopped the build.
Who benefits is equally concrete. A small team gets a machine surface that states its real status to agents before launch, which is exactly what a pre-launch data company needs to be discoverable without overclaiming. Agents get documents they can trust because the availability flags are wired to tell the truth. And the protocols themselves benefit from implementations that file honest reviews like this one, because a spec only hardens when builders report where it bends.
Questions, answered plainly
Which protocol should a builder implement first?
UCP, because discovery pays before commerce does. A UCP manifest at /.well-known/ucp tells an agent what the organization offers and how to transact before a single order flow exists, and it is a read-only JSON document you can serve from one route. ACP configuration and the AP2 trust surface follow naturally, and both can also ship read-only.
Does implementing the stack require payment infrastructure?
Not for the surface that matters pre-launch. The only database-coupled parts of the whole stack are AP2 mandate issuance and revocation, and both can wait until activation. The GET endpoints, which are what agents actually read for discovery and trust, need zero infrastructure beyond a keypair, and the single secret in the entire implementation is the AP2 private signing key.
What is the well-known shadowing trap?
Framework rewrites that map /.well-known/ paths to live routes run after static files are checked, so a static file committed at one of those paths silently wins forever and the live route behind it never executes. The fix is a rule: serve every protocol document from a route, and never also commit a static copy of it. This site keeps only agent.json, ai-plugin.json, and security.txt static, by design.
Why does the stack rate 4 of 5 and not 5?
Because the review has to be honest about the friction. Three protocols carry three different versioning schemes, ACP wants two separate discovery documents, UCP drags a legacy manifest path, and validation tooling is thin enough that this site had to ship its own checker at /api/check-endpoint. Each of those costs was survivable, and none of them was zero.
Read the reviewed surface yourself.
Every document this review grades is live on this domain right now, and an agent can read all three without asking permission. Check the manifest, the configuration, and the trust surface, then check any other domain for the same stack with the free endpoint in the documentation.