Advanced Agentic Commerce: Ship the Full Agent Surface

20 slides on the real implementation: Link headers, API catalog, Auth.md, A2A and MCP cards, ACP/AP2/MPP/UCP, x402, markdown negotiation, signed bots, WebMCP, DNS-AID and DNSSEC — the exact checklist Robauto runs on a live domain.

20 lessons · ~5 min · free, no signup.

Lessons

Full course text

1. From ‘buyable’ to ‘verifiably ready’

Agentic Commerce 101 covered the concepts. This course is the build: twenty-five concrete surfaces an agent probes on a domain — discovery, auth, payment, identity, DNS — and the order to ship them in. Robauto will run this as a done-for-you service shortly.

Source: Robauto — AgentHub

2. Step 0 — get an honest audit first

Before touching anything, scan the domain and write the baseline down. Robauto’s Agent Readiness scan is URL-only — no email, no account — and returns pass/warn/fail per check across four levels: Signal Basics, Technical Groundwork, Agent Integration and Agentic Commerce. Every check links back to the slide that teaches it, so each change has a before-and-after instead of a vibe.

Source: Robauto — Agent Readiness Scan

3. Step 1 — Link headers (RFC 8288 / 9727)

The homepage response itself should point at your machine files. Emit Link headers with registered relations: api-catalog, service-desc, service-doc, describedby. One HEAD request and the agent knows where everything lives — no HTML scraping.

Source: IETF RFC 9727 §3

4. Step 2 — the API catalog

/.well-known/api-catalog is an RFC 9727 linkset (application/linkset+json) listing every API you expose and its description document. It is the single entry point agents follow from the Link header out to OpenAPI, MCP, and payment surfaces.

Source: IETF RFC 9727

5. Step 3 — Auth.md + OAuth discovery

Publish /auth.md in Markdown explaining how an agent registers, plus /.well-known/oauth-protected-resource and /.well-known/oauth-authorization-server. Include an agent_auth block and serve the RFC 8414 issuer-suffix path too — scanners fetch /.well-known/oauth-authorization-server/auth/v1 and a 404 there fails the check.

Source: IETF RFC 8414

6. Step 4 — the A2A agent card

/.well-known/agent-card.json describes your agent to other agents: name, skills, endpoints, auth, and declared protocol extensions. Declare extensions with their canonical lowercase URIs — an undeclared extension reads as ‘found but not advertised’ and fails.

Source: A2A Protocol

7. Step 5 — the MCP server card

/.well-known/mcp/server-card.json (SEP-1649) advertises the MCP endpoint, transport, and tool surface so an assistant can attach without a human pasting a URL. Host the endpoint on its own name — mcp.yourdomain.com — and keep the card in sync with the tool catalog.

Source: Model Context Protocol

8. Step 6 — agent skills index

/.well-known/agent-skills/index.json enumerates discrete skills — each with an id, description, input schema, and endpoint. Skills are how an agent decides you are worth calling at all, so write them as tasks a buyer wants done, not as features you shipped.

Source: Robauto — Developers

9. Step 7 — content signals in robots.txt

Content-Signal directives let you state, per crawler, whether content may be used for search, AI input, or AI training. Being explicit and permissive where you want citations beats a blanket Disallow that quietly removes you from answers.

Source: Cloudflare — Content Signals Policy

10. Step 8 — ACP, AP2, MPP

Three commerce surfaces: /.well-known/acp.json (protocol, api_base_url, transports, and capabilities.services as a flat ID array), the AP2 extension declared on the A2A card, and MPP x-payment-info metadata inside your OpenAPI document. Each is a different buyer’s preferred rail.

Source: Agentic Commerce Protocol

11. Step 9 — Universal Commerce Protocol

/.well-known/ucp must answer 200 with protocol_version, services, capabilities, and endpoints — and a real version string, not a placeholder. Every spec URL and schema you reference has to be reachable, or the validator marks the field invalid.

Source: UCP Specification

12. Step 10 — make x402 actually return 402

Publishing /.well-known/x402.json is not enough: the protected route itself must answer HTTP 402 with the full accepts[] set when no X-PAYMENT header is present. If /api/v1 returns 200, the check fails — proxy that path to the paid resource and pass the upstream status through verbatim.

Source: x402 documentation

13. Step 11 — Markdown content negotiation

Agents that send Accept: text/markdown should get clean Markdown; browsers asking for text/html keep the page. Prerender a .md twin per route, serve it with Vary: Accept and a token-count header, and rank markdown only when the client actually prefers it.

Source: Robauto — markdown index

14. Step 12 — signed bots (RFC 9421)

Publish /.well-known/http-message-signatures-directory with your Ed25519 public JWK so counterparties can verify your outbound agent’s signed requests — and so you can verify theirs. This is the difference between an allowlist of user-agent strings and real identity.

Source: IETF RFC 9421

15. Step 13 — WebMCP in the browser

WebMCP exposes page-level tools to an agent operating inside the browser session, so a logged-in assistant can act on the user’s behalf without a server round-trip. Register the tools on load and keep them scoped to what the current page can legitimately do.

Source: Robauto — Developers

16. Step 14 — the edge layer that makes it true

Static hosting ignores header files. Put a small worker in front of the zone to append Link headers, force correct content types on extensionless machine files, proxy live OAuth metadata, and enforce 402. If the public host and the app host are the same, split the origin onto its own name to avoid a proxy loop.

Source: Cloudflare Workers

17. Step 15 — DNS-AID

Publish SVCB/HTTPS records under the _agents namespace — _index, _a2a, _mcp, _api, _soul — each carrying the discovery document path as a numeric SvcParam. An agent then finds your endpoints in one DNS answer, before any HTTP request happens.

Source: Robauto — DNS-AID notes

18. Step 16 — DNSSEC or it doesn’t count

DNS-AID records are only trustworthy when signed. Enable DNSSEC at your DNS provider, then publish the DS record at the registrar — key tag, algorithm 13, digest type 2. Until the parent zone carries the DS, resolvers answer AD: false and the check stays red.

Source: IETF RFC 9364 (DNSSEC)

19. Step 17 — validate, then keep validating

Re-scan after every deploy and treat drift as an outage: a renamed env var, a stale cached card, or an unsigned zone silently un-does the work. Robauto runs a daily endpoint sweep for exactly this reason and reports drift on the dashboard.

Source: Robauto — Dashboard

20. That’s the whole surface. 🏁

Seventeen steps: discovery headers, catalog, auth, cards, skills, content signals, four commerce protocols, x402, markdown, signatures, WebMCP, an edge layer, DNS-AID and DNSSEC. Robauto is packaging this as a managed build-out — get on the list and we’ll ship it on your domain.

Source: Talk to Robauto

All courses · Robauto