--- type: Agentic Web Standard title: "Agent Attribution Protocol" description: "When an AI agent recommends a product and a sale happens later, on another device or session, can anyone prove which agent (and which recommendation) actually drove it?" resource: "https://github.com/rakohq/aap-spec" tags: ["account", "endpoint", "single-vendor", "attribute-agent-traffic", "agent-checkout", "audit-agent-actions"] status: stable generated: { by: agenticweb-builder/1.0, at: 2026-10-30T00:00:00Z } verified: { by: process:agenticweb-engine, at: 2026-10-29T00:00:00Z } stale_after: 2026-11-28T00:00:00Z sources: - id: ref-1 resource: "https://rako.sh/aap" title: "rako.sh/aap markets AAP as 'the protocol layer for recording agent recommendations, matching later conversions, and creating cleaner attribution across merchants, agents, and platforms,' with example recommendation.event and conversion.event JSON payloads and a signed 'AAP Code' as the core primitive." last_modified: 2026-09-05T00:00:00Z - id: ref-2 resource: "https://raw.githubusercontent.com/rakohq/aap-spec/main/spec/v1/README.md" title: "The canonical public specification repository (Apache-2.0, created 2026-04-02) documents AAP v1.0: a session lifecycle (CREATED to SETTLED/DISPUTED/CLAWED_BACK), a signed AAP Code, binary (all-or-nothing) attribution, and states plainly that AAP 'is an open spec with a centralised trust model' where 'issuance, verification, and settlement are operated by Rako.' The README also flags a live UK trademark application (UK00004367937) on the name." last_modified: 2026-04-02T00:00:00Z - id: ref-3 resource: "https://rako.sh/docs" title: "rako.sh/docs shows working developer integration paths -- an MCP server package (@rakohq/mcp), a published npm SDK (@rakohq/sdk) and a published PyPI package (agent-attribution-protocol) -- each exposing search/recommend/checkout calls against api.rako.sh, indicating a deployed, callable service rather than a paper spec only." last_modified: 2026-09-05T00:00:00Z --- # Agent Attribution Protocol Agent Attribution Protocol (AAP) is an agentic-web standard (endpoint) at step 9, Account, governed by Single vendor; its status is "The open standard for AI agent affiliate attribution". It answers: "When an AI agent recommends a product and a sale happens later, on another device or session, can anyone prove which agent (and which recommendation) actually drove it?" Implementation status is shipping, last verified 2026-10-29. # Overview The Agent Attribution Protocol (AAP) is a commerce-attribution scheme built by Rako, a UK company, so that when an AI shopping agent recommends a product and a user buys it later -- on a different device, browser, or after a delay -- the agent's role in driving that sale can be proven and a commission paid [^ref-1][^ref-2]. It replaces cookie- and click-based affiliate tracking, which does not work for agents that recommend inside a conversation rather than generating a clickable link. This is squarely an 'account' spec: its entire function is producing a verifiable record, after the fact, of what an agent did and whether it should be credited/paid for it. **How it works.** An agent calls a `search` endpoint for offers, gets back a session and offers carrying a Rako-signed 'AAP Code'; when the agent recommends one to the user, it calls `recommend()`, which is the attribution event -- logged server-side, not via a cookie or link click. A later `checkout()`/merchant-reported conversion is matched back to that recommendation via the session, and commission is calculated and settled under merchant terms [^ref-2]. The session lifecycle (CREATED, ACTIVE, CHECKOUT, CONVERTED, VALIDATED, SETTLED, with CANCELLED/CLAWED_BACK/DISPUTED/RESOLVED branches) and a 24-hour session expiry are explicitly defined [^ref-2]. **What it does not do.** AAP is not a neutral, multi-operator standard: by its own specification text, 'issuance, verification, and settlement are operated by Rako' as the sole 'Protocol Authority' [^ref-2]. There is no independent verifier, no federation model, and no way for a second company to run a conformant AAP issuer today. It also does not define a discovery mechanism (a merchant or agent has to integrate Rako's SDK/MCP server directly), and commission math in the spec is illustrative ("examples in this spec use a 20% network-fee model for illustration"), not fixed. **Current state.** The public spec repository was created 2026-04-02 and is versioned v1.0; working developer tooling exists today -- an MCP server (@rakohq/mcp), a JavaScript/TypeScript SDK (@rakohq/sdk on npm) and a Python SDK (agent-attribution-protocol on PyPI) -- all calling a live api.rako.sh backend, so this is a shipping, callable service rather than a paper spec [^ref-3]. **Who implements it.** Rako operates the only known implementation (issuer, registry and SDKs). No independent merchant, agent-platform or competing issuer implementation was found in the sources checked. **Disputed / unknown.** No independent adoption figures (merchants, agents, or transaction volume) are published; adoption is marked unmeasured. "Agent Attribution Protocol" is the subject of a live UK trademark application (UK00004367937) per the spec's own README, and the acronym AAP collides with this site's pre-existing 'aap' record (Agent Authorization Profile, an unrelated IETF OAuth draft) -- readers should not confuse the two. # Examples ```http POST https://api.rako.sh/v1/recommend # parse: A successful response with a signed 'AAP Code' and an 'attribution_id'/'recommendation_id' confirms a live Rako-operated AAP session; requires a valid API key, so this probe can confirm the service exists but cannot enumerate third-party agents using it without their cooperation. # on absent: 401/403 without a key is expected and does not indicate absence; a connection failure or 404 would indicate the service is down or the endpoint has moved. ``` # Knowledge Graph * **Lifecycle Step**: [9 Account](/category/account/index.md) * **Pairs with**: [Model Context Protocol](/okf/protocols/mcp.md), [Agentic Commerce Protocol](/okf/protocols/agentic-commerce-protocol.md), [Universal Commerce Protocol (UCP)](/okf/protocols/ucp.md), [Agent Payments Protocol (AP2)](/okf/protocols/ap2.md), [Agent Audit Trail](/okf/protocols/agent-audit-trail.md) * **Compared in**: [Cookies, Syslog & T&Cs vs Agent Attribution, OTel GenAI & SCITT (classic vs agentic)](/compare/cookies-syslog-vs-agent-audit-trail/index.md), [Agent Attribution Protocol vs CoMP (Content Monetization Protocols)](/compare/agent-attribution-protocol-vs-iab-comp/index.md) [^ref-1]: rako.sh/aap markets AAP as 'the protocol layer for recording agent recommendations, matching later conversions, and creating cleaner attribution across merchants, agents, and platforms,' with example recommendation.event and conversion.event JSON payloads and a signed 'AAP Code' as the core primitive. (https://rako.sh/aap) [^ref-2]: The canonical public specification repository (Apache-2.0, created 2026-04-02) documents AAP v1.0: a session lifecycle (CREATED to SETTLED/DISPUTED/CLAWED_BACK), a signed AAP Code, binary (all-or-nothing) attribution, and states plainly that AAP 'is an open spec with a centralised trust model' where 'issuance, verification, and settlement are operated by Rako.' The README also flags a live UK trademark application (UK00004367937) on the name. (https://raw.githubusercontent.com/rakohq/aap-spec/main/spec/v1/README.md) [^ref-3]: rako.sh/docs shows working developer integration paths -- an MCP server package (@rakohq/mcp), a published npm SDK (@rakohq/sdk) and a published PyPI package (agent-attribution-protocol) -- each exposing search/recommend/checkout calls against api.rako.sh, indicating a deployed, callable service rather than a paper spec only. (https://rako.sh/docs)