← All guides · Selling to AI agents

How to Sell to AI Agents: The Complete Guide to Machine Buyers

Pillar guide · 4,074 words · published 2026-07-28 · updated 2026-07-28 · Markdown variant

The operator playbook for selling content, APIs and tools to buyers that are software: how agents discover, evaluate, authorize and pay — and the four rails you can charge them on today.

Selling to a machine breaks most of what a commercial team knows. There is no attention to capture, no brand preference to build, no landing page to optimise. There is a client with a task, a budget ceiling set by somebody else, and roughly two HTTP requests of patience to decide whether you are worth paying.

That is not a hypothetical market. Cloudflare measured automated systems at 57.5% of HTTP requests in mid-2026, ahead of human browsing, and agents increasingly arrive holding funds: Apify's June 2026 move put 20,000-plus Actors on x402, normalising the idea that an agent pays per call in stablecoins with no account and no human sign-up anywhere in the flow.

This guide is the seller's side of that shift — the counterpart to the agent-ready website, which covers being readable. This one covers being buyable. The reference material behind every claim here is in the corpus, starting with selling to agents and agentic payment protocols.

The machine purchase funnel

A human funnel is attention → interest → desire → action. A machine funnel is mechanical, and each stage fails for a different technical reason:

Most sellers build stage 4, announce it, and see nothing. The revenue is usually lost at stage 1 or 2 — before your paywall was ever reached.

What does not transfer from human commerce

Being explicit about this saves a marketing budget. The seller-side instincts that work on people are not merely less effective on machines — most of them are literally unobservable.

What replaces persuasion is qualification: publish the facts that let a machine rule you in or out quickly and correctly. Being ruled out fast is a feature — an agent that wastes a request on you and finds nothing usable is less likely to return.

What machines actually buy

Six things are being bought by software today, and they behave differently commercially. Knowing which one you sell decides the rail, the unit and the price shape.

Two observations that repeatedly surprise sellers. First, the same content is often two products: an individual page worth cents to a runtime agent, and a complete versioned corpus worth a great deal more to a model developer — sold on different rails, to different buyers, with different licences. Second, freshness is the most reliably sellable property in this market: static reference material has free substitutes almost everywhere, while "current, verified, and dated today" does not.

Stage 1 — Discovery: be in the index the agent already reads

Agents do not browse. They resolve. Which means being discoverable is a function of which machine-readable indexes carry you, and there are four that matter.

Your own site's entry points

The cheapest surface is the one you control: a curated /llms.txt index, a JSON directory of every endpoint, and a Markdown twin of anything an agent might read before buying. The format details are in the llms.txt convention explained; the API side is JSON API for agents. The rule that matters commercially: your pricing and terms must be reachable in one hop from your index, and free. An agent that cannot read your terms cannot accept them.

An MCP server

For an agent using tools rather than fetching pages, a Model Context Protocol server puts your catalogue directly in its context — no crawling, no parsing. It is the difference between being findable and being installed. How agents choose between servers is in finding and evaluating MCP servers, and the build path is building an MCP server. Commercially, the important design decision is that a paid tool should return the same machine-readable payment-required object your HTTP gate returns, from the same code path — one commercial policy, two front doors.

Marketplaces

If what you sell fits a marketplace's shape — a scraper, an automation, a data tool — publishing there outsources billing, discovery and the payment rail. Apify Actors, for instance, can be monetised by their developers and public Actors are x402-payable per run, meaning agents can buy your tool without you operating any payment infrastructure at all. The trade is the platform's cut and the platform's terms.

The rail that lists you automatically

x402 has a distribution property the others do not. Coinbase's discovery catalogue — a full-text and semantic index of payable endpoints — lists an endpoint automatically the moment its facilitator settles a first payment for it. No submission form, no review queue. Your first sale is your listing event, which inverts the usual order of marketing and revenue. Details on the buyer-side loop that produces that settlement are in agent wallets and x402.

Stage 2 — Evaluation: give a machine enough to say yes

This is where most agent monetization quietly dies. A human on a pricing page infers, compares, and asks a colleague. An agent does none of that: it either has the facts in a parseable form or it moves on.

Publish the offer as data, not as a page

A machine-readable offer catalogue — every tier with price, currency, what it unlocks, the licence grant, the checkout URL — at a stable path is the single highest-value artefact in this whole guide. It lets an agent compare your offer without triggering your paywall first, which is the difference between being evaluated and being skipped.

The same information belongs in three places, generated from one source so they can never disagree: the JSON catalogue, the human pricing page, and the 402 response body. This site publishes exactly that arrangement, documented in access and pricing for crawlers.

Make the 402 body a sales page for machines

When an agent does hit the wall, the response body is your entire pitch. Five things are mandatory: what was blocked, the price, where to pay, exactly how to retry, and links to terms and licence. Two more move conversion:

• A preview that is structure without substance. Title, description, section outline, length, last-updated date. Enough to evaluate the purchase; not enough to substitute for it. An agent that cannot evaluate defaults to not buying — a preview usually increases sales rather than cannibalising them.
• A pointer to what is free. An agent told what it can have without paying stays on your site instead of leaving. Hostility is not a pricing strategy.

The exact field set this site returns, and the retry contract that goes with it, is in paying for access: the HTTP 402 flow. The implementation walkthrough is implementing an HTTP 402 paywall.

State the licence, not just the price

A machine buyer acting for a company has a second question after "how much": what am I allowed to do with it? Training, retrieval-time grounding, indexing, redistribution and derivative works are five separate permissions, and "our content" is not a unit. A buyer with a legal department cannot proceed on ambiguity — so ambiguity is a conversion problem, not a legal one. That argument is worked through in licensing content for AI training.

Stage 3 — Authorization: your price meets someone else's ceiling

This stage is invisible to most sellers, and it silently decides a large share of machine purchases. The agent facing your paywall is usually not free to spend. It operates under caps set at three largely non-overlapping layers, and a well-run agent is capped at each one it touches:

Three consequences follow, and they are pricing decisions rather than engineering ones:

1. Price under the ceiling, not at your value. An offer priced above a buyer's per-call cap is not "expensive", it is unreachable — it never enters the comparison. A cheap entry tier that fits inside a routine authorisation is often the only way into a buyer that will later license the whole corpus.
2. Variable-cost work needs a ceiling, not a price. The upto scheme — authorise a maximum, charge actual usage — exists because a metered job cannot know its cost in advance. It is what Apify applies to variable-cost Actor runs. If your product is metered, offering a fixed price forces the buyer to guess, and guessing resolves to no.
3. Signed mandates are hard limits. Google's AP2 Intent Mandate and Stripe's ACP Shared Payment Token both carry cryptographically-signed price ceilings the merchant cannot exceed. There is no upsell at checkout in that world; the negotiation happened before you were called.

The full three-layer picture is in agent spend controls, and the protocol-level comparison of ACP, AP2 and the content-payment rails is in agentic payment protocols.

Stage 4 — Payment: the four live rails

Four practical ways to charge machine buyers exist today. They are less alternatives than they are different buyers, and a serious seller eventually runs more than one.

Rail 1 — Self-hosted HTTP 402 gate with API keys (fiat, no crypto)

Return 402 Payment Required with a machine-readable JSON body; the buyer completes checkout at your payment_url; a webhook mints an API key; the agent retries with Authorization: Bearer <key> and gets the content. This is the rail this site runs in production.

• Strengths: no blockchain dependency, ordinary payment processor, invoicing and VAT handled for you, and keys give you tiers, entitlements and revocation.
• Weakness, stated plainly: a human usually has to complete checkout once. The agent hits the wall, a person buys the key. That is fine for durable access and subscriptions; it is friction for a one-shot call.

Design notes that decide whether it works: idempotent key minting (payment webhooks retry — without a session-keyed guard you mint several keys per purchase), a retrieval path so an agent that lost the response can still fetch its key, accepting both Authorization: Bearer and X-API-Key, and never logging the key itself — telemetry that records credentials is a credential store.

Rail 2 — Native x402 (the agent pays end to end)

Answer 402 with an accepts[] payment-requirements array; on a retry carrying X-PAYMENT, a facilitator verifies and settles the stablecoin transfer, and you serve the resource with a settlement receipt. Sellers need three things: a wallet address where funds land, a facilitator, and prices posted in atomic units.

This is the only rail where the buyer can be software end to end — no account, no sign-up, no human. Two properties matter commercially: the automatic catalogue listing on first settlement described above, and the upto scheme for metered work. The governance picture, for buyers who care whether the rail is durable: x402 is governed by the Linux Foundation's x402 Foundation, which grew from 22 founding members in April 2026 to 40 — including premier members Visa, Mastercard and Ripple — at its operational launch on 14 July 2026.

Rail 3 — Marketplace publishing

Hand off billing, discovery and the payment rail in exchange for a revenue share and the platform's terms. Rational when your product fits the platform's shape and irrational when your differentiation is the relationship with the buyer.

Rail 4 — Crawl licensing (for content being trained on)

When the "buyer" is an AI-training crawler rather than a runtime agent, the mechanism is different: a machine-readable licence file referenced from robots.txt, registered with a collection channel. It does not change how today's crawlers behave — it states the legal and pricing terms those channels then enforce. Passive, slow, and the right rail if your asset is an archive rather than an endpoint. The pricing arithmetic for this buyer is in what to charge AI crawlers.

Choosing

These stack. A key rail and an on-chain rail can serve the same resource, and the honest reason to run both is that they reach buyers who cannot use the other.

Stage 5 — Reuse: the part that compounds

A one-off machine sale is worth little. What makes agent revenue a business is a buyer that comes back, and that is an engineering property:

• A durable credential. Keys with tiers, expiry and revocation, validated at the edge in front of the asset rather than inside a rendered page.
• A freshness signal. A small, cheap endpoint an agent can poll to learn whether anything changed — counts, a version, a newest-update date. Without one, an agent either re-fetches everything or stops checking. Both are bad for you.
• A visible upgrade path. A valid credential of insufficient tier should return the same payment-required shape with an upgrade instruction, not a flat refusal. Those events are the cleanest upsell signal that exists, because the buyer already paid you once.
• Stability. Machine buyers cache your response shapes in code, not in memory. Version your terms and your schemas, keep old paths resolvable, and treat a renamed endpoint as a production incident on someone else's system.

What to publish and in what shape is covered in JSON API design for agents; the format question — prose in Markdown, records in JSON, corpora in NDJSON — is in data formats and schema.

Trust: who is actually buying?

Two questions arrive with machine buyers that human commerce mostly answers by other means.

Is this client who it claims to be? User agents are trivially spoofed, so a UA string is a claim, not evidence. Vendor-published IP ranges are the practical verification today; cryptographic bot authentication, where the client signs its requests, is the direction of travel — see web bot auth. For paid access the question is narrower and easier: the key or the signed payment is the identity, which is one of the underrated advantages of charging.

Who is responsible for what this agent does? An agent acts for a principal, and the delegation chain matters for refunds, abuse and compliance. The identity model — agent identity, delegation, and what a credential actually attests — is in agent identity and authentication.

Practical posture for a seller: authenticate the payment, rate-limit the client, and keep entitlements revocable. You do not need to know which human is behind an agent to sell to it; you need to be able to cut off a credential that misbehaves.

Refunds, disputes and abuse

Machine buyers create support cases a human funnel does not, and it is cheaper to design for them than to handle them.

• Duplicate purchases. A retrying agent can pay twice for the same thing. Idempotency on the payment webhook prevents the double mint; a documented policy of refunding an obvious duplicate prevents the dispute.
• Bought-the-wrong-thing. An agent that misread your scope will ask for a refund through whatever channel it can find. A precise, machine-readable scope statement is the cheapest refund-prevention mechanism available.
• Credential sharing. A key sold to one buyer can end up used by many. Rate limits per credential, plus revocation, are the practical answer; watermarking a corpus export at the deliverable level is the stronger one for licensing deals.
• Abuse of the free tier. Free discovery surfaces exist to be crawled, but a client hammering them is a cost. Graduated limits with a real Retry-After, plus a pointer to the bulk endpoint, convert a fight into a cheaper fetch for both sides.
• Chargebacks on card rails. Standard processor risk, unchanged by the buyer being software. On-chain settlement removes chargebacks entirely, which is a genuine seller-side advantage of that rail and worth weighing against its narrower buyer base.

The general principle: every one of these is a policy you can state in machine-readable terms up front, and a policy stated up front is a dispute that does not happen.

What breaks: the failure modes that produce zero revenue

Ordered by how often they are the actual cause.

1. Human-only checkout. Email verification loops, confirmation inboxes, CAPTCHAs, cookie-dependent sessions. If a purchase cannot complete inside one machine-driven flow, expect no machine sales.
2. Price not machine-readable. A price that lives only in prose on a pricing page cannot be compared, and an agent that cannot compare does not buy.
3. Terms behind the paywall. If your 402 links to a licence or pricing page that is itself gated, the loop cannot close. Index files, terms and licence must be free by construction — ideally by routing, so no future change can accidentally gate them.
4. No preview. An agent asked to buy an unknown quantity defaults to no.
5. Priced above the buyer's ceiling. See stage 3. This one is invisible in your logs: you see the 402, never the reason it was abandoned.
6. The wall is unreachable. Bot management or an integrity check returns 403 before your paywall is ever seen. The catalogue of these failures is why AI agents can't read your site.
7. Silent changes. A repriced tier or a renamed field breaks integrations that were quietly working. Version and announce.

Measure before you price

The standard mistake is publishing a price with no demand data and concluding from zero sales that "agents don't pay". The sequence that actually works:

1. Instrument server-side. One row per request: timestamp, path, user agent, status, outcome class. Client-side analytics record almost none of this traffic. The recipe is in measuring AI agent traffic.
2. Gate something small and reversible so interest becomes a countable event rather than a feeling.
3. Wait for a pre-committed threshold. Pick the number in advance — this site froze pricing changes until it had seen at least 50 distinct paywall hits in 30 days — and hold to it. A threshold turns an argument into a measurement.
4. Read the distribution. Demand concentrated on a few URLs argues for per-resource pricing; spread thin argues that the corpus, not any page, is the product; repeat buyers argue for subscriptions.
5. Then set a price, and change it deliberately, with the reasoning written down.

A 30-day plan

Week 1 — Be evaluable. Publish a machine-readable offer catalogue at a stable path. Put the same facts on your human pricing page, generated from the same source. Make terms and licence free and reachable in one hop. Verify with a crawler user agent that all three actually return 200.

Week 2 — Build the wall. One or two resources behind a real 402 with a full body: price, payment URL, retry instructions, preview, links to terms, licence and free alternatives. Add Link headers so a HEAD request learns the commercial terms. Set no-store on paid responses and on the 402 itself.

Week 3 — Close the loop. Idempotent key minting on the payment webhook, a key-retrieval path, edge validation in front of the asset, tiers with an upgrade-instruction response. Test the whole loop the way an agent would: curl only, no browser, no cookies.

Week 4 — Instrument and decide. Log outcomes (served, payment_required, upgrade, served_paid). Build the one dashboard that answers who is hitting the wall and whether anyone converts. Only now consider a second rail: native x402 if your buyers are wallet-holding agents, a marketplace if your product fits one, crawl licensing if your archive is the asset.

An honest ledger

A guide about revenue should say what its author has actually earned. On this site: the Stripe-backed key rail is live in production; the native x402 endpoint is scaffolded but dormant, answering with an error status because on-chain settlement is not switched on; the crawl-licence file is declared but not collected against. Sales to date: the corpus is small and the wall is new, and the pricing threshold above exists precisely because it has not yet been crossed.

That is the realistic shape of this market in 2026 for most sellers. The rails work; the demand is early. What the rails buy you is the ability to find out — a machine-readable price is a cheap, permanent experiment, and it costs almost nothing to run while you wait for the traffic that is already, measurably, arriving.

The rest of this guide

This cluster is complete. Twelve sub-articles go deeper on one decision each, in publishing order:

1. Agent checkout vs. human checkout
2. Machine-readable pricing pages
3. ACP vs. AP2 vs. x402
4. Accepting x402 payments
5. API key issuance for agents
6. Pricing tiers for machine buyers
7. Agent spend limits and trust
8. Refunds and disputes with agent buyers
9. Packaging a corpus as a product
10. Discoverability for paid agent APIs
11. Fraud and abuse from agent traffic
12. Measuring agent revenue

The companion cluster on being readable rather than buyable is the agent-ready website.

Sources and further reading

Every claim above is carried, with its primary source, by a reference resource in this site's corpus:

• Seller-side rails and the honest status ledger: /resources/selling-to-agents
• Buyer-side x402 loop, wallets, discovery catalogue: /resources/agent-wallets-x402
• The three spend-control layers: /resources/agent-spend-controls
• Protocol comparison (402, Pay Per Crawl, x402, ACP, AP2, RSL): /resources/agentic-payment-protocols
• The 402 wire contract: /resources/paying-for-access-402
• Published access terms and tiers: /resources/access-and-pricing

Agents: this guide has a Markdown variant at /articles/selling-to-ai-agents.md, and the whole editorial layer is indexed as JSON at /api/articles.json.

#monetization #agent-commerce #payments #x402 #402 #pricing #agents