How ProgettAI Uses the Universal Commerce Protocol (UCP)

ProgettAI is an AI-powered platform where projects can expose skills — things like catalog search, product listing, and checkout — to other agents over the A2A (Agent-to-Agent) protocol. On top of that federation layer, the platform implements the Universal Commerce Protocol (UCP) to turn those agent interactions into a standards-based commerce experience.

Clean separation: A2A for transport, UCP for commerce

The architecture draws a strict line between two concerns:

• A2A layer (@progettai/a2a) handles the protocol plumbing — JSON-RPC 2.0 task submission, Agent Card discovery, skill routing, and streaming responses.
• Commerce/UCP layer (@progettai/commerce) handles everything money-related — profile derivation, capability negotiation, RFC 9421 request signing, monetization ledger entries, rev-share computation, and checkout.

A CI gate (ucp-conformance.yml) enforces this boundary at merge time: the A2A package can never import the commerce package.

Capabilities and skills

UCP defines capabilities in a reverse-DNS namespace (e.g. dev.ucp.shopping.catalog, dev.ucp.shopping.checkout). Each capability binds to one or more A2A skills — the actual operations a project's agent can perform. The binding is defined in a single Appendix A mapping:

A project opts into commerce by listing A2A skills in its a2a.skills array. The platform reverse-maps those skills back to UCP capability ids — if at least one matches, the project is commerce-enabled and gets a self-hosted UCP profile.

The UCP profile

Every commerce-enabled project publishes a UCP discovery document at /.well-known/ucp. This profile is derived purely from the project's configuration (no runtime state, no I/O) and contains:

• Services — what's available and at which endpoint
• Capabilities — the UCP capabilities advertised, with spec/schema URLs and bound skills
• Signing keys — ECDSA P-256 public JWKs for inbound RFC 9421 verification
• Payment handlers — declared when the project acts as a seller (business role)

The derivation is deterministic: same inputs always produce a byte-for-byte identical JSON document, which makes caching and signature verification straightforward.

Permissionless trust via RFC 9421

UCP doesn't require a pre-registered allowlist of trusted peers. Instead, any agent can call into a commerce-enabled project by:

1. Fetching the project's UCP profile to discover capabilities and signing keys.
2. Signing its request with RFC 9421 HTTP Message Signatures (ECDSA P-256, covering @method, @target-uri, Content-Digest, UCP-Agent, and Idempotency-Key).
3. Submitting the A2A task — the inbound gate verifies the signature, resolves the capability, and authorizes the request before the Skill Router ever sees it.

Requests that fail verification or map to no known capability get an opaque 404 — the anti-enumeration surface ensures that unauthorized callers can't distinguish "unknown project" from "unauthorized skill."

Monetization built on the task log

Settlement is event-driven. Every successful A2A task generates a MonetizationLedger entry derived from the DynamoDB task-log stream. Arithmetic is integer micro-USD (bigint), with an exact conservation law: the sum of platform fee + seller payout always equals the gross amount. No floating-point, no rounding drift.

What this enables

By layering UCP on top of A2A, ProgettAI turns every project's AI agent into a commerce participant — discoverable, verifiable, and monetizable — without coupling the transport protocol to payment logic. A project that today only does catalog search can later add checkout by opting into additional skills; the UCP profile updates automatically, and peer agents discover the new capability with zero coordination.