Skip to main content

Agent-Readable Conversion

JTBD 5
The buyer is an agent. Is your offer readable?
In agentic commerce, conversion is not a landing page. It is a structured surface a machine can read, evaluate, and transact against — without waiting for a human to tap anything.
Why it matters
If your offer is not machine-consumable, you are invisible at the moment of purchase. The agent compares structured offers; unstructured pages are not compared — they are skipped.
Two segments
Developer agents transact autonomously. Delegating consumers use an AI assistant that acts for them. Both need machine-readable offers; the trust signals differ.
Precondition
Onchain attribution must be live before agent-conversion volume is meaningful. Without it you cannot close the attribution loop from agent purchase back to acquisition source.

Purpose​

Traditional conversion optimisation assumes a human reads a page and clicks a button. In agentic commerce that assumption fails for two of the three buyer segments defined in ICP Definition:

  • Developer agents — autonomous systems that discover, evaluate, and purchase API-accessible offers without human involvement
  • Delegating consumers — humans who instruct an AI assistant to find and purchase on their behalf; the assistant is the actual evaluator

For both segments, the offer must be machine-consumable. An agent cannot fill out a contact form or watch a product video. It reads structured data, compares capabilities against a task specification, and either transacts or moves on.

The third segment — enterprise architects evaluating integration risk — still requires human-facing materials. Landing Page Optimisation serves that segment. This page covers the agent and delegating-consumer segments exclusively.

Process​

1. Agent manifest at /.well-known/agent.json​

The agent manifest is the machine-readable identity card for your offer. It lives at a predictable path so any agent can discover it without prior knowledge of your site structure. Publish and maintain it before any other agent-conversion work.

The manifest declares:

  • Identity — name, description, contact, terms-of-service URI
  • Capabilities — structured list of what your service does, expressed in terms an agent can match against a task
  • Pricing — structured unit prices, rate limits, billing model (per-call, per-token, subscription, onchain metered)
  • Auth requirements — API key, OAuth, onchain wallet, or none
  • Protocol support — which of x402, AP2, ACP, MCP, A2A the service speaks
  • Rate limits and SLAs — latency guarantees, uptime commitments heuristic, retry policy

Keep the manifest current. A stale manifest is worse than no manifest — an agent that discovers a capability your service no longer offers burns trust that affects every subsequent interaction.

2. MCP endpoint exposing the offer​

Model Context Protocol (MCP) is the standard by which agents access tool capabilities. An MCP endpoint makes your service directly callable from within an agent's reasoning loop — no separate API integration required.

An MCP-accessible offer means:

  • The agent can discover what your service does at runtime
  • The agent can call your service as a tool, receive a structured result, and continue its task
  • The delegating-consumer's AI assistant can surface your service as an option when the consumer says "find me a provider that does X"

Publishing an MCP endpoint moves your offer from "something a developer must integrate" to "something any MCP-compatible agent can use today".

3. Onchain checkout an agent completes without a human tap​

Human checkout flows are built for human cognition: multi-step forms, verification emails, payment UIs. Agents cannot navigate these. An agent-completable checkout requires:

  • Wallet-based payment — the agent holds a funded wallet; checkout is a transaction broadcast, not a UI interaction
  • Atomic settlement — the transaction completes in one step; no async confirmation email the agent must poll
  • Structured receipt — the transaction proof is machine-readable; the agent can verify completion and continue its task
  • Delegation scope — the checkout must conform to the human-approved delegation scope (see Verifiable Intent); a transaction outside scope is a trust breach

The x402 protocol is the current reference implementation for crypto-native agent checkout. AP2 and ACP cover card-rail alternatives. Choose based on your settlement preference and the wallet infrastructure your target developer segment already uses.

4. Structured pricing and capability data​

Agents compare offers against task specifications. The comparison is machine-to-machine: the agent reads your capability set, maps it against what it needs to do, checks the price against its budget constraint, and either transacts or moves on.

For this comparison to include you, your pricing and capabilities must be structured — not buried in a pricing page designed for human skimming. Publish:

  • Capability schema — a machine-readable description of what you offer, in terms an agent can match against a task specification
  • Pricing schema — unit prices, volume tiers, billing model, currency accepted (fiat rail, stablecoin, native token)
  • Comparison surface — enough structured data that a comparison agent can rank you against alternatives on the dimensions that matter to the requesting agent

Inputs / Outputs​

Inputs

  • ICP segment definitions — which agents and which delegating-consumer archetypes are you targeting
  • Protocol selection — x402, AP2, ACP, or MCP endpoint (strategy layer: see Agentic Commerce hub)
  • Capability inventory — what your service actually does, expressed as structured capability claims
  • Wallet infrastructure — which chains and which stablecoin rails you support for agent checkout

Outputs

  • /.well-known/agent.json manifest, live and versioned
  • MCP endpoint, published and documented
  • Agent-completable checkout flow on at least one rail
  • Structured pricing schema, discoverable by comparison agents
  • Attribution hooks — every agent transaction tagged to its discovery source (feeds JTBD 8)

Quality Standards​

The agent-readable surface passes when:

  • An agent that has never interacted with your service can discover your manifest, read your capabilities, compare your pricing, and initiate a transaction — with no human intervention
  • The MCP endpoint returns a structured result an agent can use directly; it does not return HTML or unstructured prose
  • The checkout flow completes atomically; it does not require an async step the agent must poll
  • The manifest is updated within 48 hours heuristic of any change to capabilities, pricing, or protocol support

The surface fails when:

  • The manifest exists but is out of date — capabilities listed that no longer exist, or pricing that no longer matches
  • The MCP endpoint requires undocumented setup steps — an agent that cannot discover setup requirements cannot use the endpoint
  • The checkout flow includes a step that requires human cognition (CAPTCHA, email verification, UI navigation)

Metrics​

  • Agent transaction volume — count of completed transactions initiated by agents, not humans (distinguish by wallet type and transaction pattern)
  • Manifest discovery rate — how many agents that fetched the manifest proceeded to a transaction heuristic
  • MCP tool call success rate — percentage of tool calls that return a valid structured result without error
  • Checkout completion rate, agent vs human — the gap tells you where the agent-checkout flow is broken
  • Attribution completeness — percentage of agent transactions traceable back to a discovery source (AEO citation, manifest discovery, MCP tool registry)

Failure Modes​

Manifest exists but is never maintained. An out-of-date manifest is a broken promise. Agents that transact based on stated capabilities and receive different capabilities lose trust — and that trust signal propagates through reputation systems. Treat the manifest as a live contract, not a one-time artifact.

MCP endpoint returns unstructured prose. The MCP result must be structured well enough that the calling agent can act on it without parsing. If your endpoint returns marketing copy, an agent cannot use it. The endpoint exists to serve agents, not humans.

Checkout requires a human tap. Email verification, CAPTCHA, manual approval — each is a checkout-stopper for an autonomous agent. Every required human step in the checkout flow is a conversion failure for the developer and delegating-consumer segments.

No delegation-scope enforcement. An agent checkout that ignores the human-approved delegation scope is a liability, not a feature. Buyers who discover their agent made an out-of-scope purchase will not return. See Verifiable Intent for the consent chain.

Treating landing-page conversion as equivalent. Human-facing landing pages remain relevant for the enterprise-architect segment and for delegating consumers who review before approving. They do not substitute for machine-readable surfaces. Both must exist. See Landing Page Optimisation.

Human / AI Split​

Human judgment required

  • Protocol selection — which of x402, AP2, ACP to prioritise given your settlement preferences and target segment's existing wallet infrastructure (strategy: Agentic Commerce hub)
  • Delegation scope design — what an agent is permitted to purchase autonomously, and what requires human confirmation
  • Privacy guardrails on transaction data — which fields are stored, which are logged, which are auditable
  • Trust signal calibration — what reputation signals to publish and how they are computed

AI-executable

  • Generating the agent manifest from a capability inventory
  • Testing the MCP endpoint against standard agent frameworks
  • Running synthetic agent transactions to verify checkout completion
  • Monitoring manifest freshness and flagging stale capability claims
  • Generating structured pricing schemas from pricing documentation

Context​

Questions​

  • Can an agent that has never visited your site discover your manifest, read your capabilities, and initiate a transaction right now — without you doing anything?
  • If your delegating-consumer buyer instructs their AI assistant to "find me a provider that does X and buy the starter plan", does your offer appear in the result?
  • What is the scope of what an agent is permitted to purchase autonomously on your behalf — and is that scope enforced in your checkout flow?