Software increasingly makes recommendations on a person's behalf. The monetization infrastructure underneath it was built for humans clicking links on web pages, and the mismatch is starting to show.
The assumption that no longer holds
Affiliate infrastructure assumes a browser. It assumes cookies that persist, a referrer header, a page the publisher controls where a disclosure can sit, and a human who clicks. An assistant answering “what's the best CRM for a ten-person team?” has none of those reliably. The conversation may happen in a native app, the link may open in a system browser with no shared cookie jar, and there is no page in the traditional sense.
This is not a reason to keep agents out. It is a reason the plumbing needs to change.
Intent, not offer IDs
A traditional publisher decides in advance what to promote: they write a review, pick the offers, embed the links. An agent cannot work that way. It learns what the user needs during the conversation, and it needs to ask a question it could not have anticipated.
That inverts the API. Instead of fetch offer 4471 and give me a link, the useful call is here is the user's intent, their country, and the category — what am I eligible to recommend, and on what terms? The response has to include the commercial model, not just the payout, because an agent needs to know whether it is looking at a one-off commission or recurring revenue before it decides whether an offer is even relevant.
Eligibility has to come back with the offer
A human publisher can read a program's terms once and remember them. An agent cannot be trusted to have read a PDF. So eligibility has to travel with the data: which countries, which traffic sources, whether this particular integration is permitted to promote this particular program at all.
If the API returns an offer the caller is not allowed to promote, the caller will promote it. Filtering must happen server-side, before the agent ever sees the record. Anything else pushes a compliance obligation onto a caller that has no way to discharge it.
Disclosure is a product requirement
The FTC Endorsement Guides, the UK CAP Code and their equivalents require that a material connection be disclosed clearly and conspicuously. That obligation does not weaken because the recommendation came from a model.
In a chat interface there is no sidebar and no footer to hide it in. Disclosure has to be part of the response the user reads, and the API should make that easy — by returning the fact that an offer is commercial in a structured field the calling application can act on, rather than leaving the agent to infer it.
There is a commercial argument here too, not only a legal one. An assistant that quietly steers users toward whatever pays most will be found out, and the backlash will land on the infrastructure as much as the application. Transparent monetization is the only version of this that survives contact with scrutiny.
Attribution without cookies
If the handoff from agent to merchant crosses an app boundary, cookie-based attribution is unreliable. What works is a stable identifier minted at link-generation time, carried in the URL, and reconciled server-side when the conversion postback arrives. The identifier has to survive the provider's parameter naming and length limits — which, as anyone who has integrated two networks knows, is not a given.
This is also what makes the model acceptable to the networks. A provider that can see which downstream application produced a conversion can police it. One that cannot, will eventually refuse the traffic, and will be right to.
Machine-readable, all the way down
If an agent is the consumer, then the documentation is part of the API. A typed description of the endpoints, the auth scheme and the response shapes — an OpenAPI document, tool schemas over MCP — is not a nice-to-have. It is how the caller discovers what it can do without a human reading a docs site and writing a wrapper.
What this adds up to
None of these requirements are exotic. Intent-based discovery, server-side eligibility filtering, structured disclosure signals, cookieless attribution and machine-readable descriptions are all things the existing ecosystem could adopt. But they have to be adopted together, because each one fails on its own: eligibility filtering without attribution is unenforceable, attribution without disclosure is untrustworthy, and machine-readable docs over an API that still assumes a browser just make the mismatch easier to hit.