Web Standards

Agents that interact with web applications should not need to scrape HTML, click buttons, or reverse-engineer private APIs. Web applications should expose themselves natively — declaring what they are, what they accept, what they cost, and what is dangerous, in formats a model can read without trial and error.

Two layers complete this. The first is how an agent discovers and calls a service: manifest, schema, transport, safety. The second is how the agent pays when the service is not free: HTTP 402 and the protocols revived around it. Together, they turn an arbitrary web service into a tool any agent can use without bespoke integration.

Discovery: where the tools live

There is no single ratified discovery file in 2026. Two conventions matter, plus several also-rans.

• /.well-known/agent-card.json — the A2A AgentCard, originating in Google’s Agent2Agent Protocol. This is the dominant production form: a JSON manifest declaring identity, capabilities, auth requirements, and a pointer to tool definitions.
• /llms.txt at the site root (not under /.well-known/) — proposed by Answer.AI in 2024. Roughly 10% adoption across surveyed domains, no commitment from major LLM providers, explicitly rejected by Google. Its real utility is IDE coding agents (Cursor, Claude Code, Copilot) pulling documentation sites — not discovery-time crawling by chat products.
• Also-rans: the Universal Commerce Protocol (/.well-known/ucp/manifest.json), Aiia’s /.well-known/ai-agent.json (published March 2026), and the text-based agent-manifest.txt. None has the institutional backing of AgentCard.

Publish both if you can afford to: agent-card.json for agent-to-agent discovery, /llms.txt for the IDE coding-agent traffic that actually fetches it. A minimal AgentCard names the service, declares auth, and points at the tool definitions — everything else hangs off the tools pointer.

Schema: OpenAPI 3.1, then MCP

OpenAPI 3.1 is still the foundation. It is no longer sufficient on its own. The 2026 stack for agent-facing APIs is OpenAPI 3.1 + MCP (Model Context Protocol), with MCP at ~97M monthly SDK downloads as of March 2026. MCP does not replace OpenAPI — the dominant pattern is to author the OpenAPI spec, then auto-generate an MCP server (Speakeasy Gram, FastMCP, openapi-mcp-generator). OpenAPI is the schema layer; MCP is the runtime discovery and invocation layer.

Semantic verbosity matters more than coverage. LLMs need more context than human developers, and explicit enums prevent hallucinated parameter values:

A spec that compiles is not the same as a spec an agent can use. Every field with a constrained value set should declare it.

Safety: classify before you expose

Autonomous agents operate probabilistically. The API must separate read operations from irreversible ones at the schema level, so a tool’s blast radius is visible before it runs.

All tools must be idempotent — agents will retry, and a duplicated transfer_funds is a production incident.

Human-in-the-loop

For high-risk state changes, the conventional pattern is to return 202 Accepted with a status URL the agent polls. This is a real HTTP semantic — RFC 7231/9110 — but it is not a ratified agent-HITL convention. Production SDKs (OpenAI Agents, Cloudflare Agents, LangGraph) use state-managed interruption with checkpoint and resume rather than HTTP polling. The flow below is illustrative:

sequenceDiagram
    participant A as Agent
    participant API as Application
    participant U as User (Phone/Email)

    A->>API: tools/call {name: "transfer_funds", arguments: {amount: 500, to: "vendor"}}
    API-->>A: 202 Accepted — "Pending human approval"

    API->>U: "Your agent requests: Transfer $500 to Vendor. Approve / Deny?"
    U-->>API: Approved

    API->>API: Execute transfer
    API-->>A: {status: "completed", transaction_id: "tx_892"}

The agent treats pending as not-rejected and continues other work. The point is durable interruption, regardless of which wire convention carries it — 202-as-HITL is a reasonable framing one author can recommend, not a ratified pattern.

Payment: HTTP 402, three protocols

HTTP 402 “Payment Required” was reserved in 1997 for a payment layer that never shipped. Traditional rails couldn’t carry sub-cent transactions. Agents now need exactly that: autonomous, real-time, machine-to-machine settlement without signups or API-key provisioning. Three protocols implement it, and they are not converging.

x402

Coinbase-originated, now stewarded by the x402 Foundation, which went live under the Linux Foundation on 2 April 2026 with 20+ institutional members (Coinbase, Cloudflare, Google, Stripe, AWS, Mastercard, Microsoft, Circle, Visa, Solana Foundation among them). Adoption is the largest of the three: ~150M+ cumulative transactions, ~$600M annualized volume, ~69k active agents as of April 2026. Zero protocol fees.

The handshake is two headers:

HTTP/1.1 402 Payment Required
X-Payment-Required: {"price": "0.001", "currency": "USDC", "network": "eip155:8453", "address": "0x...", "facilitator": "https://facilitator.x402.org"}

# Agent retries with:
X-Payment-Signature: <signed_payment_payload>

The seller forwards verification to a facilitator — a payment service that settles on-chain and returns a yes/no. Sellers never touch blockchain infrastructure directly.

L402

Lightning Labs’ protocol, production-ready since ~2020 via the Aperture reverse proxy. Macaroon-based bearer credentials with attenuation — a parent agent can cryptographically restrict a sub-agent’s credential (max spend, expiry, allowed endpoints) without contacting the issuer. The spec is mature and the delegation model is a genuine differentiator, but real-world server-side adoption has stalled; Lightning Labs themselves acknowledge “virtually no APIs use [L402] as intended.”

MPP

Stripe + Tempo’s Machine Payments Protocol, launched 18 March 2026 with 100+ Day-1 adopters (Anthropic, OpenAI, Shopify, Alchemy, Dune, Browserbase). Session-based rather than per-request: pre-fund a session, settle per call against the balance. Shared Payment Tokens (SPTs) accept USDC, credit cards, or BNPL. Settlement runs through standard Stripe PaymentIntents on the merchant’s normal payout schedule.

AP2

Google’s Agent Payments Protocol (v0.2.0, April 2026, 60+ partners) is the closest thing to a unifying umbrella. It is an orchestration layer above the three protocols and uses x402 as its crypto-rail extension while supporting cards, bank, and BNPL natively. Worth watching, but it is a coordinator, not a replacement.

Choosing one is short: x402 for crypto-settled long-tail (the default for most agent-facing APIs in 2026), MPP for Stripe merchants who need fiat, L402 only for sub-cent micropayments and only if you can find a server that takes it.

Agent OAuth — what’s real today

The pattern of agent-scoped tokens (agent:read, agent:draft_only) is aspirational, not standardized. IETF work exists in draft form — draft-klrc-aiagent-auth-01 introduces an agent_assertion grant type, and a separate draft adds requested_actor / actor_token parameters for delegation — but no ratified spec uses those scope names. Production today combines per-tool, per-action scopes (mcp:tool:read_file:read, calendar:create_event) with actor-token delegation. Treat the agent:* naming as illustrative until consensus catches up. See Credentials for the current production pattern.

Adoption path

Steps 1-3 make the application agent-accessible. Steps 4-5 make it agent-safe — and, with 402, agent-monetizable without a billing dashboard.