How Agent Attribution Works: A Technical Primer
When an AI agent recommends a product and a user buys, how does anyone know which agent drove the sale? This is how agent attribution works — and why it requires a different architecture entirely.
How Agent Attribution Works: A Technical Primer
When a human clicks an affiliate link, tracking is straightforward. Cookies, click IDs, postbacks. It works. But when an AI agent recommends a product and a user buys — no click, no cookie, no browser — the chain breaks entirely. Agent attribution is what fills that gap. Here’s exactly how it works, and why you can’t solve it by patching existing affiliate infrastructure.
What Agent Attribution Is
Attribution means proof: proof that a specific agent drove a specific sale.
Traditional affiliate attribution relies on browser state. A tracking link sets a cookie; the cookie persists until the user converts; the network matches the cookie to the conversion. It’s fragile even for humans — ad blockers, private browsing, and ITP all degrade it — but at least the architecture fits. Browsers have state. Agents don’t.
Agent attribution is binary: did this agent’s signed offer lead to this conversion? Yes or no. There’s no middle ground, no probabilistic match, no “view-through window.” Either the cryptographically signed offer issued by Rako was redeemed at checkout, or it wasn’t.
The mechanism is straightforward. A merchant lists an offer via the Agent Attribution Protocol (AAP). Rako issues a cryptographically signed offer code tied to that merchant and offer. When a user purchases through an integrated flow, the production design verifies the payment event, checks the Ed25519 signature and payment details, and attributes the conversion — no user tracking, no cookies, no persistent identifiers.
This isn’t “better affiliate tracking.” It’s a fundamentally different architecture, built for a different execution environment.
A URL You Can’t Spoof
The AAP offer format looks like this:
aap://rako.sh/v1/offer/{merchant_id}/{offer_id}Compare that to a typical affiliate link: a 47-parameter URL with click IDs, subIDs, UTMs, and network-specific tokens — all designed to survive a cookie-based journey through a browser session.
The signed offer carries no user data. What it contains: merchant ID, offer ID, commission terms, expiry timestamp, and an Ed25519 signature issued by Rako’s signing infrastructure. The signature proves the offer is legitimate and hasn’t been tampered with.
Here’s how an agent uses it in practice. The agent queries Rako’s MCP server or REST API to discover available offers for a given product category. Rako returns ranked signed offers for matching merchants. The agent recommends the best match to the user, with the signed offer code embedded in its response. In the production verification model, the user purchases through an integrated checkout, Rako authenticates the payment event, verifies the signature and payment details, and then attributes the conversion.
No fingerprinting. No session replay. The protocol is verifiable, not probabilistic — which is the only kind of attribution that scales when the entity making the recommendation is software, not a human with a browser.
Three commission-accounting models
Once attribution is confirmed, commission accounting can follow different models — each with different trust assumptions, payment-provider dependencies, and legal/commercial review requirements.
Level 1 — Merchant-reported: The merchant’s own system tells Rako when a qualifying conversion happens. Lowest friction to onboard, highest trust required. Equivalent to how most affiliate networks work today, but with cryptographic attribution rather than cookie-based matching.
Level 2 — Payment-observed: Rako’s infrastructure can be connected to merchant payment-flow evidence. Once the full verification gate is deployed and accepted, Rako can verify when a qualifying transaction completes and support post-transaction commission accounting. The merchant’s payment provider still executes the payment.
Level 3 — Payment-split: A future model may support commission split mechanics closer to transaction clearing. This requires provider support, legal review, and explicit approval before it should be treated as a live Rako capability.
Rako provides attribution and verification infrastructure. Payment handling depends on the merchant’s selected payment provider and the approved integration model.
Why Agent Attribution Is the Incentive Mechanism
Agents have no intrinsic reason to recommend your products. Without attribution, there’s no payment. Without payment, there’s no commission. Without commission, agents recommend based on training data patterns, not on merchant quality or deal relevance.
The signed offer model creates a closed loop: merchant lists offer → agent discovers and recommends → user purchases → developer earns commission → agent has a structural reason to recommend again. Remove any link in that chain and the whole thing collapses into either opaque recommendations or explicit ads — neither of which is what merchants or users want.
Attribution isn’t just an analytics problem. It’s the incentive mechanism that makes agent commerce a sustainable channel rather than a traffic anomaly.
For more on why an open protocol is the right architecture for this, see Why Agent Attribution Needs an Open Standard and Affiliate Marketing Wasn’t Built for AI Agents.
What This Means for Merchants
The agent economy is already here. Shopify data shows 15x growth in agent-originated traffic in the past year. The question isn’t whether AI agents will recommend products — they already do. The question is whether merchants have the infrastructure to get attributed when they do.
Rako is speaking with merchants about beta onboarding. Early participants can help shape offer structuring, commission terms, and the verification model that fits their checkout stack. Level 1 starts with merchant-reported conversion evidence; Level 2 depends on payment-provider evidence and production verification gates before it should be treated as verified payment-observed attribution.
If you’re building an agent or MCP server, the SDK is at npm:@rakohq/mcp. If you’re a merchant, start at rako.sh/merchants.
Agent attribution is the infrastructure layer the agent economy needs. AAP is the open protocol. Rako is building the registry, signed-offer issuance, and attribution verification layer; commission handling is subject to merchant terms and accepted verification evidence.