Article · 19 August 2026, rebuilt 26 August 2026, corrected 7 September 2026, corrected 14 September 2026 · 13 primary sources · Verified against source on 7 September 2026

Somebody built the field

An AI agent buys a pair of trainers on your behalf. Somebody recommended those trainers. Who gets paid?

Right now, nobody knows.

When I first looked at this, I thought the reason was that the field did not exist. That the people building the purchasing layer of the internet had simply forgotten that a lot of sales happen because somebody recommended something.

I was wrong, and I am glad I was, because the truth turns out to be far more interesting.

The field exists. There are 2 of them. One of them is called affiliate attribution and the example it gives is impact.com.

What none of them defines is a rule about who gets paid. And the people writing the specifications have said, in writing, that defining that is not their job.

The field exists. Twice.

There are 3 protocols shaping how an AI agent buys something on a person's behalf, and all 3 are live right now.

• UCP, the Universal Commerce Protocol, published by a consortium including Google, Shopify, Etsy, Walmart, Target, Amazon, Microsoft, Stripe and Visa.
• ACP, the Agentic Commerce Protocol, maintained by OpenAI and Stripe.
• AP2, the Agent Payments Protocol, governed by the FIDO Alliance.

2 of the 3 carry attribution.

ACP got there first, and went furthest. It carries a first-class object called affiliate_attribution, added on 14 January 2026 and described in its own schema as "Optional affiliate attribution data for crediting third-party publishers." Its changelog says it exists for "enabling agents to credit third-party publishers without relying on cookies or client-side tracking."

It has named, typed fields. provider. publisher_id. token. campaign_id. sub_id. A touchpoint that can be set to first or last. provider is required, and the example the specification gives is "(e.g., 'impact.com')".

An affiliate network is named in the specification. In January, before most of this industry had noticed the conversation was happening.

UCP followed on 5 May 2026 with something looser. Its attribution field carries "campaign identifiers, click IDs, source/medium markers" and appears on cart, checkout and catalogue requests. But it has no defined subfields at all. It is an open map of strings to strings, and the specification does not define what any key means. campaign_id appears only in a non-normative example.

A note on both of those dates, because each repository will tell you something different at first glance. ACP files its affiliate attribution work under a release labelled 2025-12-12, and UCP files its attribution field under a release labelled 2026-04-08. Neither label is a publication date. Both are version strings. ACP's object entered the repository on 14 January 2026, and the changelog file carrying the December label was written on 22 January 2026, when the project was reorganised into dated version folders, so the December release note describes work that did not exist in December. UCP's field arrived in pull request 391, opened on 27 April 2026 and merged on 5 May 2026, while the release tagged 2026-04-08 was published on 9 April 2026 and lists that pull request anyway, nearly a month before it was merged. I have dated both by the day the code arrived in the repository rather than by the label on the folder.

AP2 carries none of it. I searched its documentation and its code for attribution, affiliate, commission, campaign, referral, publisher and payout. No genuine matches, on 26 August 2026 and again on 2 September 2026. Its scope is proving a person authorised a payment, and it does not touch this.

So the picture I described in August was wrong. It was not that nobody had built the field.

What the field does not do

From UCP's own specification:

UCP does NOT prescribe attribution models, windows, or assignment logic.

And a few lines later: "Attribution is informational and optionally provided by the platform."

Informational. Optional. The field carries whatever the platform decides to put in it, to be processed by the merchant "according to their own analytics needs."

ACP is more explicit still, and more useful, because it lists what it is deliberately not doing. From its own Non-Goals:

Defining commission rates, payout schedules, or settlement rails.

And, in case there was any doubt about who resolves a disputed claim, this is what happens when 2 different providers each claim the same sale. Keep both. The network determines weighting. Each provider settles independently. And: "Servers MUST NOT block checkout due to attribution conflicts between touchpoints."

To an operator rather than a developer, that sentence says something else. The protocol will carry 2 competing claims to the same commission, all the way through the checkout, and it will not tell you which one is right. It is explicit that resolving that is somebody else's problem.

A field that carries a campaign ID is transport. It is not a rule about who gets paid.

That is the thing I missed the first time. I was looking for a missing field. The field was there. What is missing is the layer above it, and that gap is deliberate, documented and stated by the people who left it.

Why the existing plumbing still fails

None of this rescues the measurement.

Affiliate attribution rests on a click. A person clicks a tracked link, a cookie is set or a click ID is passed, the transaction fires against it, and the commission is owed.

An agent does none of that. It does not follow affiliate links and it does not carry cookies. It queries the storefront API directly, so no browser opens and no JavaScript runs. The pixel does not fire, the analytics do not record it, and the thank-you page is never loaded.

Every layer of measurement fails at the same moment, for the same reason.

The new fields are meant to solve exactly this. And they might. But look at how the carry-through is worded. On UCP, the order-level attribution is a "snapshot of the attribution associated with the originating checkout", and businesses MAY surface it. May, not must. A publisher relying on that data cannot assume it will be there.

Shopify, meanwhile, has done something quietly significant. Its agent documentation defines the fields UCP deliberately left anonymous:

Optional attribution metadata. Supported fields include referring_domain, click_id_tag, click_id_value, activity_id_tag, activity_id_value, utm_campaign, utm_source, utm_medium, utm_content, and utm_term.

10 named fields, on both cart and checkout, carried through to the order. Where UCP says any string key will do, Shopify has pinned it to the Google Analytics convention plus click and activity identifiers.

That is channel attribution. It tells you a campaign, a source and a medium. Neither affiliate nor commission appears anywhere in Shopify's agent documentation. It can tell you an AI sent the customer. It cannot tell you which creator, publisher or partner earned it.

One network is in the room

I wrote in August that nobody in affiliate was in the room. That was the line I was proudest of and it was the one that was most wrong.

impact.com is named in ACP's specification as the example attribution provider. Whether that came from a conversation, a submission or somebody's reasonable guess about who runs this infrastructure, I do not know and could not establish. But the name is in the document.

What I could not find, when I looked in August, was a published position from any single network. Not from Awin, CJ, Rakuten Advertising, impact.com or Partnerize. Individually, there is still nothing.

Collectively is a different answer, and I had been looking in the wrong place. Awin, CJ, Rakuten Advertising, Tradedoubler, Adtraction, Acceleration Partners and the APMA are all supporting members of OpenAttribution, a not-for-profit building open standards for AI content usage. In February it proposed a content attribution field to sit alongside ACP's affiliate attribution: where affiliate attribution says which publisher gets the credit, content attribution says which URLs the agent actually read, so a network can resolve the content owner afterwards. It published a content telemetry standard on 2 September 2026.

The proposal is not in either protocol. When I checked on 7 September 2026 I read the full history of both repositories and the string appeared in neither, on any branch, in any commit. So it is a position rather than a shipped field. But it is on the record, and the networks are behind it. A field that says which URL an agent read is still transport. It still does not say who gets paid.

For scale: UK affiliate and partner marketing is £1.8bn invested, £20.7bn in revenue and 357 million transactions a year, growing at 7.3%. All of it rests on being able to say who influenced a sale.

The specifications are being written now, in public, in repositories anybody can read. The attribution transport question has been settled twice, in January and in May, largely without this industry in the conversation. The settlement question is still open, and it is the one that decides whether a commission gets paid.

What would actually have to exist

3 things, and none of them are trivial.

A rule for who receives the credit. Not a field that carries a claim. A rule that resolves one. ACP will carry a first-touch claim from one provider and a last-touch claim from another through the same checkout, and it does not decide between them.

Coverage at any merchant, not only at the ones who adopted a particular protocol. A standard covering 40% of checkouts creates a worse problem than no standard at all, because now you have 2 sets of books.

Determinism. A probabilistic model can tell you an agent purchase was probably influenced by a creator. You cannot pay a commission on probably. You can measure with probability. You cannot settle with it.

ACP has done real work on the third one. Its token field is described as an "opaque provider-issued token for fraud-resistant validation", which is a serious attempt at making a claim verifiable rather than assertable. That is further than anybody else has gone.

The first 2 are untouched.

What I got wrong, and how

The first version of this article said no standard specified a field for who influenced a purchase. That was wrong when I published it, not wrong because things moved. ACP's field had been live for 7 months and UCP's for 3.

I had read summaries and guides rather than the specifications. The specifications are public, on GitHub, and take an afternoon to read properly. I made a second version of the same mistake later, taking a date off a folder name instead of reading the commit history behind it, which is what the note near the top of this article is about.

I have also removed 3 claims from the original version about the commercial performance of agentic commerce, because I could not stand any of them up to the standard the rest of this piece is held to. They may well be true. They are not sourced, so they are out.

The version you are reading was rebuilt from the schema files and the specification text directly. Every quotation above was read at source. If any of it is wrong, it is wrong because I misread a document, not because I did not open one.