How Will AI Systems Pay for Content?

An AI system can read your entire archive in less time than it takes you to read this paragraph. It can quote you, summarize you, and hand your reporting to a million people before lunch. What it cannot do, in most cases, is pay you, and not because anyone decided it shouldn’t. Nothing on either side of the exchange is built to make a payment happen.

That is the real shape of the problem. AI systems consume content at machine speed and pay for it, when they pay at all, at the speed of a legal department. A deal takes months. A retrieval takes milliseconds. The two have never been connected, so the money either arrives as a lump sum negotiated in advance or it doesn’t arrive.

This post is about how that changes. It walks through what an AI content transaction is, why terms alone don’t produce a dollar, why usage-based pricing wins once anyone can measure usage, the three ways the money can move, and why AI agents that shop on your customers’ behalf turn all of this from a debate into a deadline. It ends with what you can do now, and where SAIL, the transaction and receipt layer Next Net built for this exact problem, fits in.

What an AI content transaction is

An AI content transaction is a machine-speed license event. An AI system requests a specific piece of content, reads the terms attached to it, receives clearance to use it under those terms, and produces a receipt that records what was used, how it was used, and what is owed. Four steps: request, terms, clearance, receipt. No human in the loop, no email thread, no invoice mailed three weeks later. The whole event happens in the same window as the retrieval itself, because the retrieval is the event.

That definition matters because it draws a line between two things that get confused constantly: a licensing deal and a licensing transaction. A deal is a contract between two organizations. A transaction is one machine asking another machine for one thing and settling up for it. Deals are what publishers have been signing. Transactions are what nobody has been running.

Right now, in most AI answers, a publisher is scenery. Present in the response, cited or uncited, and absent from any ledger. The system used the work, the reader benefited from the work, and no record of the use exists that anyone could take to a finance meeting.

Why “pay” has been the wrong verb

Ask an engineer at any AI company how their system pays for content and you will get a confused look, because the system doesn’t pay for anything. It fetches. Payment, where it exists, lives in a contract somewhere upstream of the code.

That is not malice. It is architecture. The web was built on a request and response model where the response is either the content or an error. There is no step where the requester states who it is, what it intends to do, and what it agrees to owe. The infrastructure carries pages, not deals.

The people who designed HTTP saw this coming. The protocol has held a status code for it since the beginning: 402 Payment Required is reserved in the HTTP specification, sitting between 401 Unauthorized and 403 Forbidden, waiting for a use that never standardized. Three decades later, that slot is still labeled “reserved for future use.” The future is here and the code is still empty.

So when a publisher asks “how will AI pay for content,” the honest answer starts with an admission: it can’t yet, in the transactional sense, because the request never carries the information a payment needs. Fixing that is not a pricing exercise. It is a plumbing exercise.

The four steps, one at a time

Take the definition apart and each step turns out to be a distinct piece of infrastructure.

Request. The AI system identifies itself and asks for a specific content object. Not a domain, not a crawl of the whole site. One article, one image, one dataset. The request has to carry identity, because a system with no identity cannot be billed, and it has to carry intent, because training, retrieval, and summarization are different uses with different value.

Terms. The content object answers with the conditions attached to it. This is where the recent standards work lands. RSL, the Really Simple Licensing standard, gives publishers an XML format for stating machine-readable compensation and usage conditions, including free, pay-per-crawl, and pay-per-inference, and attaching them to pages, feeds, files, and HTTP headers. Terms travel with the object instead of living in a PDF nobody opens.

Clearance. Something has to check the request against the terms and say yes or no. In a human deal, that is a lawyer. In a transaction, it is a clearance service that can issue a token, validate it, and refuse a request that doesn’t qualify. RSL’s specification describes exactly this kind of license server flow, where a client acquires a license token and the content side can validate it before serving.

Receipt. The step everyone skips. A receipt is a durable record that this system used this object under these terms at this time. It is the difference between a publisher who suspects they were used ten million times and a publisher who can prove it. Every other step exists so the receipt can exist, and the receipt is what turns usage into an invoice.

That is the full event. Machine asks, object answers, service clears, ledger records. Once that loop runs, “how does AI pay for content” stops being a philosophical question and becomes a settlement schedule.

Terms are not payment

There is a temptation to treat the terms step as the finish line. Publish your preferences, block the crawlers that ignore them, done. It is worth being clear about what that gets you and what it doesn’t.

The IETF’s AI Preferences working group is standardizing a vocabulary for expressing how content may be collected and processed for AI, attached through metadata or through the protocol that delivers the content. That is useful and overdue. But the same charter puts technical enforcement of those preferences, and the authentication of clients and crawlers, explicitly out of scope. A preference is a sign in the window. It tells a well-behaved visitor what you’d like. It does not ring anything up.

Terms without receipts are a wish list; receipts without terms are a rumor. A working transaction needs both ends, and the receipt end is the one nobody has bothered to build because, until recently, nobody needed to. The reader who clicked through was the payment. Now the reader gets the answer and the publisher gets to be scenery.

Why usage-based pricing wins once measurement exists

Every flat-fee AI licensing deal signed so far has the same structural weakness: it prices the relationship before anyone can count the uses. The AI company estimates how valuable the archive will be. The publisher estimates how much the AI company would pay. They meet somewhere in the middle and neither side ever finds out who was right.

Usage-based pricing flips the order. Count first, price second. That sounds obvious, and in every other utility it is. Nobody sells electricity as a flat annual fee, because the meter exists. Content has never had the meter, so it has never had the meter’s pricing.

The four-step transaction is the meter. Once each retrieval produces a receipt, a publisher can see which objects get used, by which systems, for which purposes, and how often. Pricing can attach to the pattern instead of to a guess. A high-value evergreen explainer that gets retrieved for every question in its category can carry a different rate than an archive item pulled once a quarter, and the receipts are the evidence for both.

This is also why usage-based wins on the AI company’s side of the table, which is the part that gets missed. A flat fee is a bet against an unknown. A per-use rate is a cost that scales with the value the system extracts, which is the kind of cost a business can model. Machine-speed transactions make the pricing legible in both directions. We covered what publishers give up in the flat-fee structure specifically in a separate post on flat-fee AI licensing deals; the point here is narrower. Flat fees are what you sign when you can’t count. Once you can count, you stop signing them.

Three ways the money can move

The transaction is the mechanism. The pricing model is a choice layered on top, and the standards work already names the main options.

Per crawl. The AI system pays each time it fetches the object. Simple to meter, easy to explain, and it fits the training use case, where the value is in acquiring the content once. Its weakness is that it charges for access rather than for use. A page fetched once and quoted a million times is priced like a page fetched once and ignored.

Per inference, or per retrieval. The AI system pays each time the content shapes an answer. This is the model that matches how retrieval-based systems consume content: not at crawl time but at answer time, over and over. It requires the receipt step to work at answer time, which is harder, and it is the model most worth building toward, because it prices the thing that carries the value.

Blanket or collective license. A group of publishers pools rights and offers one license that covers the whole catalog, with usage tracking to divide the proceeds. Radio solved its version of this problem a century ago with ASCAP, and we told that story in full in what radio royalties teach publishers about getting paid by AI. RSL’s standard-license mechanism is designed to support the same shape: many publishers pointing at one shared license URL so a system that accepts the terms once gains access to everything under them.

None of these is the correct answer for every publisher. What they share is that all three depend on the receipt. A per-crawl model without receipts is an honor system. A per-inference model without receipts is impossible. A collective license without receipts cannot split a dollar fairly. The pricing debate is downstream of the measurement question, and the measurement question is answered by the transaction.

Why AI agents turn this into a deadline

Everything above would be worth building at a comfortable pace if AI systems only answered questions. They are starting to buy things.

In December 2025, Visa announced that hundreds of agent-initiated transactions had been completed in live production environments through its Intelligent Commerce program, with partners running end-to-end consumer and business purchases in closed beta. The same release reported that nearly half of U.S. shoppers already use an AI tool for at least one shopping task, and predicted that millions of consumers will use agents to complete purchases by the end of 2026.

Think about what an agent does before it buys. It researches. It compares. It reads reviews, specifications, guides, and the kind of explanatory content publishers produce. Then it pays a merchant, at machine speed, through a payment network built to clear that transaction in milliseconds with identity, authorization, and a receipt attached.

Every step of that purchase runs on infrastructure that knows who is buying and can prove what was bought. The content that informed the purchase runs on none of it. The agent will transact with the retailer through a system with receipts and read the buying guide that made the decision through a system without them. That asymmetry does not survive contact with money. The moment agents pay for the product, the question of paying for the content that sold it stops being abstract, and it has to be answered at the agent’s speed, because there is no slower speed available.

This is the same-day pairing with our Future of AI Commerce series for a reason. If an agent needs a payment network to buy, the content it relied on needs one too. The transaction described in this post is the content side of that network.

What has to exist for the loop to run

Strip it to components and the list is short.

The requester needs an identity that can be verified and billed. The content object needs rights attached to it directly, so the terms travel with the piece rather than with the site. A clearance service needs to sit between the two and issue or refuse permission in real time. And a ledger needs to record the outcome as a receipt that both parties can trust.

We have written before about why AI still has no system for paying for the content it uses, and the missing pieces named there, a rights standard, a transaction rail, and a receipt, map onto these components one for one. The difference now is that the rights standard exists in draft, the transaction rail is being built in the open by payment networks and standards bodies, and the receipt is the piece a publisher can start generating on their own side before anyone else agrees to anything.

What publishers can do now

You do not have to wait for the whole loop to be finished to start benefiting from it. Most of the work is on your side of the transaction anyway.

Start by inventorying what you own at the object level. Not “the archive” but the individual pieces, with a sense of which ones carry evergreen value and which ones are perishable. The transaction runs per object, so your catalog has to be legible per object.

Attach terms to those objects in a machine-readable format. RSL is the current option with the broadest publisher support and the simplest on-ramp, and it can live in robots.txt, in page headers, and in feeds without touching your content. Even if no system honors the terms tomorrow, publishing them establishes the record of what you asked for.

Decide your access policy deliberately rather than by default. Blocking everything protects the archive and deletes you from the answers; allowing everything makes you scenery with no leverage. There is a tiered middle, and we laid out the trade-offs in should publishers block AI crawlers.

Measure whatever you can measure today. Bot traffic by identified agent, retrieval patterns by page, referral traffic from AI answers. It is crude compared to a receipt, but it is the beginning of the meter, and it is evidence you will want at the next negotiation whether or not the transaction layer is live by then.

Keep the receipts you generate. Every logged access from an identified AI system is a data point about what your content is worth to that system. A year of those logs is a pricing model waiting to be written.

Where SAIL fits

Next Net built SAIL, the Standardized Agentic Intelligence Ledger, to be the transaction, receipt, and market intelligence layer for AI content rights. We are saying that plainly because it is our product and the rest of this post describes the problem it was designed for.

SAIL is built to sit at the clearance and receipt steps of the loop. It is designed to record each use of a rights-managed content object as a receipt, so that a publisher has a ledger of what was used, by which system, under which terms, rather than an estimate. It is designed to make usage-based pricing possible by making usage countable, and to give a publisher the evidence to price on rather than the guess to negotiate on.

It is also designed so that existing deals can be operationalized without renegotiation. A flat-fee agreement signed last year can start generating receipts this year, which means the renewal conversation happens with a meter reading in hand.

If you publish content that AI systems already use, the SAIL page for publishers walks through how the ledger works and what it takes to connect a catalog to it.

Frequently asked questions

How does AI pay for content today?

Mostly through flat-fee licensing agreements negotiated between an AI company and a publisher, covering a whole archive for a fixed period. A smaller share of content is accessed under no agreement at all. In neither case does the individual retrieval produce a payment or a record; the money, where it exists, is settled in advance and independent of use.

What is an AI content transaction?

A machine-speed license event with four steps: an AI system requests a specific content object, reads the terms attached to it, receives clearance to use it under those terms, and produces a receipt recording the use. It differs from a licensing deal in that it happens per object, per use, and without a human in the loop.

What is the difference between pay-per-crawl and pay-per-inference?

Pay-per-crawl charges when the AI system fetches the content, which fits training use. Pay-per-inference charges when the content shapes an answer, which fits retrieval-based systems that reuse the same content across many responses. Per-inference prices the value more accurately but requires a receipt at answer time rather than at crawl time.

Why is usage-based pricing better than a flat fee for AI licensing?

A flat fee prices the relationship before anyone can count the uses, so both sides are guessing. Usage-based pricing counts first and prices second, attaching rates to the pattern of retrievals rather than to a forecast. It only becomes possible once a receipt exists for each use, which is why measurement infrastructure comes before pricing reform.

Do AI agents change how content gets paid for?

Yes. Agents that complete purchases on a user’s behalf already run on payment infrastructure with identity, authorization, and receipts built in. The content those agents rely on to make buying decisions runs on none of that. As agentic commerce scales, the gap between how the product is paid for and how the content that sold it is paid for becomes impossible to ignore, and it has to close at the agent’s speed.

The short version

AI systems will pay for content the way every other machine-speed system pays for anything: through a transaction with a request, terms, clearance, and a receipt, settled per use rather than per deal. The standards for terms are here. The payment rails are being built by the networks that already move money for agents. The receipt is the piece still missing from most publishers’ side of the exchange, and it is the piece that turns being scenery into being paid.

That is the layer Next Net built SAIL to provide. If you want to see what your catalog looks like as a ledger instead of an archive, start with the publisher overview.