{
 "acronym": "AAP",
 "adoption": {
  "by": null,
  "level": "unmeasured",
  "probe_run": null
 },
 "aliases": [],
 "analog": "affiliate/referral tracking, reinvented for agents that don't click links or carry cookies",
 "collisions": [
  "Agent Authorization Profile (also abbreviated AAP, IETF OAuth draft, unrelated)",
  "AAMP (Agentic Advertising Management Protocols, unrelated, different acronym but easily confused)"
 ],
 "discovery": {
  "mechanism": "none",
  "path": null
 },
 "dispute": {
  "claims": [
   "Vendor calls it 'the open standard'; the spec's own text says trust is centralised in one company (Rako).",
   "Acronym collision with the existing 'aap' record (Agent Authorization Profile, IETF) is a real risk of confusion on this site."
  ],
  "summary": "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."
 },
 "evidence": [
  {
   "claim": "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.",
   "date": "2026-09-05",
   "label": "VERIFIED",
   "url": "https://rako.sh/aap"
  },
  {
   "claim": "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.",
   "date": "2026-04-02",
   "label": "VERIFIED",
   "url": "https://raw.githubusercontent.com/rakohq/aap-spec/main/spec/v1/README.md"
  },
  {
   "claim": "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.",
   "date": "2026-09-05",
   "label": "VERIFIED",
   "url": "https://rako.sh/docs"
  }
 ],
 "form": "endpoint",
 "governance": "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'",
 "group": null,
 "history": [
  {
   "date": "2026-09-06",
   "note": "new record: found via search for post-hoc agent commerce attribution specs; verified against rako.sh/aap, rako.sh/docs, and github.com/rakohq/aap-spec (README, spec/v1/README.md); flagged as single-vendor 'open spec, closed operation' and acronym collision"
  }
 ],
 "id": "agent-attribution-protocol",
 "implementation": "shipping",
 "last_verified": "2026-09-06",
 "name": "Agent Attribution Protocol",
 "native_status": "\"The open standard for AI agent affiliate attribution\" (vendor's own description); v1.0 spec published, centrally operated",
 "origin": {
  "date": "2026-04-02",
  "org": "Rako (RAKO HQ LTD, UK company no. 17132612)"
 },
 "part_of": null,
 "parties": [
  "agent-payment"
 ],
 "phase": "stable",
 "probe": {
  "method": "POST",
  "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.",
  "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.",
  "path": "https://api.rako.sh/v1/recommend"
 },
 "question": "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?",
 "scope": "commerce",
 "spec_url": "https://github.com/rakohq/aap-spec",
 "step": "account",
 "summary_md": "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.\n\n**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].\n\n**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.\n\n**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].\n\n**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.\n\n**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.",
 "track": "single-vendor",
 "version": {
  "date": "2026-04-02",
  "label": "v1.0"
 }
}