agenticweb.wiki

Agent Attribution Protocol AAP

By Belgravia Labs Standards Observatory · Last verified · 3 primary sources

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.

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 [1][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.

Overview

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 [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 [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' [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 [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.

Discovery and probe

none

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.

Not probed live: needs-credentials. The probe is a vendor API call that needs an API key.

Instances

Every instance with its source is listed on the instances page.

Verified SDKs, reference implementations & validators:

See also

Comparisons

References

  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 (2026-09-05) VERIFIED
  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 (2026-04-02) VERIFIED
  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 (2026-09-05) VERIFIED

Disputed: AAP calls itself 'the open standard' and publishes its spec text under Apache-2.0, but by its own README it has a 'centralised trust model': Rako alone issues and signs the AAP Code, operates the offer registry, and administers commission settlement. This is architecturally closer to a single-vendor affiliate network with a published API than a neutral standard multiple independent operators can run -- readers should weigh 'open spec, closed operation' when comparing it to IETF/W3C-track account specs. It also acronym-collides with both the pre-existing site record 'aap' (Agent Authorization Profile, an unrelated IETF OAuth draft) and, loosely, with IAB Tech Lab's AAMP.

Verification log and errata

JSON · Markdown · OKF v0.2

Frequently asked questions

What is Agent Attribution Protocol (AAP)?
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.
What is the adoption and standardization status of Agent Attribution Protocol?
"The open standard for AI agent affiliate attribution" (vendor's own description); v1.0 spec published, centrally operated, governed by Single vendor (Rako); the spec text is published under Apache-2.0, but issuance, verification and settlement are centrally operated by Rako, which the spec calls the 'Protocol Authority'. Implementation: shipping. Version: v1.0 (2026-04-02). Last verified 2026-10-29.
How does Agent Attribution Protocol compare to other account protocols?
Agent Attribution Protocol (AAP) is one of 7 standards at step 9, Account (Prove what happened; be judged). It pairs with Model Context Protocol, Agentic Commerce Protocol, Universal Commerce Protocol (UCP), Agent Payments Protocol (AP2). Head-to-head comparisons on this site: Cookies, Syslog & T&Cs vs Agent Attribution, OTel GenAI & SCITT, CoMP (Content Monetization Protocols). Every standard at this step is listed at https://agenticweb.wiki/category/account/.