[ { "acronym": "MCP", "adoption": { "by": "Wikipedia (OpenAI, Google DeepMind adopted MCP by March 2025) and WorkOS ('adopted by OpenAI, Google DeepMind, Microsoft, and thousands of development teams')", "level": "claimed", "probe_run": null }, "aliases": [], "analog": "Language Server Protocol", "collisions": [ "Microsoft Cloud Partner", "Master Control Program" ], "discovery": { "mechanism": "Capability negotiation during the JSON-RPC initialize handshake over a streamable-HTTP or stdio transport; optional static Server Card for pre-connection discovery", "path": "GET {endpoint}/server-card (SEP-2127, experimental, not yet part of the accepted core spec)" }, "dispute": null, "evidence": [ { "claim": "Canonical dated specification is 2026-07-28; MCP is a JSON-RPC 2.0 protocol standardizing how hosts, clients, and servers share resources, prompts, and tools, with optional extensions (Tasks, Skills over MCP, MCP Apps).", "date": "2026-07-28", "label": "VERIFIED", "url": "https://modelcontextprotocol.io/specification/2026-07-28/index" }, { "claim": "OpenAI officially adopted MCP in March 2025 (ChatGPT desktop app integration) and added MCP support to ChatGPT apps in September 2025; MCP integrates with Microsoft Semantic Kernel and Azure OpenAI.", "date": "2026", "label": "VERIFIED", "url": "https://en.wikipedia.org/wiki/Model_Context_Protocol" }, { "claim": "MCP has become the de facto protocol for connecting AI to external tools and data, adopted by OpenAI, Google DeepMind, Microsoft, and thousands of development teams as of 2026.", "date": "2026", "label": "REPORTED", "url": "https://workos.com/blog/everything-your-team-needs-to-know-about-mcp-in-2026" }, { "claim": "The MCP Server Card is defined by SEP-2127, tracked as an experimental extension (modelcontextprotocol/ext-server-card), reserving GET /server-card as the recommended discovery location; it is explicitly NOT an accepted or official MCP extension as of this check, and discovery is intended to route through AI Catalog entries rather than a fixed /.well-known/ path.", "date": "2026-08-12", "label": "VERIFIED", "url": "https://github.com/modelcontextprotocol/experimental-ext-server-card" }, { "claim": "The MCP GitHub org publishes ten official/community SDKs tiered 1-3 (TypeScript, Python, C#, Go, Rust = Tier 1; Java, Ruby = Tier 2; Swift, PHP, Kotlin = Tier 3); the Python SDK has 24.2k GitHub stars and the TypeScript SDK 13.3k, both far larger than any competing protocol's SDK repos checked in this pass.", "date": "2026", "label": "VERIFIED", "url": "https://modelcontextprotocol.io/docs/2026-07-28/sdk" }, { "claim": "The MCP Registry (modelcontextprotocol/registry) is the official server registry, with 7.2k GitHub stars and 979 forks as of this check.", "date": "2026-09", "label": "VERIFIED", "url": "https://github.com/modelcontextprotocol/registry" }, { "claim": "MCP Apps is an accepted extension (distinct from the experimental Server Card) letting servers return sandboxed-iframe interactive UI; it is supported by Claude, Claude Desktop, VS Code GitHub Copilot, Microsoft 365 Copilot, Goose, Postman, MCPJam, and Archestra.AI, and is also the standard OpenAI's ChatGPT plugin UI builds on.", "date": "2026", "label": "VERIFIED", "url": "https://modelcontextprotocol.io/docs/extensions/apps" } ], "form": "endpoint", "governance": "Agentic AI Foundation (Linux Foundation umbrella); day-to-day spec work in the modelcontextprotocol GitHub org via public SEPs (Specification Enhancement Proposals) and working groups", "group": null, "history": [ { "date": "2026-09-05", "note": "seeded from Exa Agent research run" }, { "date": "2026-09-06", "note": "verified against modelcontextprotocol.io/specification/2026-07-28, github.com/modelcontextprotocol/experimental-ext-server-card, github.com/modelcontextprotocol/registry, modelcontextprotocol.io/docs/2026-07-28/sdk, modelcontextprotocol.io/docs/extensions/apps, en.wikipedia.org/wiki/Model_Context_Protocol, workos.com MCP-2026 blog" } ], "id": "mcp", "implementation": "multi-implementation", "last_verified": "2026-09-06", "name": "Model Context Protocol", "native_status": "Active open specification, current dated release 2026-07-28", "origin": { "date": "2024-11", "org": "Anthropic" }, "part_of": null, "parties": [ "agent-site" ], "phase": "living", "probe": { "method": "POST", "on_absent": "connection refused, 404, or a non-JSON-RPC response means no MCP server is exposed at that endpoint; a Server Card GET at {endpoint}/server-card returning JSON is a weaker, static signal since Server Cards are still experimental (SEP-2127)", "parse": "JSON-RPC 2.0 request {\"method\":\"initialize\",...}; on success, response.result.protocolVersion (e.g. \"2026-07-28\") and response.result.serverInfo.name prove an MCP server is present", "path": "{endpoint}/mcp" }, "question": "How does an AI application call tools and pull structured context, prompts, and data from an external server?", "scope": "general", "spec_url": "https://modelcontextprotocol.io/specification/2026-07-28/index", "step": "act", "summary_md": "The Model Context Protocol (MCP) is a JSON-RPC 2.0 based protocol that lets an AI \"host\" application (an IDE, a chat client) connect, through a \"client\" it embeds, to one or more \"servers\" that expose tools (functions the model can call), resources (data or content), and prompts (reusable templates) [1]. It also defines client-side elicitation (a server asking the user a question) and utilities for progress, cancellation, and structured errors. Anthropic published the first version in November 2024; the current dated release is 2026-07-28 [1].\n\nMCP solves the M×N integration problem: rather than every AI application writing bespoke connectors to every tool and data source, both sides implement one protocol once, similarly to how the Language Server Protocol standardized editor-to-language-server integration [1]. It is transport-agnostic (stdio for local processes, streamable HTTP for remote servers) and stateless per request, with capabilities negotiated during an `initialize` handshake.\n\nMCP does not itself define a stable, machine-readable way to discover a server before connecting to it, nor does it define an interactive-UI format — those live in separate, still-maturing extensions. The \"MCP Server Card\", meant to let a client learn a server's identity and remote endpoints via a well-known static document, is defined only by SEP-2127, tracked in an explicitly experimental repository (`modelcontextprotocol/ext-server-card`) that states plainly it is \"not an accepted or official MCP extension\" [4]. Its reserved discovery location is `GET /server-card`, not `/.well-known/mcp` or `/.well-known/mcp.json` as some third-party guides describe for an earlier, now-superseded proposal (SEP-1649) — this row's probe uses the JSON-RPC `initialize` call instead, since that is the only mechanism guaranteed by the accepted spec. By contrast, MCP Apps — a separate extension for sandboxed-iframe interactive UI returned by tools — has graduated to accepted-extension status and has multi-vendor host support (Claude, VS Code Copilot, Microsoft 365 Copilot, Goose, Postman, and others) [7].\n\nAs of September 2026, MCP is implemented by ten official SDKs spanning three support tiers, with the Python SDK alone carrying 24,200+ GitHub stars, and by an official cross-language server registry (7,200+ stars) [5][6]. Adoption is broad but the strongest public claims are secondary, not counted: Wikipedia states OpenAI adopted MCP in ChatGPT's desktop app in March 2025 and extended support to ChatGPT apps in September 2025, and that Microsoft integrates it with Semantic Kernel and Azure OpenAI [2]; WorkOS separately describes MCP as adopted by \"OpenAI, Google DeepMind, Microsoft, and thousands of development teams\" [3]. No systematic, third-party-run census of live MCP servers was located in this pass, so adoption here is recorded as `claimed` (by those two secondary sources) rather than `measured`.\n\nGovernance sits with the Agentic AI Foundation under the Linux Foundation, with day-to-day specification work happening in public via SEPs (Specification Enhancement Proposals) and topic-specific working groups (e.g. the Server Card working group) in the `modelcontextprotocol` GitHub org — this is a materially more open, standards-body-adjacent process than the seed record's placeholder \"Agentic AI Foundation / Linux Foundation\" implied but did not source. What remains genuinely unsettled: whether Server Cards graduate from experimental status, and whether any independent org will publish a measured adoption count rather than vendor and press claims.", "track": "linux-foundation", "version": { "date": "2026-07-28", "label": "2026-07-28" } }, { "acronym": "A2A", "adoption": { "by": "Linux Foundation", "level": "claimed", "probe_run": null }, "aliases": [ "A2A Protocol" ], "analog": "none", "collisions": [ "Account-to-Account payments (A2A, banking)" ], "discovery": { "mechanism": "Agent Card", "path": "/.well-known/agent-card.json" }, "dispute": null, "evidence": [ { "claim": "A2A v1.0.0 specification defines JSON-RPC 2.0 over HTTP(S), the Agent Card discovery document, and the well-known path /.well-known/agent-card.json per RFC 8615.", "date": "2026-09-05", "label": "VERIFIED", "url": "https://a2a-protocol.org/latest/specification/" }, { "claim": "The A2A Protocol project is an open source project under the Linux Foundation, contributed by Google, licensed Apache 2.0. Official SDKs exist for Python (a2a-sdk), Go, JavaScript, Java, .NET, and Rust, maintained under the a2aproject GitHub org.", "date": "2026-09-05", "label": "VERIFIED", "url": "https://raw.githubusercontent.com/a2aproject/A2A/main/README.md" }, { "claim": "On its one-year anniversary (announced 2026-04-09), the A2A Protocol project stated it had surpassed 150 supporting organizations and cited integration in major cloud platforms and enterprise production use.", "date": "2026-04-09", "label": "VERIFIED", "url": "https://www.prnewswire.com/news-releases/a2a-protocol-surpasses-150-organizations-lands-in-major-cloud-platforms-and-sees-enterprise-production-use-in-first-year-302737641.html" } ], "form": "endpoint", "governance": "Linux Foundation (A2A Project); contributed by Google", "group": null, "history": [ { "date": "2026-09-05", "note": "seeded from Exa Agent research run" }, { "date": "2026-09-06", "note": "verified against a2a-protocol.org/latest/specification/, github.com/a2aproject/A2A README and agent-discovery.md, and the LF/A2A one-year press release (prnewswire)" } ], "id": "a2a", "implementation": "multi-implementation", "last_verified": "2026-09-06", "name": "Agent2Agent Protocol", "native_status": "Stable, v1.0.0", "origin": { "date": "2025-04-09", "org": "Google" }, "part_of": null, "parties": [ "agent-agent" ], "phase": "stable", "probe": { "method": "GET", "on_absent": "404 or non-JSON response means no public Agent Card is hosted at this well-known path; the origin may still run A2A behind auth or a registry", "parse": "JSON body with name, url (A2A service endpoint), and skills[] fields present confirms an A2A server", "path": "{origin}/.well-known/agent-card.json" }, "question": "How do two independent agents, built on different frameworks, discover each other and delegate a task to completion?", "scope": "general", "spec_url": "https://a2a-protocol.org/latest/specification/", "step": "coordinate", "summary_md": "Agent2Agent (A2A) is an open protocol for two independent AI agents — potentially built on different frameworks, by different companies, running on separate servers — to discover each other's capabilities and collaborate on a task without either exposing its internal memory, tools, or proprietary logic [1]. It solves agent-to-agent interoperability at the application layer: an A2A server publishes a JSON \"Agent Card\" describing its identity, service endpoint, supported interaction modes (sync request/response, Server-Sent Events streaming, async push notifications), and skills; a client agent fetches that card, then exchanges JSON-RPC 2.0 messages over HTTP(S) to create and drive a task to completion [1]. Standard discovery is the well-known URI `https://{domain}/.well-known/agent-card.json`, per RFC 8615; the spec also allows curated-registry discovery (no standard registry API is prescribed) and direct/hardcoded configuration [1].\n\nA2A does not itself define a registry protocol, a payment mechanism, or a UI-rendering format — those are left to other layers (registries, x402/agentic-commerce specs, and UI-negotiation extensions respectively). It also does not replace intra-agent tool-calling protocols such as MCP; A2A and MCP are commonly described by the project as complementary.\n\nGoogle announced A2A on 2025-04-09 with 50+ launch partners and donated it to the Linux Foundation later in 2025 [2]. The specification reached v1.0.0 and is now labeled stable on the project's own documentation site [1]. At its one-year mark (2026-04-09) the project's press release claimed more than 150 supporting organizations, integration into major cloud platforms (the release names Google Cloud, Microsoft, and AWS), and active production deployments in supply chain, financial services, insurance, and IT operations [3] — this adoption count is a claim by the Linux Foundation/A2A project itself, not an independently measured probe count, so it is recorded here as \"claimed,\" not \"measured.\"\n\nOfficial SDKs are published for Python, Go, JavaScript, Java, .NET, and Rust under the `a2aproject` GitHub organization, and the project lists integrations from frameworks including Google ADK, LangGraph, and IBM's BeeAI [2]. What remains open/disputed: the spec explicitly does not standardize a registry API for curated discovery, leaving that to individual deployments; and no third-party, methodology-disclosed count of live A2A servers (as opposed to \"supporting organizations\") was found as of this verification pass.", "track": "linux-foundation", "version": { "date": "2026-01", "label": "1.0.0" } }, { "acronym": "ACP", "adoption": { "by": null, "level": "unmeasured", "probe_run": null }, "aliases": [], "analog": "Language Server Protocol", "collisions": [ "Agent Communication Protocol (IBM)", "Agentic Commerce Protocol (OpenAI/Stripe)", "Agent Connect Protocol (AGNTCY)" ], "discovery": { "mechanism": "ACP Registry (a standard way for ACP clients to discover, install, and configure compatible agents, stabilized 2026-03-09); locally, agents run as editor sub-processes over stdio JSON-RPC", "path": "none fixed; local agents are launched as sub-processes, remote agents connect over HTTP or WebSocket (remote support still a work in progress)" }, "dispute": null, "evidence": [ { "claim": "ACP standardizes communication between code editors/IDEs and coding agents for both local (stdio sub-process) and remote (HTTP/WebSocket, still in progress) scenarios; it reuses MCP's JSON representations where possible and adds coding-UX-specific types such as diffs.", "date": "2026", "label": "VERIFIED", "url": "https://agentclientprotocol.com/get-started/introduction" }, { "claim": "ACP v2 protocol documentation and schema were published in Draft form on 2026-07-20; governance is a Zed-led design team using a public RFD (Request for Dialog) process, with Sergey Ignatov of JetBrains joining as Lead Maintainer on 2026-02-18 and an ACP Registry stabilized 2026-03-09.", "date": "2026-07-20", "label": "VERIFIED", "url": "https://agentclientprotocol.com/updates" }, { "claim": "Governance is explicitly a 'design team with the Zed team as the lead (BDFL)'; RFDs are ACP's RFC-equivalent process, licensed Apache 2.0, discussed on Zulip and via GitHub PRs.", "date": "2026", "label": "VERIFIED", "url": "https://agentclientprotocol.com/rfds/about" } ], "form": "endpoint", "governance": "Zed Industries acts as BDFL/design-team lead over a public Request for Dialog (RFD) process; Sergey Ignatov (JetBrains) joined as a second Lead Maintainer on 2026-02-18, reflecting growing Zed/JetBrains collaboration", "group": "Protocols called ACP", "history": [ { "date": "2026-09-05", "note": "seeded from Exa Agent research run" }, { "date": "2026-09-06", "note": "verified against agentclientprotocol.com/get-started/introduction, agentclientprotocol.com/updates, agentclientprotocol.com/rfds/about" }, { "date": "2026-09-06", "note": "collisions updated to add Agent Connect Protocol (Cisco/AGNTCY), verified against github.com/agntcy/acp-spec, spec.acp.agntcy.org" } ], "id": "agent-client-protocol", "implementation": "multi-implementation", "last_verified": "2026-09-06", "name": "Agent Client Protocol", "native_status": "v1 stable and shipping; v2 published in Draft form as of 2026-07-20", "origin": { "date": "2025", "org": "Zed Industries" }, "part_of": null, "parties": [ "agent-site" ], "phase": "stable", "probe": { "method": "stdio", "on_absent": "process exits, writes non-JSON-RPC output, or times out: the binary does not speak ACP", "parse": "response result containing protocolVersion and agentCapabilities confirms an ACP-speaking agent", "path": "spawn {agent-binary} and send a JSON-RPC 2.0 initialize request per the ACP schema over stdin/stdout" }, "question": "How does a code editor invoke and converse with an interchangeable coding agent it did not build?", "scope": "coding-tools", "spec_url": "https://agentclientprotocol.com/get-started/introduction", "step": "act", "summary_md": "The Agent Client Protocol (ACP) standardizes how a code editor or IDE talks to a coding agent, so that any ACP-compatible agent works with any ACP-compatible editor without bespoke integration work on either side [1]. It targets the same M×N problem the Language Server Protocol solved for editor-to-language-server integration, but for agent-to-editor instead.\n\nACP assumes the user's primary surface is the editor, which reaches out to agents for specific tasks. Local agents run as editor sub-processes and communicate over JSON-RPC via stdio; remote, cloud-hosted agents are supported over HTTP or WebSocket, though the project's own documentation states full remote support is still a work in progress [1]. ACP deliberately reuses MCP's JSON representations where practical, and layers on coding-specific UX types (e.g. representing diffs) that MCP does not define; user-facing text defaults to Markdown.\n\nACP does not itself define agent discovery beyond the ACP Registry (stabilized 2026-03-09), which gives clients a standard way to find, install, and configure agents — it does not attempt to be a general web-scale discovery mechanism [2]. It also does not (yet) fully specify remote-agent transport; a dedicated Transports Working Group (JetBrains and Block/Goose engineers) was formed on 2026-04-22 specifically to standardize WebSocket/HTTP transports for remote agents [2].\n\nAs of this check (September 2026), ACP v1 is stable and has shipped a steady cadence of \"Completed\" RFDs throughout 2026 (session resume, session list, logout, elicitation, boolean config options, request cancellation, and more), and ACP v2's protocol documentation and schema were published in Draft form on 2026-07-20 [2]. Rust and TypeScript SDKs both reached 1.0 on 2026-06-25 [2]. Governance is unambiguous and disclosed rather than disputed: Zed Industries is the explicit \"BDFL\" (benevolent dictator for life) design-team lead over a public Request-for-Dialog process modeled loosely on Rust's RFC process, and JetBrains' Sergey Ignatov joined as a second Lead Maintainer on 2026-02-18, formalizing what the project describes as \"growing collaboration between Zed and JetBrains\" [3][2]. What is not yet settled: how much of the remote-agent transport work lands in v1 versus v2, and whether governance broadens beyond the two-company core team the project says it currently anticipates expanding.", "track": "single-vendor", "version": { "date": "2026-07-20", "label": "v1 (stable); v2 draft" } }, { "acronym": "ACP", "adoption": { "by": null, "level": "unmeasured", "probe_run": null }, "aliases": [ "Agent Communication Protocol", "ACP" ], "analog": "none", "collisions": [ "Agent Client Protocol (Zed)", "Agentic Commerce Protocol (OpenAI/Stripe)", "Agent Connect Protocol (AGNTCY)" ], "discovery": { "mechanism": "GET /agents (Agent Discovery endpoint)", "path": "/agents" }, "dispute": null, "evidence": [ { "claim": "The i-am-bee/acp GitHub repository was archived by the owner on 2025-08-27 and is read-only; its README banner states \"ACP is now part of A2A under the Linux Foundation!\" with a link to a migration guide.", "date": "2026-09-05", "label": "VERIFIED", "url": "https://github.com/i-am-bee/acp" }, { "claim": "The ACP OpenAPI specification (v0.2.0) defines GET /agents for agent discovery, GET /ping for liveness, and a /runs resource for stateless/stateful/streamed execution.", "date": "2026-09-05", "label": "VERIFIED", "url": "https://raw.githubusercontent.com/i-am-bee/acp/main/docs/spec/openapi.yaml" } ], "form": "endpoint", "governance": "Formerly IBM BeeAI; archived, functionality merged into A2A under the Linux Foundation", "group": "Protocols called ACP", "history": [ { "date": "2026-09-05", "note": "seeded from Exa Agent research run" }, { "date": "2026-09-06", "note": "verified against github.com/i-am-bee/acp (archived banner, archive date) and its OpenAPI spec; set phase withdrawn per Ruling 11 as merged into A2A" }, { "date": "2026-09-06", "note": "collisions updated to add Agent Connect Protocol (Cisco/AGNTCY), verified against github.com/agntcy/acp-spec, spec.acp.agntcy.org" } ], "id": "agent-communication-protocol", "implementation": "deprecated", "last_verified": "2026-09-06", "name": "Agent Communication Protocol", "native_status": "\"ACP is now part of A2A under the Linux Foundation\" (repository banner)", "origin": { "date": "2025", "org": "IBM (BeeAI)" }, "part_of": null, "parties": [ "agent-agent", "agent-human" ], "phase": "withdrawn", "probe": { "method": "GET", "on_absent": "Expected: the protocol was retired in August 2025 and superseded by A2A, so absence is the normal case", "parse": "JSON array of agent objects would confirm a live ACP server; in practice the repository is archived and this is not expected to resolve on new deployments", "path": "{origin}/agents" }, "question": "How did agents, applications, and people exchange multimodal REST messages before merging into A2A?", "scope": "general", "spec_url": "https://github.com/i-am-bee/acp", "step": "coordinate", "summary_md": "IBM's Agent Communication Protocol (ACP) was an open REST protocol, built by IBM's BeeAI project, for exchanging multimodal messages (text, code, files, media) between agents, applications, and people, with support for synchronous, background, and streamed responses and for stateless or stateful execution [1][2]. It solved the same problem A2A now solves: letting agents built on different frameworks discover each other's capabilities (`GET /agents`) and run tasks (`POST /runs`) over a standard REST/OpenAPI surface, and it powered agent discovery and execution on IBM's BeeAI Platform [1].\n\nACP does not exist as an independent, live protocol any more. Its GitHub repository (`i-am-bee/acp`) was archived by its owner on 2025-08-27 and is now read-only [1]; the repository's README carries a banner stating \"ACP is now part of A2A under the Linux Foundation!\" and links a migration guide directing implementers to Google/Linux Foundation's A2A protocol instead [1]. Because the record here would otherwise duplicate a step already covered by `a2a`, and because the issuer itself declares the protocol subsumed, this record's phase is set to \"withdrawn\" and its implementation to \"deprecated\" per Ruling 11 — it is kept as a historical record rather than deleted, since some deployments and SDKs (`acp-sdk` on PyPI/npm) may still exist in the wild.\n\nAt time of archival the last published OpenAPI spec was v0.2.0, exposing `GET /ping` (liveness), `GET /agents` (agent discovery, paginated via `limit`/`offset`), and a `/runs` family of endpoints for execution [2]. Governance had been IBM BeeAI-led community governance; there is no evidence ACP itself was ever formally adopted by a Linux Foundation working group before being merged — rather, its functionality and some contributors moved into the A2A project, which is the Linux Foundation-governed successor. What is unresolved: whether any production deployments continue to run the archived ACP server surface independently of A2A; no such deployment was found during this verification pass.", "track": "linux-foundation", "version": { "date": "2025-08", "label": "0.2.0 (final OpenAPI spec, archived)" } }, { "acronym": "ACP", "adoption": { "by": "OpenAI and Stripe (project README)", "level": "claimed", "probe_run": null }, "aliases": [ "ACP", "Agentic Commerce Protocol" ], "analog": "Checkout API", "collisions": [ "Agent Client Protocol (Zed)", "Agent Communication Protocol (IBM)", "ERC-8183 (also informally called Agentic Commerce Protocol)", "Agent Connect Protocol (AGNTCY)" ], "discovery": { "mechanism": "Bilateral capability negotiation (per RFC: capability_negotiation) between agent platform and merchant; no fixed well-known path published", "path": null }, "dispute": null, "evidence": [ { "claim": "ACP is an interaction model and open standard maintained by OpenAI and Stripe, currently in beta, using date-based versioning; the 2026-04-17 release added Cart, Feed, Orders, authentication and MCP support.", "date": "2026-04-17", "label": "VERIFIED", "url": "https://github.com/agentic-commerce-protocol/agentic-commerce-protocol" }, { "claim": "Governance: a Technical Steering Committee of up to 7 org seats; OpenAI and Stripe are Founding Maintainers with veto power exercised only against violations of five named principles (mission, neutrality, security, protocol integrity, considered decision-making).", "date": null, "label": "VERIFIED", "url": "https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/docs/governance.md" }, { "claim": "Meta has joined OpenAI and Stripe as a lead maintainer of the project.", "date": null, "label": "VERIFIED", "url": "https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/MAINTAINERS.md" }, { "claim": "OpenAI publishes ACP-based Commerce documentation for building checkout flows in ChatGPT.", "date": null, "label": "REPORTED", "url": "https://developers.openai.com/commerce/" }, { "claim": "Stripe publishes Agentic Commerce documentation implementing ACP for merchants.", "date": null, "label": "REPORTED", "url": "https://docs.stripe.com/agentic-commerce" } ], "form": "endpoint", "governance": "Technical Steering Committee (up to 7 org seats); OpenAI, Stripe, and Meta are lead maintainers, with OpenAI and Stripe as Founding Maintainers holding last-resort veto over mission, neutrality, security, and fork-integrity decisions", "group": "Protocols called ACP", "history": [ { "date": "2026-09-05", "note": "seeded from Exa Agent research run" }, { "date": "2026-09-06", "note": "verified against agentic-commerce-protocol GitHub repo (README, docs/governance.md, MAINTAINERS.md, spec/2026-04-17), developers.openai.com/commerce, docs.stripe.com/agentic-commerce" }, { "date": "2026-09-06", "note": "collisions updated to add Agent Connect Protocol (Cisco/AGNTCY), verified against github.com/agntcy/acp-spec, spec.acp.agntcy.org" } ], "id": "agentic-commerce-protocol", "implementation": "multi-implementation", "last_verified": "2026-09-06", "name": "Agentic Commerce Protocol", "native_status": "Beta open standard, interaction model for connecting buyers, agents, and businesses", "origin": { "date": "2025-09-29", "org": "OpenAI and Stripe" }, "part_of": null, "parties": [ "agent-site" ], "phase": "living", "probe": { "method": "POST", "on_absent": "Absence proves nothing generalizable: ACP endpoints and auth are negotiated per integration and not advertised at a fixed public path, so a failed probe only shows this origin/path pair is not configured, not that ACP is unsupported.", "parse": "Response includes an API-Version response/negotiation and a CheckoutSession object per the 2026-04-17 OpenAPI schema", "path": "{origin}/checkout_sessions" }, "question": "How do a buyer's agent and a merchant complete a deterministic, programmatic checkout without the agent becoming the merchant of record?", "scope": "commerce", "spec_url": "https://github.com/agentic-commerce-protocol/agentic-commerce-protocol", "step": "pay", "summary_md": "The Agentic Commerce Protocol (ACP) is an open, REST-based interaction model that lets a buyer's AI agent (a \"platform\" such as ChatGPT) complete a checkout with a merchant's existing commerce stack, while the merchant remains the system of record for orders, payments, tax, and compliance [1]. It solves the discovery-to-checkout hand-off for conversational and agentic shopping: a client negotiates capabilities, creates and updates a `CheckoutSession`, and completes or cancels it, with optional delegated-payment tokens (`/agentic_commerce/delegate_payment`) so an agent platform can pass a payment method to a merchant without becoming a payment processor [1].\n\nIt does not define blockchain settlement, on-chain escrow, or a payment rail of its own — payments continue to run over the merchant's existing PSP relationship, and ACP is scoped explicitly to checkout session lifecycle, feed ingestion, and payment-handler negotiation, not returns, tax computation, or fraud modeling [1]. It is also not a discovery protocol: there is no published well-known path for finding ACP support at an origin; capability negotiation is bilateral and appears to be arranged per integration (RFC: capability_negotiation), so it cannot be probed generically the way UCP's `/.well-known/ucp` can.\n\nAs of the current state (2026-09), the specification uses date-based versioning with a complete snapshot per release; the latest stable release is 2026-04-17, adding a push-model Feed API, multi-item checkout examples, and 3-D Secure authentication flows, with active development continuing in an `unreleased/` branch [1]. Governance sits with a Technical Steering Committee of up to seven organization seats, appointed by Founding Maintainers OpenAI and Stripe, who retain veto power scoped narrowly to five stated principles (mission, neutrality, security, protocol integrity, and considered decision-making) [2]. Meta has since joined as a third lead maintainer alongside OpenAI and Stripe [3].\n\nReference implementations exist from both founding maintainers: OpenAI's ChatGPT commerce surface and Stripe's Agentic Commerce integration, both documented on their respective developer sites [4][5]. Because the only adoption figures available come from the maintaining organizations' own materials, adoption here is recorded as claimed rather than independently measured. What remains unresolved: how \"beta\" status maps to production risk for merchants going live today, and whether the TSC's veto mechanism has ever been invoked in a real dispute.", "track": "vendor-consortium", "version": { "date": "2026-04-17", "label": "2026-04-17 (date-versioned spec; unreleased/ tracks current development)" } }, { "acronym": "UCP", "adoption": { "by": "UCP project (ucp.dev launch-partner list)", "level": "claimed", "probe_run": null }, "aliases": [ "UCP" ], "analog": "Commerce API plus a machine-readable merchant capability document", "collisions": [], "discovery": { "mechanism": "well-known capability/profile document", "path": "/.well-known/ucp" }, "dispute": null, "evidence": [ { "claim": "UCP's own site lists co-development partners across Shopping (Google, Shopify, Etsy, Wayfair, Target, Walmart, Amazon, Microsoft, Meta, Salesforce, Stripe), Lodging (Amadeus, Booking.com, Expedia Group, Google, Hilton, Marriott, Trip.com), and Food (DoorDash, Google, Square, Toast, Uber Eats).", "date": null, "label": "VERIFIED", "url": "https://ucp.dev" }, { "claim": "The GitHub org's central MAINTAINERS.md names a Shopping Tech Council (Google, Shopify, Etsy, Meta, Amazon, Microsoft, Target, Stripe, Salesforce) and a Food Tech Council (Google, Square, Toast, DoorDash, Uber Eats), governed per GOVERNANCE.md's Domain Tech Council / Governing Council model.", "date": null, "label": "VERIFIED", "url": "https://raw.githubusercontent.com/Universal-Commerce-Protocol/.github/main/MAINTAINERS.md" }, { "claim": "UCP core concepts documentation defines discovery via a well-known capability document at /.well-known/ucp (also referencing /.well-known/oauth-authorization-server for identity linking), and states UCP is built on REST and JSON-RPC transports with AP2, A2A, and MCP support built in.", "date": null, "label": "VERIFIED", "url": "https://ucp.dev/documentation/core-concepts/" }, { "claim": "The UCP GitHub repository describes UCP as an open standard for interoperability between commerce entities (platforms, businesses, PSPs, Credential Providers), with Capabilities such as Checkout, Identity Linking, Order, and Payment Token Exchange.", "date": null, "label": "VERIFIED", "url": "https://raw.githubusercontent.com/Universal-Commerce-Protocol/ucp/main/README.md" } ], "form": "well-known-file", "governance": "Domain Tech Councils (DTC) per vertical — Shopping Tech Council and Food Tech Council seated — under an overall Governing Council (GC); DTC seats held by Google, Shopify, Etsy, Meta, Amazon, Microsoft, Target, Stripe, Salesforce, Wayfair, Square, Toast, DoorDash, Uber Eats", "group": null, "history": [ { "date": "2026-09-05", "note": "seeded from Exa Agent research run" }, { "date": "2026-09-06", "note": "verified against ucp.dev (home, core-concepts), Universal-Commerce-Protocol/ucp README, and Universal-Commerce-Protocol/.github MAINTAINERS.md / GOVERNANCE.md" } ], "id": "ucp", "implementation": "multi-implementation", "last_verified": "2026-09-06", "name": "Universal Commerce Protocol", "native_status": "Open standard; specification expanding beyond Shopping into Lodging and Food", "origin": { "date": "2026-01", "org": "Google" }, "part_of": null, "parties": [ "agent-site" ], "phase": "living", "probe": { "method": "GET", "on_absent": "A missing or non-JSON response at /.well-known/ucp means the origin does not (yet) declare UCP capabilities; UCP also supports MCP/A2A transports, so a 404 on the well-known path does not rule out a business exposing UCP only via those channels.", "parse": "200 response with a UCP profile JSON document declaring supported Capabilities (e.g. Checkout, Identity Linking, Order) and Extensions", "path": "{origin}/.well-known/ucp" }, "question": "Can an agent discover a business's commerce capabilities, build a cart, and check out interoperably across shopping, lodging, and food ordering?", "scope": "commerce", "spec_url": "https://ucp.dev/documentation/core-concepts/", "step": "pay", "summary_md": "The Universal Commerce Protocol (UCP) is an open standard, initiated by Google, that gives platforms (AI agents, apps, procurement systems) and businesses a common language and set of REST/JSON-RPC \"Capabilities\" — Checkout, Identity Linking, Order, Payment Token Exchange — so agentic commerce can work without bespoke, one-off integrations per merchant [3][4]. Businesses declare what they support in a machine-readable profile discoverable at a well-known path (`/.well-known/ucp`), and platforms use that to autonomously configure themselves for a given origin [3].\n\nUCP solves cross-vertical interoperability for agentic shopping, lodging, and food ordering by defining Capabilities and optional Extensions on top of transport-agnostic REST, MCP, or A2A bindings, and it explicitly builds on the Agent Payments Protocol (AP2) for payment authorization and OAuth 2.0 for identity linking rather than reinventing either [3][4]. It does not itself move money or replace a merchant's payment processor — the merchant remains \"Merchant of Record\" — and its Lodging and Food verticals are still described by the project as pending detailed specifications as of the current documentation snapshot [1].\n\nGovernance runs through per-vertical Domain Tech Councils (DTC) — a seated Shopping Tech Council and Food Tech Council as of this verification — operating under an overall Governing Council, with seats and maintainer nomination rights tied to actual contribution rather than fixed vendor slots [2]. Seated companies span Google, Shopify, Etsy, Meta, Amazon, Microsoft, Target, Stripe, and Salesforce (Shopping) and Google, Square, Toast, DoorDash, and Uber Eats (Food) [2]. UCP's own launch materials additionally name Walmart, Amadeus, Booking.com, Expedia Group, Hilton, Marriott, and Trip.com as co-development partners across Shopping and Lodging verticals, though Lodging has no seated council yet in the maintainers file [1][2].\n\nBecause every adoption figure available — the partner list, the council rosters — comes from UCP's own site and repository, adoption here is recorded as claimed by the UCP project rather than independently measured; nobody outside the project has published a count of live UCP-conformant merchant endpoints. What is unresolved: how many of the named partners have a working `/.well-known/ucp` profile live today versus having only committed to the initiative, and how UCP's scope divides from AP2 in practice given the two are designed to interlock.", "track": "vendor-consortium", "version": { "date": "2026-08-25", "label": "documentation site dated 2026-08-25; active/expanding specification (Lodging and Food detailed specs pending)" } }, { "acronym": "AP2", "adoption": { "by": "Google (launch blog post, 60+ launch partners)", "level": "claimed", "probe_run": null }, "aliases": [ "AP2", "Agentic Payment Protocol" ], "analog": "Signed payment authorization / purchase order", "collisions": [], "discovery": { "mechanism": "No site-level discovery; AP2 mandates are exchanged as message payloads inside a Commerce Protocol (e.g. UCP) or an agent framework (A2A/MCP-compatible flows), not fetched from a well-known path", "path": "none" }, "dispute": null, "evidence": [ { "claim": "AP2 defines five roles (Shopping Agent, Credential Provider, Merchant, Merchant Payment Processor, Trusted Surface) and two Mandate types (Checkout Mandate, Payment Mandate) used as cryptographic, signed evidence of what a user authorized, for both human-present and human-not-present flows; it is explicitly designed to be compatible with and complementary to UCP.", "date": null, "label": "VERIFIED", "url": "https://raw.githubusercontent.com/google-agentic-commerce/AP2/main/docs/ap2/specification.md" }, { "claim": "AP2's CONTRIBUTING.md states the core specification has been donated to the FIDO Alliance, and that contributions to the google-agentic-commerce/AP2 repository going forward are to samples and SDK only.", "date": null, "label": "VERIFIED", "url": "https://raw.githubusercontent.com/google-agentic-commerce/AP2/main/CONTRIBUTING.md" }, { "claim": "Google's launch announcement (blog.google / cloud.google.com) frames AP2 as an open protocol for agent payments with more than 60 partners at launch, and that the spec was donated to FIDO for continued development.", "date": "2025-09-16", "label": "REPORTED", "url": "https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol" }, { "claim": "The AP2 checkout_mandate.md defines the Checkout Mandate as cryptographic proof to the Merchant that the Shopping Agent is authorized to purchase a specific Checkout, and a Checkout Receipt for the completed transaction.", "date": null, "label": "VERIFIED", "url": "https://raw.githubusercontent.com/google-agentic-commerce/AP2/main/docs/ap2/checkout_mandate.md" } ], "form": "endpoint", "governance": "Core specification donated by Google to the FIDO Alliance for continued development; the google-agentic-commerce/AP2 repository now hosts only samples and an SDK, not the normative spec text", "group": null, "history": [ { "date": "2026-09-05", "note": "seeded from Exa Agent research run" }, { "date": "2026-09-06", "note": "verified against google-agentic-commerce/AP2 (README, CONTRIBUTING.md, docs/ap2/specification.md, docs/ap2/checkout_mandate.md) and Google Cloud blog launch announcement; folded in ap2-checkout-mandate as a component rather than a separate protocol" } ], "id": "ap2", "implementation": "multi-implementation", "last_verified": "2026-09-06", "name": "Agent Payments Protocol", "native_status": "Security/authorization protocol for agent-performed payments; core spec now stewarded by FIDO Alliance", "origin": { "date": "2025-09-16", "org": "Google" }, "part_of": null, "parties": [ "agent-site" ], "phase": "candidate", "probe": { "method": "none", "on_absent": "There is no generic HTTP probe for AP2: a Merchant, Credential Provider, or Merchant Payment Processor supports AP2 only if it accepts and validates AP2 Checkout/Payment Mandates inside its own commerce protocol's message flow (e.g. as a UCP payment handler), which cannot be detected by an unauthenticated GET against the origin.", "parse": "not applicable — AP2 is a client-side/in-band mandate format, not an origin-exposed endpoint or file", "path": "none" }, "question": "Did the user actually authorize what this agent is about to buy and pay for, and can the merchant prove it later?", "scope": "payments", "spec_url": "https://raw.githubusercontent.com/google-agentic-commerce/AP2/main/docs/ap2/specification.md", "step": "pay", "summary_md": "The Agent Payments Protocol (AP2) is a security and authorization framework for agent-performed payments: it defines how a user's intent to buy something is captured as a cryptographically signed, tamper-evident Mandate that a Merchant, Credential Provider, and Merchant Payment Processor can verify and later present as dispute evidence [1]. It solves the \"was this agent actually authorized to spend this money on this cart\" problem for both human-present (\"direct\") and human-not-present (\"autonomous\") purchase flows, using two linked mandate types: a Checkout Mandate (what is being bought) and a Payment Mandate (how it is being paid for), each with a corresponding Receipt [1][4].\n\nAP2 explicitly does not define a commerce protocol itself — no catalog APIs, no checkout session lifecycle, no merchant-facing REST surface — it is a security layer meant to sit inside a Commerce Protocol such as the Universal Commerce Protocol (UCP), which it says it is \"designed explicitly to be compatible with\" [1]. It also does not expose any discoverable endpoint or well-known file: mandates travel as message payloads inside whatever transport the surrounding commerce or agent-to-agent protocol uses, so there is no generic HTTP probe that proves or disproves AP2 support at an origin.\n\nAs of this verification, AP2's normative specification text has been donated by Google to the FIDO Alliance for continued stewardship; the original `google-agentic-commerce/AP2` GitHub repository states explicitly that further contributions there are limited to code samples and an SDK, not the spec itself [2]. Google's original announcement (September 2025) cited more than 60 launch partners, though that figure comes from Google's own blog post rather than an independent count [3]. Reference samples exist in Python, Go, and Android using Google's Agent Development Kit (ADK) and Gemini models, but these are demonstration code, not a conformance suite.\n\nWhat is disputed or unresolved: how governance actually operates now that the spec sits with FIDO rather than in the original GitHub repo — no FIDO-hosted specification page was located during this verification, only the original repository's copy and Google's donation announcement — and how the 60+ \"launch partners\" map to organizations actually running AP2-verified mandates in production versus organizations that merely endorsed the announcement.", "track": "industry-body", "version": { "date": null, "label": "v0.2" } }, { "acronym": "", "adoption": { "by": null, "level": "unknown", "probe_run": null }, "aliases": [], "analog": "Signed purchase order", "collisions": [], "discovery": { "mechanism": "none — see ap2", "path": "none" }, "dispute": null, "evidence": [ { "claim": "docs/ap2/checkout_mandate.md is a topic page inside the AP2 specification (docs/ap2/specification.md), not a standalone protocol with its own governance, versioning, or repository.", "date": null, "label": "VERIFIED", "url": "https://raw.githubusercontent.com/google-agentic-commerce/AP2/main/docs/ap2/specification.md" }, { "claim": "The Checkout Mandate and its Checkout Receipt are defined as part of AP2's Mandates section alongside the Payment Mandate; both mandate types share AP2's roles, verification model, and dispute-evidence design.", "date": null, "label": "VERIFIED", "url": "https://raw.githubusercontent.com/google-agentic-commerce/AP2/main/docs/ap2/checkout_mandate.md" } ], "form": "document-format", "governance": "FIDO Alliance / AP2 (see ap2 record)", "group": null, "history": [ { "date": "2026-09-05", "note": "seeded from Exa Agent research run" }, { "date": "2026-09-06", "note": "verified: confirmed this is a component of ap2's specification.md, not a distinct protocol; set phase=withdrawn and merged content into ap2" } ], "id": "ap2-checkout-mandate", "implementation": "unknown", "last_verified": "2026-09-06", "name": "AP2 Checkout Mandate", "native_status": "AP2 specification component, not an independently published protocol", "origin": { "date": null, "org": "Google AP2" }, "part_of": "ap2", "parties": [ "agent-site" ], "phase": "withdrawn", "probe": { "method": "none", "on_absent": "not applicable; this record is retired, see ap2", "parse": "not applicable", "path": "none" }, "question": "What exactly did the user approve for checkout?", "scope": "payments", "spec_url": "https://raw.githubusercontent.com/google-agentic-commerce/AP2/main/docs/ap2/checkout_mandate.md", "step": "pay", "summary_md": "This record is withdrawn as a distinct protocol entry. The \"AP2 Checkout Mandate\" is not a separate specification: it is one topic page (`docs/ap2/checkout_mandate.md`) inside the single AP2 specification document tree, defining the Checkout Mandate object and its Checkout Receipt as one of AP2's two Mandate types (the other being the Payment Mandate) [1][2]. It has no independent governance, repository, versioning, or discovery mechanism apart from AP2 itself — it is versioned, donated to FIDO, and maintained exactly as AP2 is. Content and evidence for this concept has been folded into the `ap2` record. This id is kept in the dataset only so a reader who encounters \"AP2 Checkout Mandate\" as a separate name is redirected rather than finding a dead link.", "track": "industry-body", "version": { "date": null, "label": "AP2 v0.2" } }, { "acronym": "", "adoption": { "by": "x402 Foundation (x402.org live dashboard)", "level": "claimed", "probe_run": null }, "aliases": [], "analog": "HTTP 402 Payment Required, finally implemented", "collisions": [], "discovery": { "mechanism": "HTTP 402 response carrying payment requirements in a header", "path": "none — signalled per-request via the 402 status code, not a fixed well-known path" }, "dispute": null, "evidence": [ { "claim": "x402's HTTP transport spec defines the 402 challenge as HTTP 402 status with a PAYMENT-REQUIRED header carrying a base64-encoded PaymentRequired object, and the client retry as a PAYMENT-SIGNATURE header carrying a base64-encoded PaymentPayload.", "date": null, "label": "VERIFIED", "url": "https://raw.githubusercontent.com/x402-foundation/x402/main/specs/transports-v2/http.md" }, { "claim": "x402.org's footer identifies the project as 'x402 a Series of LF Projects, LLC', confirming Linux Foundation stewardship, and its Announcements page states the Linux Foundation announced the operational launch of the x402 Foundation on July 14, 2026.", "date": "2026-07-14", "label": "VERIFIED", "url": "https://x402.org/announcement" }, { "claim": "x402.org's homepage displays a live self-reported dashboard: 75.41M transactions and $24.24M volume in the last 30 days, 94.06K buyers and 22K sellers, at time of check.", "date": "2026-09-06", "label": "VERIFIED", "url": "https://x402.org" } ], "form": "http-header", "governance": "x402 Foundation, a Series of LF Projects, LLC (Linux Foundation); operational launch announced 2026-07-14", "group": "HTTP 402 family", "history": [ { "date": "2026-09-05", "note": "seeded from Exa Agent research run" }, { "date": "2026-09-06", "note": "verified against x402.org (homepage, /announcement), x402-foundation/x402 specs/transports-v2/http.md" } ], "id": "x402", "implementation": "multi-implementation", "last_verified": "2026-09-06", "name": "x402", "native_status": "Open, neutral standard for internet-native payments", "origin": { "date": null, "org": "Coinbase" }, "part_of": null, "parties": [ "agent-site", "agent-payment" ], "phase": "living", "probe": { "method": "GET", "on_absent": "A 200 or a 402 without a PAYMENT-REQUIRED header means this specific path is not (or no longer) gated by x402 v2 over HTTP; the same origin could still use x402 over the MCP or other transports, or the legacy v1 header shape, so the probe only rules out v2/HTTP on the probed path.", "parse": "HTTP 402 status with a base64-encoded PaymentRequired object in the PAYMENT-REQUIRED response header (x402 v2 HTTP transport)", "path": "{origin}/{paid-path}" }, "question": "How can an HTTP client pay per-request or per-resource, in stablecoins, without accounts, API keys, or signup?", "scope": "payments", "spec_url": "https://github.com/x402-foundation/x402/blob/main/specs/transports-v2/http.md", "step": "pay", "summary_md": "x402 is an open, HTTP-native payment protocol that activates the long-reserved (since 1999) HTTP 402 \"Payment Required\" status code: a server responds 402 with machine-readable payment requirements, the client pays (in practice, stablecoins over an EVM-compatible network) and retries the request with proof of payment attached [1]. It solves instant, account-free, per-request monetization for APIs and agentic consumers — no signup, no KYC, no stored API keys, no prepaid credit balance — collapsing what the project calls a five-step \"old way\" of API onboarding into three HTTP round trips [own site, x402.org homepage].\n\nIt does not itself define a payment network; it is a wire-format and challenge/response convention that networks and asset issuers plug into via a `scheme` and `network` field (the reference implementation targets EVM chains and USDC, per the transport spec's example payload) [1]. Version 2 of the specification moved the payment-required and payment-signature payloads into dedicated `PAYMENT-REQUIRED` and `PAYMENT-SIGNATURE` HTTP headers rather than embedding them in earlier v1 conventions, and the specification separately defines non-HTTP transports (the repository lists transports-v1 and transports-v2 directories) [1].\n\nAs of this verification, x402 is governed by the x402 Foundation, described in its own site footer as \"a Series of LF Projects, LLC\" — i.e., a Linux Foundation-hosted project — with an operational launch announced by the Linux Foundation on 2026-07-14 [2]. Coinbase originated the protocol; the Foundation now governs it independently of any single company, per the project's own framing [x402.org homepage]. The site's homepage displays a real-time usage dashboard claiming 75.41M transactions and $24.24M in volume over the trailing 30 days, with 94.06K buyers and 22K sellers, current as of this check [3] — but this figure is self-reported by the Foundation running the protocol, not measured by an independent index, so it is recorded here as claimed rather than observed or measured. What remains open: no independently operated adoption index (e.g. a third-party \"402 index\") was located and fetched during this verification to cross-check the Foundation's own dashboard number.", "track": "linux-foundation", "version": { "date": null, "label": "x402 protocol specification v2, transports-v2/http.md" } }, { "acronym": "L402", "adoption": { "by": null, "level": "unmeasured", "probe_run": null }, "aliases": [ "LSAT" ], "analog": "HTTP 402 plus a bearer credential (like an API key you buy per-use)", "collisions": [], "discovery": { "mechanism": "HTTP 402 response carrying a WWW-Authenticate challenge", "path": "none — signalled per-request, no well-known file" }, "dispute": null, "evidence": [ { "claim": "L402's protocol specification defines the credential as a `:` pair, the challenge as `WWW-Authenticate: L402 macaroon=..., invoice=...` on a 402, and requires servers to switch to 401 (not 402) once a credential has been presented but fails verification.", "date": null, "label": "VERIFIED", "url": "https://raw.githubusercontent.com/lightninglabs/L402/master/protocol-specification.md" }, { "claim": "The L402 README states it was developed by Lightning Labs, evolved from the earlier LSAT (Lightning Service Authentication Token) concept, and is designed to fit agentic use cases where an AI agent discovers, pays for, and authenticates to a service without human intervention, including delegated sub-credentials via macaroon caveat attenuation.", "date": null, "label": "VERIFIED", "url": "https://raw.githubusercontent.com/lightninglabs/L402/master/README.md" } ], "form": "http-header", "governance": "Lightning Labs", "group": "HTTP 402 family", "history": [ { "date": "2026-09-05", "note": "seeded from Exa Agent research run" }, { "date": "2026-09-06", "note": "verified against lightninglabs/L402 README.md and protocol-specification.md on GitHub" } ], "id": "l402", "implementation": "shipping", "last_verified": "2026-09-06", "name": "L402", "native_status": "Active, registered as an HTTP Authentication scheme (RFC 7235-style)", "origin": { "date": "2020", "org": "Lightning Labs (originally published as LSAT)" }, "part_of": null, "parties": [ "agent-site", "agent-payment" ], "phase": "living", "probe": { "method": "GET", "on_absent": "A 200, 401, or a 402 without an L402-scheme WWW-Authenticate header means this path does not issue L402 challenges; the credential scheme is registered under RFC 7235 so a server could in principle offer it alongside other schemes on the same 401/402 responses.", "parse": "HTTP 402 status with a WWW-Authenticate: L402 macaroon=\"...\", invoice=\"...\" header", "path": "{origin}/{paid-path}" }, "question": "How can a client pay for, and then authenticate to, a metered API resource over the Lightning Network with no accounts or database-backed sessions?", "scope": "payments", "spec_url": "https://raw.githubusercontent.com/lightninglabs/L402/master/protocol-specification.md", "step": "pay", "summary_md": "L402 (formerly LSAT, Lightning Service Authentication Token) is an HTTP authentication scheme, developed by Lightning Labs, that combines the dormant HTTP 402 status code with Lightning Network micropayments to let a client pay for and then authenticate to a metered API resource in a single credential [1][2]. A server challenges with HTTP 402 plus a `WWW-Authenticate: L402` header containing a macaroon and a BOLT-11 Lightning invoice; the client pays the invoice, receives a payment preimage, and re-presents `macaroon:preimage` in an `Authorization` header on retry — the server verifies statelessly by checking that the preimage hashes to the payment hash embedded in the macaroon, with no database lookup [1].\n\nIt solves pay-per-use API access without accounts, passwords, or centralized session state, and its macaroon-based credentials support caveats and attenuation, so a holder can mint a narrower, delegated sub-credential for another party (including another agent) without contacting the issuing server [2]. It does not itself define a currency or settlement rail beyond the Lightning Network, and it is explicitly scoped to authentication plus payment proof, not to cart-building, catalog discovery, or dispute resolution — those are left to whatever service sits behind the challenge.\n\nThe specification is precise about status-code discipline: 402 is reserved exclusively for the initial payment challenge, while a 401 is returned once any credential (valid-looking or not) has been submitted, so clients can distinguish \"you must pay\" from \"your credential is broken\" [1]. As of this verification, the specification lives on the `master` branch of `lightninglabs/L402` with no separately dated release tag observed, and Lightning Labs also operates a reference reverse-proxy implementation (Aperture) that gates access to metered services with L402 in production. No independent, dated count of production L402 deployments was located during this verification, so adoption is recorded as unmeasured rather than claimed or observed — Lightning Labs' own materials assert active use but do not publish a number in the sources checked.", "track": "single-vendor", "version": { "date": null, "label": "current protocol-specification.md on the master branch" } }, { "acronym": "MPP", "adoption": { "by": null, "level": "unmeasured", "probe_run": null }, "aliases": [ "MPP" ], "analog": "A payment-method-agnostic HTTP 402 challenge/credential/receipt exchange", "collisions": [], "discovery": { "mechanism": "HTTP 402 response carrying a WWW-Authenticate: Payment challenge", "path": "none — signalled per-request, no well-known file" }, "dispute": null, "evidence": [ { "claim": "MPP's protocol overview documents the flow as: client GETs a resource, server returns 402 with WWW-Authenticate: Payment, client retries with Authorization: Payment, server verifies and responds 200 with a Payment-Receipt header — and explicitly uses 402 (not 401) even for failed credential verification, reserving 401 for authentication failures unrelated to payment and 403 for policy denial after a valid payment.", "date": null, "label": "VERIFIED", "url": "https://mpp.dev/protocol" }, { "claim": "MPP's Governance page states the protocol is co-authored by Tempo and Stripe, is 'neutral by design' and operates independently of any single company, payment method, or rail, and splits governance between the core specification (submitted to the IETF standards track as the Payment HTTP Authentication Scheme) and separately maintained payment methods.", "date": null, "label": "VERIFIED", "url": "https://mpp.dev/governance" }, { "claim": "mpp.dev's homepage lists SDKs across TypeScript (mppx), Go, Ruby, Rust, and Python, plus a comparison page contrasting MPP with x402, and blog posts describing added EVM and x402-exact-flow support as of June 2026.", "date": "2026-08-12", "label": "VERIFIED", "url": "https://mpp.dev" } ], "form": "http-header", "governance": "Co-authored by Tempo and Stripe; the core specification (the abstract 402/Challenge/Credential/Receipt shape) is submitted to the IETF standards track as the Payment HTTP Authentication Scheme, while individual payment methods (Tempo, EVM, Stripe Card, Lightning, Solana, Stellar, Monad, NEAR Intents, RedotPay) are maintained separately from the core, to keep the core neutral to any one rail", "group": "HTTP 402 family", "history": [ { "date": "2026-09-05", "note": "seeded from Exa Agent research run" }, { "date": "2026-09-06", "note": "verified against mpp.dev (homepage, /protocol, /governance)" } ], "id": "mpp", "implementation": "multi-implementation", "last_verified": "2026-09-06", "name": "Machine Payments Protocol", "native_status": "Open protocol; developer docs distinguish the normative IETF specification from the mpp.dev developer-friendly overview", "origin": { "date": null, "org": "Tempo and Stripe" }, "part_of": null, "parties": [ "agent-site", "agent-payment" ], "phase": "review", "probe": { "method": "GET", "on_absent": "A 200, 401, or a 402 without a Payment-scheme WWW-Authenticate header means this path is not gated by MPP; MPP also has MCP/JSON-RPC and WebSocket transport bindings, so an HTTP-only probe cannot rule out MPP support offered solely over those transports.", "parse": "HTTP 402 status with a WWW-Authenticate: Payment ... challenge header; a subsequent authorized retry returns 200 with a Payment-Receipt header", "path": "{origin}/{paid-path}" }, "question": "How can a machine client (an agent, script, or another server) pay for an HTTP resource using any payment network, not just one?", "scope": "payments", "spec_url": "https://mpp.dev/protocol", "step": "pay", "summary_md": "The Machine Payments Protocol (MPP) standardizes HTTP 402 \"Payment Required\" as an extensible, payment-network-agnostic machine-to-machine payment flow: a client requests a resource, the server issues a 402 challenge with `WWW-Authenticate: Payment`, the client fulfills the payment (signing a transaction, paying an invoice, or completing a card charge depending on the method) and retries with `Authorization: Payment`, and the server verifies and serves the resource with an optional `Payment-Receipt` header [1]. It solves the same core problem as x402 and L402 — metered, account-free API access for agents and machines — but is explicitly designed to be method-agnostic: the same core Challenge/Credential/Receipt shape can carry Tempo, EVM, Stripe Card, Lightning, Solana, Stellar, Monad, or NEAR Intents payments [1][3].\n\nIt does not itself pick a payment network or currency: the core specification \"makes no claims or affordances to any specific payment method\" and is designed to work with any rail [2]. MPP is precise about status-code semantics in a way that differs from typical HTTP auth schemes — it uses 402 consistently for all payment-related failures (a fresh challenge, a malformed credential, an expired challenge, or a failed verification), reserving 401 for authentication failures unrelated to payment and 403 for cases where a valid payment was made but policy still denies access [1].\n\nMPP's governance is deliberately split in two: the core specification is co-authored by Tempo and Stripe and has been submitted to the IETF standards track under the name \"Payment HTTP Authentication Scheme,\" while individual payment methods are maintained separately by whoever supports that rail, which the project says \"keeps the protocol neutral while letting payment rails move at their own pace\" [2]. As of this verification the IETF submission's exact draft name/number was not independently located on the IETF datatracker, so its formal standing (individual submission vs. working-group adopted) is unconfirmed — mpp.dev's own \"IETF Specs\" card was checked but returned no distinct draft identifier in this pass. SDKs exist for TypeScript, Go, Ruby, Rust, and Python per the project's own site, and MPP maintains a direct compatibility/comparison page against x402 [3]. No independent adoption count was found; adoption is recorded as unmeasured.", "track": "vendor-consortium", "version": { "date": null, "label": "documented protocol overview on mpp.dev; normative text is the IETF-submitted 'Payment HTTP Authentication Scheme' draft" } }, { "acronym": "ERC-8004", "adoption": { "by": "Forbes (2026-02-05) citing community trackers; community-maintained awesome-erc8004 deployment list", "level": "claimed", "probe_run": null }, "aliases": [ "Trustless Agents" ], "analog": "DNS plus a public review/reputation ledger", "collisions": [], "discovery": { "mechanism": "ERC-721 Identity Registry token (agentId) resolves via agentURI to a JSON agent registration file; optional HTTPS domain proof at a fixed well-known path", "path": "/.well-known/agent-registration.json" }, "dispute": { "claims": [ "Forbes and community trackers describe mainnet deployment as of 2026-01-29, but this is not an IETF/W3C-style finalized standard — it remains a Draft ERC.", "getSummary() reputation reads require an explicit non-empty clientAddresses filter specifically because unfiltered aggregation is vulnerable to Sybil/spam feedback, per the spec's own Security Considerations.", "An independent June 2026 study found that most on-chain registrations are not backed by a live agent (3–15% valid, live registration files) and that reputation feedback is dominated by coordinated Sybil reviewers (~90.6%), so registration counts overstate real adoption and reputation scores are not yet usable for trust decisions [4]." ], "summary": "The Validation Registry (stake/zkML/TEE-backed independent checking) is not finalized while Identity and Reputation are; adoption is reported by trackers and press, not independently counted by us. Registration counts should be read as a ceiling: the June 2026 empirical study found only 3–15% of registrations point at a live endpoint." }, "evidence": [ { "claim": "EIP-8004 defines three per-chain singleton registries (Identity, Reputation, Validation) and the JSON agent registration file format, including the optional /.well-known/agent-registration.json domain-verification file", "date": "2025-08-13", "label": "VERIFIED", "url": "https://eips.ethereum.org/EIPS/eip-8004" }, { "claim": "Identity Registry (0x8004A169FB4a3325136EB29fA0ceB6D2e539a432) and Reputation Registry (0x8004BAa17C55a88189AE136b182e5fdA19dE9b63) deployed at identical addresses on Ethereum mainnet since 29 Jan 2026, after ~3 months of testnet use (10,000+ agents, 20,000+ feedback entries reported)", "date": "2026-02-05", "label": "VERIFIED", "url": "https://www.forbes.com/sites/digital-assets/2026/02/05/ai-agents-gain-trust-via-ethereum-erc-8004-on-mainnet/" }, { "claim": "Community-maintained tracker lists the same two contract addresses deployed identically across 16+ EVM chains (Base, Arbitrum, Optimism, Polygon, etc.) and documents the Validation Registry as still under active revision, unlike the finalized Identity/Reputation contracts", "date": null, "label": "REPORTED", "url": "https://github.com/sudeepb02/awesome-erc8004" }, { "claim": "Empirical study of 112,921 registrations across Ethereum, BSC and Base: only 3–15% expose a valid ERC-8004 registration file with at least one live service endpoint, and about 90.6% of reputation reviewers exhibit coordinated Sybil behaviour (Xiong et al., arXiv 2606.26028, 2026-06-24).", "date": "2026-06-24", "label": "VERIFIED", "url": "https://arxiv.org/abs/2606.26028" } ], "form": "onchain-registry", "governance": "Ethereum EIP process; no formal steward until finalized", "group": null, "history": [ { "date": "2026-09-05", "note": "seeded from Exa Agent research run" }, { "date": "2026-09-06", "note": "verified against EIP-8004 primary text, Forbes mainnet-launch report (2026-02-05), and community deployment tracker (awesome-erc8004)" }, { "date": "2026-09-07", "note": "added the arXiv 2606.26028 empirical study on live endpoints and Sybil feedback" } ], "id": "erc-8004", "implementation": "multi-implementation", "last_verified": "2026-09-07", "name": "ERC-8004: Trustless Agents", "native_status": "Draft Standards Track ERC", "origin": { "date": "2025-08-13", "org": "Ethereum community (De Rossi, Crapis, Ellis, Reppel)" }, "part_of": null, "parties": [ "agent-registry", "agent-agent" ], "phase": "draft", "probe": { "method": "GET", "on_absent": "Endpoint-domain control is not proven by this optional file; the agent's core identity may still be valid via the onchain agentURI directly (a JSON file at any URI scheme, not necessarily HTTPS at this path)", "parse": "JSON body has a registrations[] entry whose agentRegistry (eip155:{chainId}:{identityRegistry}) and agentId match the onchain agent being checked", "path": "https://{endpoint-domain}/.well-known/agent-registration.json" }, "question": "Who is an agent, and what onchain identity, reputation and validation record does it carry?", "scope": "general", "spec_url": "https://eips.ethereum.org/EIPS/eip-8004", "step": "identify", "summary_md": "ERC-8004 (\"Trustless Agents\") is a draft Ethereum standard that gives autonomous agents a portable, onchain identity plus pluggable trust signals, so that agents from different organizations can discover and transact with one another without a pre-existing relationship [1]. It defines three per-chain singleton registries: an Identity Registry (an ERC-721 token whose tokenURI, here called agentURI, points to a JSON registration file listing the agent's name, description and service endpoints — A2A agent cards, MCP endpoints, ENS names, DIDs, wallets); a Reputation Registry (a standard interface for clients to post signed numeric feedback, with onchain filtering by reviewer and tag to blunt Sybil attacks); and a Validation Registry (generic hooks for requesting and recording independent checks of an agent's work, e.g. by staked re-execution, zkML proofs, or TEE attestations) [1].\n\nIt solves discovery-plus-trust for cross-organizational agent economies: MCP and A2A cover how an agent is invoked and how it advertises skills, but neither defines a portable identity an unrelated party can look up and score [1]. ERC-8004 does not itself define payments (it notes x402 as a complementary, orthogonal protocol), does not prescribe how validation is actually computed (that is left to competing validator networks), and — by the authors' own admission — cannot cryptographically guarantee that an agent's advertised capabilities are functional or non-malicious; it only anchors identity and makes trust signals public and structured [1].\n\nCurrent state: still a Draft ERC (no EIP number finalization; created 2025-08-13) [1]. The Identity and Reputation Registry contracts went live on Ethereum mainnet on 2026-01-29 at deterministic addresses (0x8004A169... and 0x8004BAa1...), following roughly three months of testnet activity reported at over 10,000 registered agents and 20,000 feedback entries [2]. A community-maintained tracker shows the same two contracts redeployed at identical addresses across at least 16 EVM chains (Base, Arbitrum, Optimism, Polygon, Avalanche, and others), while listing the Validation Registry as still under active revision rather than finalized [3]. Reference implementations and a client-side verification dApp (AtlasNexus Verify) are cited by the same tracker [3].\n\nImplementers: the reference implementation repository (erc8004/reference-implementation), the coordinating site 8004.org, and independent tooling such as AtlasNexus Verify [2][3]. The EIP requires EIP-155, EIP-712, EIP-721 and EIP-1271 as building blocks [1].\n\nDisputed or unknown: adoption figures (10,000+ agents, 20,000+ feedback entries) come from press and community trackers, not a probe we ran ourselves, so we label them claimed rather than measured. It is also unresolved whether the Validation Registry will ship as specified or be substantially revised, and whether reputation aggregation across chains will be standardized or remain ad hoc per aggregator [1][3].", "track": "community", "version": { "date": "2025-08-13", "label": "Draft ERC, created 2025-08-13; Identity and Reputation Registries live on Ethereum mainnet since 2026-01-29" } }, { "acronym": "ERC-8183", "adoption": { "by": null, "level": "unmeasured", "probe_run": null }, "aliases": [ "EIP-8183" ], "analog": "Escrow contract with a third-party inspector", "collisions": [ "Agentic Commerce Protocol (OpenAI/Stripe ACP)" ], "discovery": { "mechanism": "EVM smart-contract interface (job created on an AgenticCommerce contract deployment)", "path": "none — no well-known file; discovery is by contract address/ABI" }, "dispute": { "claims": [ "ERC-8183 abstract: 'This specification defines the Agentic Commerce Protocol: a job with escrowed budget...'", "agentic-commerce-protocol record: OpenAI/Stripe/Meta-maintained REST checkout standard of the same colloquial name" ], "summary": "The proposal's own title and abstract call the standard 'the Agentic Commerce Protocol,' the same phrase used by the unrelated OpenAI/Stripe specification tracked in this dataset as 'agentic-commerce-protocol.' The two share no governance, code, or organization; ERC-8183 is an on-chain escrow/attestation primitive on Ethereum, while ACP is an off-chain REST checkout API maintained by OpenAI, Stripe, and Meta." }, "evidence": [ { "claim": "ERC-8183's abstract defines a job with escrowed budget and four states (Open, Funded, Submitted, Terminal outcomes Completed/Rejected/Expired), with an evaluator who alone may mark a submitted job completed, requires EIP-20, and cites composability with ERC-8004 for reputation. The EIP page lists a Discussion Link at Ethereum Magicians and names four individual authors, with a reference implementation (IACPHook.sol, AgenticCommerce.sol) included in the specification; status is Draft on the ERC standards track.", "date": "2026-02-25", "label": "VERIFIED", "url": "https://eips.ethereum.org/EIPS/eip-8183" }, { "claim": "The Ethereum Magicians discussion thread for ERC-8183 ('erc-8183-agentic-commerce') is live and hosts the proposal's community discussion, corroborating the EIP page's listed Discussion Link.", "date": "2026-02-25", "label": "REPORTED", "url": "https://ethereum-magicians.org/t/erc-8183-agentic-commerce/27902" } ], "form": "onchain-registry", "governance": "Ethereum EIP/ERC process (Ethereum Magicians discussion + EIPs repository); status Draft, an ERC Standards Track proposal, not yet Final", "group": null, "history": [ { "date": "2026-09-05", "note": "seeded from Exa Agent research run" }, { "date": "2026-09-06", "note": "verified against eips.ethereum.org/EIPS/eip-8183; flagged name collision with agentic-commerce-protocol (ACP)" } ], "id": "erc-8183", "implementation": "prototype", "last_verified": "2026-09-06", "name": "ERC-8183: Agentic Commerce", "native_status": "Draft ERC — 'This specification defines the Agentic Commerce Protocol: a job with escrowed budget...'", "origin": { "date": "2026-02-25", "org": "Ethereum community (Virtuals Protocol-affiliated authors)" }, "part_of": null, "parties": [ "agent-agent", "agent-site" ], "phase": "draft", "probe": { "method": "eth_call", "on_absent": "Absence at a given contract address only shows that specific deployment does not implement ERC-8183; there is no registry of ERC-8183 deployments to enumerate, so 'is ERC-8183 adopted' cannot be answered by any single probe.", "parse": "Contract implements the ERC-8183 job state machine functions (setBudget, fund, submit, complete, reject, claimRefund) and emits the corresponding lifecycle events; requires EIP-20 for the escrowed token", "path": "{contract_address}" }, "question": "How can two agents (a client and a provider) settle a job on-chain, with funds held in escrow and released only once an evaluator attests the work was done?", "scope": "commerce", "spec_url": "https://eips.ethereum.org/EIPS/eip-8183", "step": "pay", "summary_md": "ERC-8183 is a draft Ethereum standard (an ERC on the Standards Track) that defines a minimal on-chain escrow-and-attestation primitive for agent-to-agent commerce: a client locks a budget in an EIP-20 token, a provider submits work, and a designated evaluator (who can be the client itself) either attests completion — releasing escrow to the provider, minus an optional platform fee — or rejects, refunding the client [1]. A job moves through exactly six states (Open, Funded, Submitted, Completed, Rejected, Expired) with a fixed, small set of allowed transitions, and an optional attestation reason (e.g. a hash) is designed to compose with reputation systems such as ERC-8004 [1].\n\nIt solves the narrow case of \"client funds work, one attester says done or not done\" for agent marketplaces, deliberately keeping the surface small so implementations stay composable, and it explicitly leaves broader agent discovery, negotiation, and reputation to other standards [1]. It does not define off-chain messaging, does not specify how a client and provider find each other, and does not itself handle currencies other than EIP-20 tokens; it is a settlement primitive, not a full commerce protocol.\n\nAs of this verification (draft created 2026-02-25, still Draft status), ERC-8183 provides a reference implementation in Solidity (`AgenticCommerce.sol`, `IACPHook.sol`) inside the specification itself, and its authors — Davide Crapis, Bryan Lim, Tay Weixiong, and Chooi Zuhwa — include contributors associated with the Virtuals Protocol ecosystem (usernames `@ai-virtual-b`, `@twx-virtuals`) based on their GitHub handles, though no independent confirmation of employer affiliation was sought [1][2]. No deployed, audited, or adopted implementation beyond the reference contracts was located during this verification, so implementation is recorded as prototype and adoption as unmeasured.\n\nWhat is disputed: this proposal's abstract calls itself \"the Agentic Commerce Protocol,\" the identical informal name used for the unrelated OpenAI/Stripe/Meta REST checkout standard tracked separately in this dataset as `agentic-commerce-protocol`. The two are unconnected — different governance, different technology (on-chain escrow vs. off-chain REST checkout), different authors — and a reader searching \"Agentic Commerce Protocol\" could easily conflate them. This dataset disambiguates by acronym: ACP (OpenAI/Stripe/Meta) vs. ERC-8183.", "track": "community", "version": { "date": "2026-02-25", "label": "Draft, created 2026-02-25" } }, { "acronym": "ERC-8226", "adoption": { "by": null, "level": "unmeasured", "probe_run": null }, "aliases": [ "RAMS", "Regulated Agent Mandate Standard" ], "analog": "Power of attorney", "collisions": [], "discovery": { "mechanism": "EVM contract interface detection (ERC-165 supportsInterface for IAgentMandate)", "path": null }, "dispute": null, "evidence": [ { "claim": "The canonical spec text (abstract, motivation, IAgentMandate/IComplianceProvider interfaces, reference implementation) is published on eips.ethereum.org, status Draft, created 2026-04-12.", "date": "2026-04-12", "label": "VERIFIED", "url": "https://eips.ethereum.org/EIPS/eip-8226" }, { "claim": "The EIP's discussion thread and originating pull request on the ethereum/ERCs repo record the proposal's provenance and author affiliation with Brickken.", "date": "2026-05-12", "label": "REPORTED", "url": "https://github.com/ethereum/ERCs/pull/1844" } ], "form": "onchain-registry", "governance": "Ethereum ERC process (Ethereum Magicians discussion thread + ethereum/ERCs GitHub repo); not yet adopted by an EIP editor as Final", "group": null, "history": [ { "date": "2026-09-05", "note": "seeded from Exa Agent research run" }, { "date": "2026-09-06", "note": "verified against eips.ethereum.org/EIPS/eip-8226 and github.com/ethereum/ERCs/pull/1844" } ], "id": "erc-8226", "implementation": "prototype", "last_verified": "2026-09-06", "name": "ERC-8226 Regulated Agent Mandate", "native_status": "Draft, Standards Track: ERC (marked ⚠️ Draft on eips.ethereum.org)", "origin": { "date": "2026-04-12", "org": "Brickken (Ludovico Rossi, Dario Lo Buglio, Thamer Dridi, Nabil El Alami Khalifi)" }, "part_of": null, "parties": [ "agent-site" ], "phase": "draft", "probe": { "method": "ETH_CALL", "on_absent": "No IAgentMandate registry is deployed at the address; the asset contract carries no RAMS-conformant delegation layer", "parse": "Call reverts with false/error if no active mandate exists; a successful bool return with mandate data proves an IAgentMandate registry is deployed at {contract}", "path": "{contract}.canExecute(agent, principal, asset, action, amount) via eth_call against IAgentMandate" }, "question": "What scoped, time-bounded, and financially capped authority may an on-chain agent exercise on a regulated asset holder's behalf?", "scope": "commerce", "spec_url": "https://eips.ethereum.org/EIPS/eip-8226", "step": "permit", "summary_md": "ERC-8226, also called the Regulated Agent Mandate Standard (RAMS), is a Draft Ethereum Request for Comments that defines a compliance-delegation layer for AI agents acting on tokenized regulated assets such as securities or fund units [1]. It answers the permit question for on-chain agents: what scoped, time-bounded, financially capped authority has a KYC-cleared principal granted an agent, and how does a regulated token contract check that authority before letting the agent's call through.\n\nThe spec defines two Solidity interfaces: `IAgentMandate`, a registry keyed by (agent, principal) pairs that exposes `canExecute` for pre-flight checks and `recordExecution` for logging use, and `IComplianceProvider`, which lets a token-compliance framework plug in. Mandates cap a transferred quantity (token amount for ERC-20/ERC-1155, count for ERC-721) per asset address, can be time-limited, and can be frozen (halted but not revoked) by an authorized enforcer while only the principal can revoke outright. RAMS is explicitly agnostic to the agent-identity standard used (it names ERC-8004 as a compatible example), the token standard (ERC-20/721/1155), and the regulated-token compliance framework (it names ERC-7943 and ERC-3643) [1].\n\nIt does not itself provide agent identity, KYC verification, or token-transfer-eligibility logic; those are left to the named companion standards. It does not define an off-chain permission surface (no well-known file or HTTP header) — the entire mechanism is on-chain, discoverable only by probing whether a given regulated-token deployment has wired an IAgentMandate-conformant registry into its transfer checks.\n\nAs of this verification (2026-09-06) the proposal is Draft status, created 2026-04-12 by four authors affiliated with Brickken, a tokenized real-world-asset platform, with an open Ethereum Magicians discussion thread and a merged pull request into the community ethereum/ERCs repository dated 2026-05-12 [1][2]. A reference implementation and test suite (IAgentMandate registry, IComplianceProvider, an optional IAgentExecutor forwarding interface, a RamsGated base contract, and an ERC-7943 asset that inherits it) ship alongside the spec text, but this is the proposers' own reference code, not an independent production deployment [1].\n\nWhat is unresolved: no independent implementer, regulated-asset platform, or agent-identity project has been found describing production use of RAMS; adoption is unmeasured. It is unclear whether RAMS will progress through EIP editor review toward Final status, whether it will compete with or be folded into ERC-8004's agent-identity ecosystem, and whether real KYC/regulatory infrastructure will treat an on-chain mandate as legally sufficient without off-chain paperwork.", "track": "community", "version": { "date": "2026-04-12", "label": "Draft, created 2026-04-12" } }, { "acronym": "", "adoption": { "by": null, "level": "unmeasured", "probe_run": null }, "aliases": [], "analog": "In-page JavaScript API (window.* APIs)", "collisions": [ "Model Context Protocol (MCP)" ], "discovery": { "mechanism": "In-page JavaScript object (window.modelContext / the ModelContext tool map); a page registers tools imperatively (registerTool()) or declaratively via annotated HTML form elements", "path": "none — a client or agent must load the page itself to see whether it registers WebMCP tools; this is a stated limitation of the API (\"Clients and browsers must visit a site directly to know if it has callable tools\")" }, "dispute": null, "evidence": [ { "claim": "WebMCP API enables web applications to provide JavaScript-based tools to AI agents; published as a Draft Community Group Report by the W3C Web Machine Learning Community Group, dated 4 September 2026, explicitly not on the W3C Standards Track. Editors are from Microsoft and Google.", "date": "2026-09-04", "label": "VERIFIED", "url": "https://webmachinelearning.github.io/webmcp/" }, { "claim": "Chrome runs a WebMCP origin trial starting Chrome 149, with a chrome://flags/#enable-webmcp-testing local-development flag; two APIs exist (imperative and declarative); published demos and a Model Context Tool Inspector Chrome extension exist. Last updated 2026-08-07.", "date": "2026-08-07", "label": "VERIFIED", "url": "https://developer.chrome.com/docs/ai/webmcp" } ], "form": "browser-api", "governance": "W3C Web Machine Learning Community Group; editors are Brandon Walderman (Microsoft), Khushal Sagar (Google), Dominic Farolino (Google)", "group": null, "history": [ { "date": "2026-09-05", "note": "seeded from Exa Agent research run" }, { "date": "2026-09-06", "note": "verified against webmachinelearning.github.io/webmcp (4 Sept 2026 draft) and developer.chrome.com/docs/ai/webmcp (updated 2026-08-07); Cloudflare BrowserRun claim dropped, unverified in this pass" } ], "id": "webmcp", "implementation": "developer-trial", "last_verified": "2026-09-06", "name": "WebMCP", "native_status": "Draft Community Group Report, dated 4 September 2026; explicitly \"not a W3C Standard nor on the W3C Standards Track\"", "origin": { "date": "2026", "org": "Google and Microsoft engineers, via the W3C Web Machine Learning Community Group" }, "part_of": null, "parties": [ "agent-site" ], "phase": "draft", "probe": { "method": "in-page script execution (not a network probe)", "on_absent": "window.modelContext is undefined, or getTools() returns an empty map: the page exposes no WebMCP tools (this cannot be checked without executing JavaScript in a real browser context — it is not curl-probable)", "parse": "presence of a non-empty tool map returned by getTools() (or the declarative equivalent synthesized from annotated form elements)", "path": "typeof window.modelContext !== 'undefined' && window.modelContext.getTools()" }, "question": "What JavaScript tools can a web page register so an in-browser AI agent can call them directly instead of scraping the DOM?", "scope": "general", "spec_url": "https://webmachinelearning.github.io/webmcp/", "step": "act", "summary_md": "WebMCP is a proposed JavaScript API that lets a web page register \"tools\" — functions with natural-language descriptions and JSON Schema input definitions — that an AI agent (in-browser or otherwise) can call directly, instead of inferring intent by scraping the rendered DOM [1]. A page using WebMCP can be thought of as running an MCP server client-side: the tool concepts (name, description, input schema, annotations) deliberately mirror MCP's tool definition so that the same mental model and, in principle, the same downstream tooling apply on both sides of the fetch boundary [1].\n\nIt solves the reliability gap in DOM-scraping-based browser agents: rather than an agent guessing which button does \"checkout\" from visual and structural cues, the site declares the tool's purpose explicitly, with a JSON Schema for inputs, reducing hallucination and misclicks [2]. It supports two authoring styles: an imperative JavaScript API (registerTool()) and a declarative API that annotates standard HTML form elements.\n\nWebMCP does not solve discovery at scale: a client or crawler cannot learn whether a given origin exposes WebMCP tools without loading the page and executing its JavaScript — the Chrome team's own documentation lists \"tool discoverability\" as a stated limitation, alongside unsuitability for headless/automated scenarios (it is designed for a human-in-the-loop local browser session) and added engineering overhead for complex interfaces [2]. It also does not standardize server-side or non-browser agent tool-calling; that is MCP's job.\n\nAs of this verification (September 2026), WebMCP is a W3C Community Group Draft Report — not a W3C Standard and not on the Standards Track — dated 4 September 2026, edited by engineers from Microsoft and Google [1]. Chrome is running a public origin trial from Chrome 149 (Intent to Experiment filed with blink-dev), with a local-development flag (chrome://flags/#enable-webmcp-testing) and a Chrome Web Store \"Model Context Tool Inspector\" extension for manually exercising tools; documentation was last updated 2026-08-07 [2]. The seed record's premise that Cloudflare's BrowserRun product had confirmed WebMCP support (per a 2026-08-06 Cloudflare blog post) could not be verified in this pass — that specific page was not fetched, so this claim is dropped rather than carried forward unsourced; it should be checked directly in a future pass. What remains open: whether any browser besides Chrome will implement WebMCP, and whether the spec advances beyond Community Group status toward a W3C Working Group.", "track": "w3c", "version": { "date": "2026-09-04", "label": "Draft Community Group Report, 4 September 2026" } }, { "acronym": "", "adoption": { "by": null, "level": "unmeasured", "probe_run": null }, "aliases": [], "analog": "HTML for machine-readable, natural-language site content", "collisions": [], "discovery": { "mechanism": "None standardized; the project's own README points to a spec page (nlweb.ai/spec) for the protocol details, but that domain does not currently resolve", "path": "none confirmed; nlweb.ai (including nlweb.ai/spec) was unreachable via curl and firecrawl in this verification pass" }, "dispute": { "claims": [ "README claims a formal spec exists at nlweb.ai/spec", "That domain was unreachable during this verification (2026-09-06)" ], "summary": "The spec_url for NLWeb's actual wire protocol (nlweb.ai/spec) is unreachable, so this row's `spec_url` points to the GitHub README (which describes but does not itself specify the protocol) rather than to a canonical spec document. The protocol details (exact `ask` request/response shape beyond 'Schema.org JSON') could not be independently confirmed from a live spec in this pass." }, "evidence": [ { "claim": "NLWeb natively supports MCP; every NLWeb instance also acts as an MCP server exposing a core `ask` method that takes a natural-language question and returns Schema.org-formatted JSON. The project describes itself as 'to MCP/A2A what HTML is to HTTP' and as a proof-of-concept the community is invited to surpass with its own implementations.", "date": "2026", "label": "VERIFIED", "url": "https://github.com/nlweb-ai/NLWeb" }, { "claim": "github.com/microsoft/NLWeb redirects to github.com/nlweb-ai/NLWeb, i.e. the reference implementation's canonical home moved off the microsoft org to a dedicated community org between the original Microsoft announcement and this check.", "date": "2026-09-06", "label": "VERIFIED", "url": "https://github.com/microsoft/NLWeb" }, { "claim": "nlweb.ai (the domain hosting the protocol spec referenced by the README) did not resolve/respond via curl or firecrawl_scrape on 2026-09-06, corroborating the task brief that nlweb.ai is down.", "date": "2026-09-06", "label": "REPORTED", "url": "https://nlweb.ai/spec" } ], "form": "endpoint", "governance": "Originated at Microsoft; the reference implementation now lives under a separate community GitHub org (nlweb-ai), not microsoft/NLWeb directly — github.com/microsoft/NLWeb redirects to github.com/nlweb-ai/NLWeb", "group": null, "history": [ { "date": "2026-09-05", "note": "seeded from Exa Agent research run" }, { "date": "2026-09-06", "note": "verified against github.com/microsoft/NLWeb (redirects to github.com/nlweb-ai/NLWeb); nlweb.ai/spec confirmed unreachable via curl and firecrawl" } ], "id": "nlweb", "implementation": "prototype", "last_verified": "2026-09-06", "name": "NLWeb", "native_status": "\"Main reference implementation... implemented in Python\"; described by its own README as a proof-of-concept the community is invited to build alternative implementations of, not a definitive solution", "origin": { "date": "2025", "org": "Microsoft" }, "part_of": null, "parties": [ "agent-site" ], "phase": "draft", "probe": { "method": "POST", "on_absent": "connection refused, 404, or a non-Schema.org JSON shape means no NLWeb endpoint is present", "parse": "a JSON response using Schema.org vocabulary answering the natural-language question in the request body proves NLWeb (or an MCP-exposed equivalent) is present; every NLWeb instance also runs as an MCP server exposing an `ask` tool/method", "path": "{origin}/ask" }, "question": "How can a site expose a natural-language question-answering interface grounded in its own Schema.org-structured content, for both humans and agents?", "scope": "general", "spec_url": "https://github.com/nlweb-ai/NLWeb", "step": "act", "summary_md": "NLWeb is a collection of open protocols and an accompanying open-source reference implementation for adding a conversational, natural-language question-answering interface to a website, grounded in the Schema.org and RSS structured markup that the README says over 100 million sites already publish [1]. Its central design idea is that a site's existing semi-structured markup can double as the semantic layer a natural-language interface needs, so adding a conversational endpoint does not require rebuilding a site's content model from scratch.\n\nNLWeb solves the problem of giving both human users and AI agents a single natural-language entry point into a site's content: every NLWeb instance exposes a core `ask` method — as a plain endpoint and, natively, as an MCP server tool — that takes a natural-language question and returns a JSON response using Schema.org vocabulary [1]. The project's own framing is explicit: \"NLWeb is to MCP/A2A what HTML is to HTTP\" — i.e. it proposes to be the content layer that sits on top of the agent-to-tool and agent-to-agent transport layers, not a competitor to either [1].\n\nNLWeb does not itself specify agent-to-agent coordination (it says A2A support is 'soon', not shipped) and it explicitly disclaims being a definitive or complete answer: the README frames the reference implementation as \"proof-of-concept demonstrations showing one possible approach\" and invites the community to build \"diverse, innovative implementations that surpass our examples\" [1]. It also does not define a standardized discovery mechanism (no well-known path is specified for locating a site's `ask` endpoint), and the project's canonical protocol-specification page, linked from the README as nlweb.ai/spec, did not resolve during this verification pass (2026-09-06), so the wire-level protocol details beyond \"Schema.org-shaped JSON over an `ask` method\" could not be independently confirmed from a live spec document [3].\n\nAs of this check, the reference implementation's canonical home has moved: `github.com/microsoft/NLWeb` now redirects to `github.com/nlweb-ai/NLWeb`, a separate GitHub organization, rather than staying under the `microsoft` org [2]. This is a governance-relevant shift the seed record's plain \"Microsoft\" governance label did not capture — Microsoft originated the project and still supports it (contact is an @microsoft.com address, and Microsoft's trademark guidance is referenced in the README), but the repository itself now lives under a nominally independent community org. Support spans multiple vector stores (Qdrant, Snowflake, Milvus, Azure AI Search, Elasticsearch, Postgres, Cloudflare AutoRAG) and multiple LLM providers (OpenAI, DeepSeek, Gemini, Anthropic, Inception, HuggingFace), which is a broader integration surface than a typical single-vendor prototype, but no independent count of live NLWeb deployments was found, so adoption remains unmeasured. What is unresolved: why nlweb.ai is down, whether the org move to nlweb-ai signals an intended governance change (e.g. toward a foundation or away from Microsoft) or is incidental, and what the actual `ask` request/response schema is now that the spec page is unreachable.", "track": "community", "version": { "date": null, "label": "unversioned; MIT-licensed, actively committed" } }, { "acronym": "", "adoption": { "by": null, "level": "observed", "probe_run": null }, "aliases": [ "Agent Skills", "SKILL.md" ], "analog": "Package README / plugin manifest", "collisions": [ "MCP \"Skills over MCP\" working group (a related but distinct proposal for discovering skills through MCP itself)" ], "discovery": { "mechanism": "Filesystem/package convention: a directory containing a SKILL.md file with YAML frontmatter (required fields name, description) plus Markdown instructions; agents discover skills by scanning known skill directories, loading only name+description at startup (\"progressive disclosure\") and the full body only on activation", "path": "/SKILL.md (directory name must match the frontmatter name field)" }, "dispute": null, "evidence": [ { "claim": "Agent Skills is a lightweight open format: a skill is a directory with a required SKILL.md (YAML frontmatter with required name and description fields, optional license/compatibility/metadata/allowed-tools) plus Markdown instructions and optional scripts/, references/, assets/ directories; agents load skills via three-stage progressive disclosure (discovery of name+description, activation loads the full body, execution loads bundled resources on demand). Validation tooling ships as skills-ref.", "date": "2026", "label": "VERIFIED", "url": "https://agentskills.io/specification" }, { "claim": "\"The Agent Skills format was originally developed by Anthropic, released as an open standard, and has been adopted by a growing number of agent products. The standard is open to contributions from the broader ecosystem\" — development happens on github.com/agentskills/agentskills and a public Discord. A client showcase lists dozens of named adopting products including Claude Code, Claude.ai, Cursor, GitHub Copilot, VS Code, Gemini CLI, ChatGPT & Codex, JetBrains Junie, Amp, OpenHands, Goose, Letta, Factory, Roo Code, OpenCode, Snowflake Cortex Code, Databricks Genie Code, and Spring AI, among ~35 named logos.", "date": "2026", "label": "VERIFIED", "url": "https://agentskills.io" } ], "form": "document-format", "governance": "Originally developed and released as an open format by Anthropic; now described by its own site as \"open to contributions from the broader ecosystem\" with development happening in the community-run github.com/agentskills/agentskills org and a public Discord", "group": null, "history": [ { "date": "2026-09-05", "note": "seeded from Exa Agent research run" }, { "date": "2026-09-06", "note": "verified against agentskills.io and agentskills.io/specification" } ], "id": "anthropic-agent-skills-format", "implementation": "multi-implementation", "last_verified": "2026-09-06", "name": "Agent Skills", "native_status": "Active open format, described on agentskills.io as adopted by a growing number of agent products", "origin": { "date": "2025", "org": "Anthropic" }, "part_of": null, "parties": [ "agent-site" ], "phase": "living", "probe": { "method": "filesystem read (not a network probe)", "on_absent": "no SKILL.md at that path, or frontmatter missing required fields: not a valid Agent Skill", "parse": "YAML frontmatter containing required `name` (max 64 chars, lowercase/digits/hyphens) and `description` (max 1024 chars) fields, per the agentskills.io specification", "path": "{skills-dir}/{skill-name}/SKILL.md" }, "question": "How can reusable, on-demand procedural instructions and bundled resources be packaged so any compatible agent can load and run them?", "scope": "coding-tools", "spec_url": "https://agentskills.io/specification", "step": "act", "summary_md": "Agent Skills is an open packaging format for reusable procedural knowledge: a \"skill\" is a directory containing a required `SKILL.md` file (YAML frontmatter with a `name` and `description`, plus optional `license`, `compatibility`, `metadata`, and experimental `allowed-tools` fields) followed by Markdown instructions, and optionally `scripts/`, `references/`, and `assets/` subdirectories for executable code, longer documentation, and templates respectively [1]. It solves the problem of giving an agent domain-specific, team- or user-specific know-how — a legal review checklist, a data pipeline procedure — as a portable, version-controllable unit that works across any compatible agent product, rather than being locked into one vendor's prompt-engineering conventions [2].\n\nThe format's core mechanism is progressive disclosure in three stages: at startup an agent loads only the `name` and `description` (roughly 100 tokens) for every available skill; when a task matches a description, the agent loads the full `SKILL.md` body (recommended under 5,000 tokens); only when the instructions call for it does the agent load bundled scripts, references, or assets [1]. This keeps large skill libraries cheap to keep \"on hand\" without bloating context.\n\nAgent Skills does not define how an agent discovers which skill directories exist in the first place (that is left to each host's own conventions — e.g. a fixed `.claude/skills/` or `~/.codex/skills/` directory) and does not define a runtime protocol for invoking a skill over a network; it is purely a file-format and loading-behavior convention, distinct from the related but separate \"Skills over MCP\" working-group effort that is exploring discovering skills *through* MCP itself, which this row does not cover (cross-reference — see mcp record).\n\nAs of this verification (September 2026), the format was \"originally developed by Anthropic\" but its own site now states it is \"released as an open standard\" and \"open to contributions from the broader ecosystem,\" with development happening in a dedicated `agentskills/agentskills` GitHub organization and public Discord rather than solely inside Anthropic's repos [2] — a materially more open governance picture than the seed record's plain \"Anthropic\" / \"Agent Skills ecosystem\" labels captured. A client showcase names roughly 35 adopting products spanning coding agents (Claude Code, Cursor, GitHub Copilot, VS Code, JetBrains Junie, Amp, OpenHands, Goose, Roo Code, OpenCode, Factory), general assistants (Claude.ai, Gemini CLI, ChatGPT & Codex), and enterprise platforms (Snowflake Cortex Code, Databricks Genie Code, Spring AI) [2]. This is direct, first-party observation of a broad adopter list rather than a systematic count, so adoption here is recorded as `observed`, not `measured`. What remains open: no version number is attached to the specification itself (it is presented as a living document), and the relationship/overlap between this format and the MCP \"Skills over MCP\" working group's discovery mechanism has not been reconciled by either project as of this check.", "track": "community", "version": { "date": null, "label": "unversioned living spec (agentskills.io/specification)" } }, { "acronym": "", "adoption": { "by": "Rankability (Tranco top-1000, June 2026: 8.7%) and SE Ranking (~300,000 domains analyzed: 10.13%) — independent third-party publisher-side counts, not our own probe", "level": "claimed", "probe_run": null }, "aliases": [ "llmstxt.org" ], "analog": "sitemap.xml / a README for a site's documentation", "collisions": [], "discovery": { "mechanism": "Fixed filename at the site root or at any subpath, covering the pages under that path", "path": "/llms.txt (or //llms.txt, e.g. /docs/llms.txt)" }, "dispute": { "claims": [ "llmstxt.org and hosting-platform vendors (Mintlify, GitBook, Wix, Yoast, AIOSEO) present growing publisher adoption as evidence of success", "Google Search Central states plainly that llms.txt is unnecessary for its generative AI features and lists it as a myth to ignore", "Ahrefs' traffic-log study found 97% of published llms.txt files are never read by any client" ], "summary": "Publisher-side adoption (thousands of sites, roughly 8-10% of measured domain samples) is separate from and should not be conflated with consumption: no answer engine has documented reading llms.txt, Google explicitly says its generative AI features don't use it, and a large-scale log analysis found the great majority of published files are never fetched." }, "evidence": [ { "claim": "Full v2 proposal text: file grammar, discovery link relations (rel=\"alternate\" type=\"text/markdown\", rel=\"describedby\"), relationship to robots.txt/sitemap.xml, and that AI labs (OpenAI, Anthropic, Gemini) publish llms.txt for their own docs", "date": "2026-08", "label": "VERIFIED", "url": "https://llmstxt.org" }, { "claim": "v2 (August 2026) changelog: adds standard link relations for discoverability, allows both `page.html.md` and `page.md` forms, defines what a subpath file covers, and drops the v1 context-expansion tooling and the mechanical meaning of the \"Optional\" section", "date": "2026-08", "label": "VERIFIED", "url": "https://llmstxt.org/changes.html" }, { "claim": "Google's official Search Central guidance (last updated 2026-07-10) lists \"LLMS.txt files and other 'special' markup\" under things site owners can ignore, stating Google Search's generative AI features do not use them", "date": "2026-07-10", "label": "VERIFIED", "url": "https://developers.google.com/search/docs/fundamentals/ai-optimization-guide" }, { "claim": "8.7% of the Tranco top-1,000 domains and 5.6% of the top-10,000 published a valid llms.txt file as of June 2026", "date": "2026-06", "label": "REPORTED", "url": "https://www.rankability.com/data/llms-txt-adoption/" }, { "claim": "Across a dataset of nearly 300,000 domains, 10.13% carried an llms.txt file, with adoption not concentrated among high-traffic sites (8.27% for 100,001+ visit sites vs 10.54% for mid-traffic sites)", "date": "2026", "label": "REPORTED", "url": "https://seranking.com/blog/llms-txt/" }, { "claim": "Analysis of 137,000 sites publishing llms.txt found 97% of the files were never fetched by any client in the observation window; of requests that did reach a file, 96% came from bots rather than identifiable AI assistants", "date": "2026", "label": "REPORTED", "url": "https://ahrefs.com/blog/llmstxt-study/" } ], "form": "well-known-file", "governance": "Jeremy Howard / Answer.AI; maintained as an open proposal in the AnswerDotAI/llms-txt GitHub repository with a public Discord for implementation discussion", "group": null, "history": [ { "date": "2026-09-05", "note": "seeded from Exa Agent research run" }, { "date": "2026-09-06", "note": "verified against llmstxt.org (v2, Aug 2026), llmstxt.org/changes.html, Google's AI optimization guide, and three independent third-party adoption studies (Rankability, SE Ranking, Ahrefs)" } ], "id": "llms-txt", "implementation": "multi-implementation", "last_verified": "2026-09-06", "name": "llms.txt", "native_status": "\"This is v2 of the proposal\" — explicitly a community proposal open for input, not a standards-track document", "origin": { "date": "2024-09", "org": "Jeremy Howard / Answer.AI" }, "part_of": null, "parties": [ "agent-site" ], "phase": "draft", "probe": { "method": "GET", "on_absent": "No llms.txt at this path; a more specific subpath file (e.g. /docs/llms.txt) may still exist and take precedence for that subpath", "parse": "200 response beginning with an H1 heading (`# `) followed by a blockquote summary, per the llms.txt v2 grammar", "path": "{origin}/llms.txt" }, "question": "Where can an agent find a concise, curated map of a site's content, written for language models rather than browsers?", "scope": "general", "spec_url": "https://llmstxt.org", "step": "read", "summary_md": "llms.txt is a proposed convention for publishing a small, curated, markdown-formatted index of a site's content at `/llms.txt` (or a subpath such as `/docs/llms.txt`), intended to be read by language models and AI agents rather than crawled and scraped like a full site [1]. The file is one required H1 heading naming the project, an optional blockquote summary, optional free-form context, and then H2-delimited \"file lists\" of markdown links to more detailed content — typically clean `.md` mirrors of a site's HTML pages [1].\n\nIt solves a narrow problem: HTML pages are built for browsers, wrap information in navigation and scripts that are wasteful to parse into an LLM's limited context window, and give an agent no small, authoritative starting point for a large site. llms.txt gives a site a place to say \"start here\" and to link to markdown-native content instead of full HTML [1].\n\nIt does not solve discovery for sites that don't publish one, does not replace `robots.txt` (a permission signal, not a content index) or `sitemap.xml` (exhaustive, for search-engine crawlers, and usually not markdown-native) [1], and — critically — it does not guarantee that anything reads it. Google's own Search Central documentation, last updated 2026-07-10, explicitly tells site owners they \"don't need to create ... llms.txt\" because \"Google Search itself doesn't use them,\" filing it alongside other AEO/GEO \"hacks\" to ignore [3]. No answer engine has published documentation describing llms.txt consumption in its retrieval pipeline.\n\nThe current text is v2, published August 2026, revising the original September 2024 proposal by Jeremy Howard (Answer.AI). v2's main addition is standard discovery link relations (`rel=\"alternate\" type=\"text/markdown\"` for a page's markdown twin, `rel=\"describedby\"` for the covering llms.txt file), expressible as HTML `` tags or an HTTP `Link:` header; it also loosened the markdown-mirror URL convention and dropped the v1 context-expansion tooling and the special meaning of the \"Optional\" section [1][2]. The specification remains an informal, single-maintainer GitHub proposal, not a standards-track document of any kind [1].\n\nOn the producer side, several documentation platforms and CMSs generate llms.txt automatically — Mintlify, GitBook, Yoast SEO, AIOSEO, and Wix — and OpenAI, Anthropic, and Google publish llms.txt for their own developer docs [1]. This is genuine, if modest, publisher-side adoption: independent Tranco-based studies put it at roughly 8.7% of the top 1,000 domains (June 2026) and 5.6% of the top 10,000 [4], while a broader ~300,000-domain analysis found 10.13% overall, spread fairly evenly across traffic tiers rather than concentrated among high-traffic sites [5].\n\nWhat is disputed or unknown is consumption, not existence. The gap between \"a file exists\" and \"a model reads it\" is large and, per the sources available, mostly unmeasured by anyone with visibility into model retrieval internals. One large-scale server-log study of 137,000 llms.txt-publishing sites found 97% of the files were never fetched by any client during the observation window, and of the requests that did arrive, 96% came from generic bots rather than identifiable AI assistants [6]. Combined with Google's explicit statement that its own systems ignore the file, the safest characterization is: llms.txt is a real, growing publisher-side convention with no documented reader among major answer engines as of mid-2026.", "track": "single-vendor", "version": { "date": "2026-08", "label": "v2" } }, { "acronym": "", "adoption": { "by": "agents.md (site claims over 60,000 AGENTS.md files across open-source GitHub repositories, via a `path:AGENTS.md NOT is:fork NOT is:archived` code search)", "level": "claimed", "probe_run": null }, "aliases": [], "analog": "CONTRIBUTING.md / a repository's contributor instructions, but written for an agent instead of a human contributor", "collisions": [ "AGENT.md (legacy pre-merge filename some tools symlink for backward compatibility)" ], "discovery": { "mechanism": "Fixed filename at a repository's root; agents read the nearest AGENTS.md up the directory tree from the file being edited, so a nested file in a monorepo package takes precedence over the root file", "path": "AGENTS.md" }, "dispute": null, "evidence": [ { "claim": "Full AGENTS.md rationale, format (no required fields, closest-file-wins precedence), FAQ, migration guidance, and current list of 25+ adopting tools (Codex, Amp, Jules, Cursor, Factory, Devin, Aider, goose, Ona, VS Code, Zed, Windsurf, GitHub Copilot coding agent, Warp, Junie, RooCode, Phoenix, Augment Code, Kilo Code, opencode, and more). \"AGENTS.md is now stewarded by the Agentic AI Foundation under the Linux Foundation\".", "date": "2026-09", "label": "VERIFIED", "url": "https://agents.md" }, { "claim": "AGENTS.md was released by OpenAI in August 2025, emerging from collaboration across OpenAI Codex, Amp, Jules (Google), Cursor, and Factory", "date": "2026", "label": "REPORTED", "url": "https://blog.stackademic.com/agents-md-the-readme-your-ai-coding-agent-actually-reads-e634b7e2de34" }, { "claim": "OpenAI's own harness-engineering writeup for the Codex repository references \"the initial AGENTS.md file that directs agents how to work in\" the repo, corroborating OpenAI's originating role", "date": "2026", "label": "REPORTED", "url": "https://openai.com/index/harness-engineering/" } ], "form": "well-known-file", "governance": "Agentic AI Foundation (AAIF), a Linux Foundation project", "group": null, "history": [ { "date": "2026-09-05", "note": "seeded from Exa Agent research run" }, { "date": "2026-09-06", "note": "verified against agents.md, OpenAI's harness-engineering post, and a secondary account of the August 2025 launch" } ], "id": "agents-md", "implementation": "multi-implementation", "last_verified": "2026-09-06", "name": "AGENTS.md", "native_status": "\"An open format... regardless of which coding agent you use\"; explicitly not proprietary to any one tool", "origin": { "date": "2025-08", "org": "OpenAI (Codex team), in collaboration with Amp, Google (Jules), Cursor, and Factory" }, "part_of": null, "parties": [ "agent-site" ], "phase": "living", "probe": { "method": "GET", "on_absent": "No repository-level agent instructions are declared; an agent falls back to inferring conventions from the codebase or README", "parse": "200 response containing markdown text; presence alone is the signal since there are no required fields or schema", "path": "{origin}/AGENTS.md (repository-root fetch, e.g. raw.githubusercontent.com///HEAD/AGENTS.md)" }, "question": "What build, test, and convention instructions should a coding agent follow in this repository?", "scope": "coding-tools", "spec_url": "https://agents.md", "step": "read", "summary_md": "AGENTS.md is an open convention for a markdown file placed at a repository's root (or nested inside subpackages) that gives coding agents the operational context a human-facing README would clutter: build and test commands, code-style rules, security considerations, and PR conventions [1]. It complements, rather than replaces, README.md: the README stays focused on human contributors while AGENTS.md carries agent-specific detail [1].\n\nIt solves the problem of giving many different coding agents — Codex, Claude Code, Cursor, Copilot, and dozens of others — one predictable, tool-agnostic place to find per-repository instructions, instead of every vendor inventing its own proprietary rules file (`.cursorrules`, `CLAUDE.md`, etc., some of which are still separately supported alongside it). It has no required fields or schema: \"AGENTS.md is just standard Markdown. Use any headings you like; the agent simply parses the text you provide\" [1]. In a monorepo, nested AGENTS.md files are supported and the closest file to the edited path wins, letting each subproject carry tailored instructions; the OpenAI repository itself reportedly has 88 such files [1].\n\nIt does not enforce anything: whether an agent actually runs the test commands it lists is a matter of each tool's own behavior, and explicit user chat instructions always override the file's contents [1]. It is not a machine-readable manifest (no capability declarations, no discovery well-known path) — it is read as freeform prose, closer to documentation than to a protocol.\n\nCurrent state: the format launched in August 2025, originating from OpenAI's Codex team working with Amp, Google's Jules, Cursor, and Factory [1][2][3]. As of this verification (September 2026) it is stewarded by the Agentic AI Foundation (AAIF), a Linux Foundation project, and is supported by more than two dozen coding tools and agents, including several that also support a proprietary rules file of their own alongside it (Zed, Windsurf, RooCode, Kilo Code, opencode) [1]. The project's own site claims over 60,000 AGENTS.md files exist across public, non-fork, non-archived GitHub repositories, based on a GitHub code search rather than an independent crawl [1].\n\nWhat is disputed or unknown: the 60,000+ figure is a claim by the format's own stewards, not an independently reproduced count, and no third-party adoption study analogous to the llms.txt Tranco studies was found during this verification. It is also unclear how much of AAIF's governance is substantive versus a naming step shortly after Linux Foundation involvement was announced (2026), since the specification text itself has not visibly changed in structure since the original release.", "track": "linux-foundation", "version": { "date": "2026-09", "label": "current site guidance (living document)" } }, { "acronym": "AIPREF", "adoption": { "by": null, "level": "unmeasured", "probe_run": null }, "aliases": [ "draft-ietf-aipref-attach" ], "analog": "robots.txt plus HTTP representation metadata", "collisions": [], "discovery": { "mechanism": "robots.txt directive and/or Content-Usage HTTP response header, both updating RFC 9309", "path": "/robots.txt" }, "dispute": null, "evidence": [ { "claim": "draft-ietf-aipref-attach-05, dated 2026-08-19, defines attachment via the Robots Exclusion Protocol and an HTTP header field, and states it updates RFC 9309.", "date": "2026-08-19", "label": "VERIFIED", "url": "https://www.ietf.org/archive/id/draft-ietf-aipref-attach-05.html" }, { "claim": "The working document is developed on GitHub by the ietf-wg-aipref organization with an issue tracker and a rendered latest draft.", "date": "2026-08-19", "label": "REPORTED", "url": "https://datatracker.ietf.org/doc/html/draft-ietf-aipref-vocab-07" } ], "form": "well-known-file", "governance": "IETF AI Preferences Working Group (ai-control@ietf.org mailing list)", "group": "AIPREF", "history": [ { "date": "2026-09-05", "note": "seeded from Exa Agent research run" }, { "date": "2026-09-06", "note": "verified against ietf.org/archive/id/draft-ietf-aipref-attach-05.html" } ], "id": "aipref-content-usage-attachment", "implementation": "unknown", "last_verified": "2026-09-06", "name": "AIPREF Content-Usage Attachment", "native_status": "Internet-Draft, work in progress; \"About This Document\" note says it is to be removed before publishing as an RFC", "origin": { "date": "2025", "org": "IETF AI Preferences (aipref) Working Group" }, "part_of": null, "parties": [ "agent-site" ], "phase": "working-group", "probe": { "method": "GET", "on_absent": "Publisher has not attached machine-readable AI-use preferences via either attachment method; no inference can be drawn about actual policy", "parse": "Presence of a 'Content-Usage' line in a robots.txt group, or a Content-Usage HTTP response header on the fetched resource itself", "path": "{origin}/robots.txt" }, "question": "How does a publisher attach its AI-use preferences to content served over HTTP, so an automated system can find them?", "scope": "general", "spec_url": "https://www.ietf.org/archive/id/draft-ietf-aipref-attach-05.html", "step": "permit", "summary_md": "The AIPREF Content-Usage Attachment draft is an IETF AI Preferences Working Group Internet-Draft that defines how a publisher attaches machine-readable AI-use preferences to HTTP-served content [1]. It solves the 'where do the preference values live' half of the AIPREF pair: it specifies two attachment mechanisms, a Robots Exclusion Protocol extension (a new directive inside robots.txt) and an HTTP response header field named Content-Usage, and states explicitly that it updates RFC 9309 (the Robots Exclusion Protocol RFC) so the two documents are read together [1].\n\nIt does not itself define the vocabulary of preference values — which use categories exist (e.g. AI training, search, input to generative answers) and how they are expressed — that is the companion AIPREF Vocabulary draft (draft-ietf-aipref-vocab), which this document's tokens reference. It also does not define enforcement: like robots.txt, compliance depends entirely on the crawler choosing to read and honour the signal.\n\nAs of this verification (2026-09-06) the current version is draft-ietf-aipref-attach-05, dated 2026-08-19, confirming the prior finding that -05 was current as of August 2026 [1]. The document is still explicitly marked as a work in progress with boilerplate noting the 'About This Document' section is to be stripped before RFC publication, and it carries no RFC number yet. Development happens in the open on GitHub under ietf-wg-aipref/drafts with a public issue tracker and mailing list (ai-control@ietf.org) [1].\n\nImplementers are not named in the draft itself; this record does not find independent evidence of shipping crawlers or CMS/CDN products emitting the Content-Usage header or the new robots.txt directive as of this verification — adoption is unmeasured rather than zero, since a systematic scan was not run for this record. What is unresolved: how this attachment mechanism will interact with the pre-existing, unrelated Cloudflare Content Signals Policy convention, which also extends robots.txt with different signal names (search/ai-input/ai-train) and predates this draft; and whether major crawler operators (Google, OpenAI, Anthropic, Perplexity) will adopt the IETF vocabulary once it reaches RFC status rather than continuing with their own per-vendor robots.txt tokens, which are already in wide use (see ai-crawler-tokens-robots).", "track": "ietf", "version": { "date": "2026-08-19", "label": "draft-ietf-aipref-attach-05" } }, { "acronym": "AIPREF", "adoption": { "by": null, "level": "unmeasured", "probe_run": null }, "aliases": [ "draft-ietf-aipref-vocab" ], "analog": "Controlled metadata vocabulary (like Dublin Core terms)", "collisions": [], "discovery": { "mechanism": "Not independently discoverable; values are carried by the Content-Usage attachment mechanism (robots.txt directive or HTTP header)", "path": null }, "dispute": null, "evidence": [ { "claim": "draft-ietf-aipref-vocab-07, dated 2026-08-19, defines a vocabulary for expressing how automated processing systems may use digital assets, and states the document does not yet reflect working-group consensus.", "date": "2026-08-19", "label": "VERIFIED", "url": "https://datatracker.ietf.org/doc/html/draft-ietf-aipref-vocab-07" }, { "claim": "The vocabulary draft is developed in the same ietf-wg-aipref/drafts GitHub repository and mailing list as the Content-Usage attachment draft, confirming the two are companion documents.", "date": "2026-08-19", "label": "REPORTED", "url": "https://www.ietf.org/archive/id/draft-ietf-aipref-attach-05.html" } ], "form": "document-format", "governance": "IETF AI Preferences Working Group (ai-control@ietf.org mailing list)", "group": "AIPREF", "history": [ { "date": "2026-09-05", "note": "seeded from Exa Agent research run" }, { "date": "2026-09-06", "note": "verified against datatracker.ietf.org/doc/html/draft-ietf-aipref-vocab-07" } ], "id": "aipref-vocabulary", "implementation": "unknown", "last_verified": "2026-09-06", "name": "AIPREF Vocabulary", "native_status": "Internet-Draft, work in progress; explicitly states its contents 'DO NOT REFLECT CONSENSUS of the Working Group'", "origin": { "date": "2025", "org": "IETF AI Preferences (aipref) Working Group" }, "part_of": null, "parties": [ "agent-site" ], "phase": "working-group", "probe": { "method": "GET", "on_absent": "No AIPREF-vocabulary token found in the attachment surface; cannot distinguish 'no preference stated' from 'publisher uses a different vocabulary (e.g. Cloudflare Content Signals)'", "parse": "Parse any Content-Usage directive value against the AIPREF controlled vocabulary tokens defined in this draft", "path": "{origin}/robots.txt" }, "question": "What controlled set of values expresses a publisher's AI-use preferences, independent of how they are attached to content?", "scope": "general", "spec_url": "https://datatracker.ietf.org/doc/html/draft-ietf-aipref-vocab-07", "step": "permit", "summary_md": "The AIPREF Vocabulary draft is the second half of the IETF AI Preferences Working Group's pair of documents. Where the Content-Usage Attachment draft defines where preference values live (robots.txt directive or HTTP header), this draft defines what those values mean: a controlled vocabulary for declaring restrictions or permissions on how digital assets may be used by automated processing systems [1]. The two are meant to be read together and are cross-referenced explicitly in the attach draft [2].\n\nIt does not define an attachment or discovery mechanism of its own — the vocabulary is inert without the Content-Usage attach draft to carry it — and it does not cover licensing, payment, or compensation terms, which are out of scope for the working group's charter as currently drafted.\n\nAs of this verification (2026-09-06), the current version is draft-ietf-aipref-vocab-07, dated 2026-08-19, matching the same publication date as the -05 attach draft, suggesting a coordinated release [1]. The document is unusually explicit about its immaturity: its own 'Note to Readers' states that presence or absence of any particular text does not indicate working-group consensus, and it is published solely as a basis for further discussion [1]. This is a stronger caveat than the boilerplate carried by most IETF drafts.\n\nGovernance is the IETF AI Preferences Working Group, with development on GitHub (ietf-wg-aipref/drafts) and discussion on the ai-control@ietf.org list. No implementer of the AIPREF vocabulary specifically (as opposed to the broader Content-Usage attachment surface) was identified in this verification pass; adoption is unmeasured. What is unresolved: the exact set of controlled vocabulary terms was not enumerated in this pass and should be checked against the rendered draft text at the GitHub Pages mirror (ietf-wg-aipref.github.io/drafts/draft-ietf-aipref-vocab.html) in a future review; whether the vocabulary will converge with, or remain distinct from, the pre-existing Cloudflare Content Signals Policy vocabulary (search/ai-input/ai-train) is also unresolved, since the two were developed independently and target overlapping use cases.", "track": "ietf", "version": { "date": "2026-08-19", "label": "draft-ietf-aipref-vocab-07" } }, { "acronym": "TDMRep", "adoption": { "by": null, "level": "unmeasured", "probe_run": null }, "aliases": [], "analog": "Rights-reservation metadata (like a Creative Commons license badge)", "collisions": [], "discovery": { "mechanism": "well-known file, HTTP response header, or embedded metadata in HTML/EPUB/PDF", "path": "/.well-known/tdmrep.json" }, "dispute": null, "evidence": [ { "claim": "The CG-FINAL report published 2024-05-10 defines the tdm-reservation and tdm-policy declarations, the /.well-known/tdmrep.json file, HTTP header, and embedded-metadata attachment surfaces, and states plainly it is a Community Group report, not a W3C Standard.", "date": "2024-05-10", "label": "VERIFIED", "url": "https://www.w3.org/community/reports/tdmrep/CG-FINAL-tdmrep-20240510/" }, { "claim": "The TDM Reservation Protocol Community Group's own charter page confirms the group's goal (a simple, practical machine-readable TDM rights-reservation solution) and links the same CG-FINAL report as its output, independently corroborating the spec's existence and governance body from a second W3C-hosted page distinct from the report itself.", "date": null, "label": "VERIFIED", "url": "https://www.w3.org/community/tdmrep/" } ], "form": "well-known-file", "governance": "W3C Text and Data Mining Reservation Protocol Community Group", "group": null, "history": [ { "date": "2026-09-05", "note": "seeded from Exa Agent research run" }, { "date": "2026-09-06", "note": "verified against w3.org/community/reports/tdmrep/CG-FINAL-tdmrep-20240510/" } ], "id": "tdmrep", "implementation": "unknown", "last_verified": "2026-09-06", "name": "Text and Data Mining Reservation Protocol", "native_status": "W3C Community Group Final Report; explicitly \"not a W3C Standard nor is it on the W3C Standards Track\"", "origin": { "date": "2022", "org": "W3C Text and Data Mining Reservation Protocol Community Group" }, "part_of": null, "parties": [ "agent-site" ], "phase": "stable", "probe": { "method": "GET", "on_absent": "No TDM reservation file at the well-known path; check per-resource HTTP headers and embedded metadata before concluding no reservation exists, per the spec's own processing-priority rules", "parse": "Presence of a tdm-reservation or tdm-policy field in the returned JSON, or equivalently in the TDM-Reservation/TDM-Policy HTTP headers on the resource", "path": "{origin}/.well-known/tdmrep.json" }, "question": "Has a rights holder reserved text-and-data-mining rights over this content, and what policy governs any permitted mining?", "scope": "general", "spec_url": "https://www.w3.org/community/reports/tdmrep/CG-FINAL-tdmrep-20240510/", "step": "permit", "summary_md": "TDMRep (Text and Data Mining Reservation Protocol) is a W3C Community Group Final Report, published 2024-05-10, defining a protocol for rights holders to reserve text-and-data-mining rights over otherwise lawfully accessible web content, and to make any TDM licensing policy discoverable [1]. It was created as a technical response to Article 4 of the EU Copyright in the Digital Single Market Directive, which lets rights holders opt out of the TDM exception by an 'appropriate' machine-readable means [1].\n\nThe spec defines a `tdm-reservation` declaration (1 = reserved, 0 = not reserved) and an optional `tdm-policy` pointing to a JSON-LD policy document, attachable four ways: a `/.well-known/tdmrep.json` file at the origin, an HTTP `TDM-Reservation`/`TDM-Policy` response header, or embedded metadata inside HTML, EPUB 2/3, or PDF files, with a defined processing-priority order across these surfaces when more than one is present [1]. The policy document format can express permission scope (research vs. non-research mining), a duty to contact the rights holder, and a duty to compensate financially.\n\nIt does not define an enforcement or authorization mechanism — like robots.txt, a reservation is a signal a crawler may honour or ignore — and it does not define payment rails for the compensation duty it lets a policy express. It is not on the W3C Standards Track; the report itself says so explicitly, and under the W3C Community Final Specification Agreement, different (weaker) patent and process commitments apply than for a Recommendation [1].\n\nAs of this verification (2026-09-06), the CG-FINAL-tdmrep-20240510 report confirms the prior finding of a 2024-05-10 final date, and no successor draft was found during this pass — the Community Group appears to have concluded its work with this final report. Governance now sits with the W3C TDMRep Community Group (public-tdmrep@w3.org mailing list, GitHub issues preferred for discussion) rather than an active working group.\n\nWhat is unresolved: this verification did not independently confirm which publishers or crawlers implement `/.well-known/tdmrep.json` in production; adoption is unmeasured rather than known-zero, and a dedicated probe run against a domain sample would be needed to move this to 'measured'. It is also unresolved how TDMRep's EU-directive-specific framing interacts with the more general-purpose, non-EU-specific AIPREF and Content Signals conventions that address overlapping ground.", "track": "w3c", "version": { "date": "2024-05-10", "label": "CG-FINAL-tdmrep-20240510" } }, { "acronym": "", "adoption": { "by": null, "level": "unmeasured", "probe_run": null }, "aliases": [ "Cloudflare Content Signals Policy" ], "analog": "robots.txt policy extension", "collisions": [], "discovery": { "mechanism": "Machine-readable comment lines inside robots.txt", "path": "/robots.txt" }, "dispute": { "claims": [ "Cloudflare presents Content Signals as a way for publishers to express search / ai-train / ai-input preferences, and enforces its own categories at the network edge for zones it fronts (new defaults from 2026-09-15).", "Google's John Mueller stated on 2026-07-06 that no crawler or LLM he is aware of reads the robots.txt directive and that Google does not, so outside Cloudflare's own edge the directive is a declared preference with no confirmed consumer [3][4]." ], "summary": "Two different things carry the same name: an edge-enforced Cloudflare feature that works because Cloudflare blocks the request, and a robots.txt directive that only works if a crawler chooses to honour it. As of July 2026 Google says it does not, and no other major crawler has documented doing so." }, "evidence": [ { "claim": "Cloudflare's blog post, datePublished 2025-09-24 per its own page metadata, defines three content signals (search, ai-input, ai-train) as machine-readable comment lines inside robots.txt, each independently settable to yes/no, and frames restrictions as express reservations of rights under EU Directive 2019/790 Article 4.", "date": "2025-09-24", "label": "VERIFIED", "url": "https://blog.cloudflare.com/content-signals-policy/" }, { "claim": "Cloudflare's own developer documentation (distinct from the announcement blog post) reproduces the exact Content Signals Policy text and confirms it ships by default in the managed robots.txt feature, and separately states this feature was already turned on for over 3.8 million domains at launch, giving an independent, dated adoption figure from Cloudflare's own materials.", "date": "2025-09-24", "label": "VERIFIED", "url": "https://developers.cloudflare.com/bots/additional-configurations/managed-robots-txt/" }, { "claim": "Google's John Mueller (r/TechSEO, 2026-07-06): no crawler or LLM he knows of reads the content-signal robots.txt directive; it 'has no effects whatsoever for any crawler or llm' and 'just adds bloat'. Reported independently by Search Engine Roundtable and Search Engine Journal.", "date": "2026-07-06", "label": "VERIFIED", "url": "https://www.seroundtable.com/google-cloudflare-content-signals-41631.html" }, { "claim": "Search Engine Journal's account of the same statement, noting Cloudflare also emits the Content-Signal syntax as an HTTP response header in Markdown for Agents.", "date": "2026-07-06", "label": "VERIFIED", "url": "https://www.searchenginejournal.com/google-answers-question-about-llms-author-txt-for-seo/581547/" } ], "form": "well-known-file", "governance": "Cloudflare, developed with publisher/platform partners named in the announcement (e.g. Condé Nast, News/Media Alliance, Reddit, Pinterest, Quora, Yahoo)", "group": null, "history": [ { "date": "2026-09-05", "note": "seeded from Exa Agent research run" }, { "date": "2026-09-06", "note": "verified against blog.cloudflare.com/content-signals-policy/" }, { "date": "2026-09-07", "note": "added Google's 2026-07-06 statement that no crawler honours the directive (Search Engine Roundtable, Search Engine Journal)" } ], "id": "cloudflare-content-signals-policy", "implementation": "shipping", "last_verified": "2026-09-07", "name": "Content Signals Policy", "native_status": "Vendor-published policy convention layered on robots.txt; not submitted to a standards body as of this verification", "origin": { "date": "2025-09-24", "org": "Cloudflare" }, "part_of": null, "parties": [ "agent-site" ], "phase": "living", "probe": { "method": "GET", "on_absent": "Website operator has not stated a content-signal preference for that use; the spec is explicit that omission means the operator neither grants nor restricts permission for that use", "parse": "Look for 'content-signal: search=', 'content-signal: ai-input=', or 'content-signal: ai-train=' lines (as machine-readable comments) inside any robots.txt group", "path": "{origin}/robots.txt" }, "question": "May content fetched under a robots.txt allow rule also be used for search indexing, as live input to an AI answer, or for AI model training?", "scope": "general", "spec_url": "https://blog.cloudflare.com/content-signals-policy/", "step": "permit", "summary_md": "The Content Signals Policy is a Cloudflare-authored convention, announced 2025-09-24, that extends robots.txt with a machine-readable way for a website operator to state whether content a crawler is allowed to fetch may also be used for three specific downstream purposes: `search` (building a search index and returning links/excerpts, explicitly excluding AI-generated search summaries), `ai-input` (feeding content into an AI model at request time, e.g. retrieval-augmented generation or grounding), and `ai-train` (training or fine-tuning a model) [1]. It is a permit-layer refinement on top of the existing allow/disallow crawl decision: robots.txt still governs whether a page may be fetched at all, and content signals then govern what may be done with a page the crawler was already allowed to fetch.\n\nSignals are expressed as human-readable comment lines (so they degrade gracefully for crawlers that don't parse them) of the form `content-signal: search=yes, ai-train=no`. Per the spec text, `yes` permits the corresponding use, `no` prohibits it, and omitting a signal means the operator neither grants nor restricts permission for that use — a deliberately weaker default than an explicit prohibition [1]. Cloudflare frames any expressed restriction as an express reservation of rights under Article 4 of the EU Copyright Directive (2019/790), aligning its legal grounding with TDMRep's.\n\nIt does not define enforcement, and Cloudflare's own post frames it as advisory: compliance depends on crawler operators choosing to read and honour the signal, exactly like robots.txt itself. It has not, as of this verification, been submitted to IETF, W3C, or any other standards body — it remains a single-vendor convention, distinct from and overlapping with the IETF AIPREF Content-Usage/Vocabulary drafts, which use a different attachment surface (a dedicated header/directive) and a different vocabulary.\n\nAs of this verification (2026-09-06), the announcement date of 2025-09-24 is confirmed directly from the post's own structured-data metadata, matching the prior finding [1]. Cloudflare ships the mechanism directly into its own customer-facing robots.txt management tooling, giving it a shipping implementation by definition for any site on Cloudflare's platform, though no independent count of how many zones have set a non-default signal was found in this pass — adoption is unmeasured. What is unresolved: whether AI vendors (OpenAI, Anthropic, Google, Perplexity) formally commit to honouring these specific signal names in their own crawler documentation, as opposed to their existing per-bot robots.txt tokens (see ai-crawler-tokens-robots), was not confirmed in this pass.", "track": "single-vendor", "version": { "date": "2025-09-24", "label": "Announced 2025-09-24" } }, { "acronym": "WebBotAuth", "adoption": { "by": "Cloudflare (edge verification, verified-bots program) and independent client/server implementations listed in the draft's own appendix", "level": "observed", "probe_run": null }, "aliases": [ "Web Bot Auth", "HTTP Message Signatures for automated traffic" ], "analog": "Signed User-Agent / client authentication", "collisions": [], "discovery": { "mechanism": "Signature-Agent HTTP header points to a key directory; the directory is fetched from a fixed well-known path", "path": "/.well-known/http-message-signatures-directory" }, "dispute": null, "evidence": [ { "claim": "The protocol defines the Signature-Agent header (profiling RFC 9421's Signature-Input/Signature fields) for in-band key discovery, and a well-known URI serving a JWKS-based key directory. The draft's own appendix lists independent public client implementations (Chrome MV3 and Cloudflare Workers/Rust libraries by Cloudflare, a Puppeteer example, a Guzzle/PHP middleware, Python scripts) and server implementations (Cloudflare Workers, a Caddy plugin, an Apache module).", "date": "2026-06-26", "label": "VERIFIED", "url": "https://datatracker.ietf.org/doc/html/draft-meunier-webbotauth-httpsig-protocol-00" }, { "claim": "As of 2026-09-01 the document was adopted by the IETF webbotauth Working Group as draft-ietf-webbotauth-httpsig-protocol-00, superseding the individual submission", "date": "2026-09-01", "label": "VERIFIED", "url": "https://datatracker.ietf.org/doc/draft-ietf-webbotauth-httpsig-protocol/" }, { "claim": "Cloudflare verifies Web Bot Auth signatures at the edge as part of its Verified Bots program, requiring the key directory at /.well-known/http-message-signatures-directory and specific Signature-Input parameters (tag=web-bot-auth, keyid, created, expires)", "date": "2026-07-01", "label": "VERIFIED", "url": "https://developers.cloudflare.com/bots/reference/bot-verification/web-bot-auth/" } ], "form": "http-header", "governance": "IETF webbotauth Working Group (chartered; document adopted as a WG item 2026-09-01)", "group": "Web Bot Auth family", "history": [ { "date": "2026-09-05", "note": "seeded from Exa Agent research run" }, { "date": "2026-09-06", "note": "verified against draft-meunier-webbotauth-httpsig-protocol-00, its WG-adopted successor draft-ietf-webbotauth-httpsig-protocol-00 (2026-09-01), and Cloudflare's Web Bot Auth integration docs" } ], "id": "webbotauth", "implementation": "multi-implementation", "last_verified": "2026-09-06", "name": "Web Bot Auth HTTP Message Signatures", "native_status": "Active Internet-Draft, WG Document, Intended Status: Informational", "origin": { "date": "2025-04", "org": "Thibault Meunier (Cloudflare), Sandor Major (Google)" }, "part_of": null, "parties": [ "agent-site" ], "phase": "working-group", "probe": { "method": "GET", "on_absent": "No published key directory; the origin cannot verify Web Bot Auth signatures from this Signature-Agent identity", "parse": "200 response with Content-Type: application/http-message-signatures-directory+json and a JWKS body ({\"keys\":[...]}), itself signed with a Signature/Signature-Input pair tagged http-message-signatures-directory", "path": "https://{origin}/.well-known/http-message-signatures-directory" }, "question": "Which automated client made this HTTP request, and can the origin verify it cryptographically?", "scope": "general", "spec_url": "https://datatracker.ietf.org/doc/draft-ietf-webbotauth-httpsig-protocol/", "step": "identify", "summary_md": "Web Bot Auth is an IETF specification that lets an automated HTTP client (a crawler, agent, or bot) cryptographically sign its outbound requests using RFC 9421 HTTP Message Signatures, so the receiving server can verify the client's identity and intent without relying on spoofable signals like the User-Agent string or source IP [1]. A client sends a Signature-Agent header naming where its public keys can be found; the origin resolves that to a JSON Web Key Set served at a fixed well-known path and verifies the request's Signature/Signature-Input fields against it [1].\n\nIt solves bot/agent attribution at the transport layer: an origin can distinguish a signed, identity-bearing automated client from unsigned traffic, and can grant differentiated treatment (rate limits, access, billing) based on a verified identity rather than heuristics [1][3]. It does not define what a client is *authorized* to do once verified (that is left to the origin's own policy), does not cover payment, and does not itself specify how a verifier should be told which identities to trust — that is the job of the companion Signature Agent Card / registry draft.\n\nCurrent state: originally an individual submission (draft-meunier-webbotauth-httpsig-protocol, first published 2025-04, reaching -00 of the current \"httpsig-protocol\" naming on 2026-06-26). On 2026-09-01 it was formally adopted as a document of the newly chartered IETF **webbotauth** Working Group, republished as draft-ietf-webbotauth-httpsig-protocol-00 [2]. Intended status is Informational, not yet a Working Group last call or RFC.\n\nWho implements it: Cloudflare verifies Web Bot Auth signatures at the edge for its Verified Bots program and publishes an integration guide with the exact required headers and the /.well-known/http-message-signatures-directory path [3]. The draft's own appendix lists further independent implementations: a Chrome MV3 extension and Rust/TypeScript libraries from Cloudflare, a Puppeteer-based client example, a PHP Guzzle middleware, Python scripts, and server-side modules for Caddy and Apache [1]. Cloudflare previously reported signing bots from OpenAI as an early adopter (2025-05-15, per the prior seed research; not independently re-verified in this pass).\n\nDisputed or unknown: the spec's naming and draft numbering have churned repeatedly (it replaces draft-meunier-web-bot-auth-architecture and draft-meunier-webbotauth-httpsig-directory), which makes citing a stable version number difficult; always resolve to the datatracker's \"current\" redirect rather than a pinned draft-NN URL. Adoption beyond Cloudflare's own edge and the listed open-source projects has not been independently counted.", "track": "ietf", "version": { "date": "2026-09-01", "label": "draft-ietf-webbotauth-httpsig-protocol-00, adopted by the webbotauth WG, last updated 2026-09-01 (supersedes the individual draft-meunier-webbotauth-httpsig-protocol-00 of 2026-06-26)" } }, { "acronym": "", "adoption": { "by": null, "level": "unmeasured", "probe_run": null }, "aliases": [ "Signature Agent Card", "Registry and Signature Agent card for Web bot auth" ], "analog": "OAuth Dynamic Client Registration metadata / client_id document", "collisions": [], "discovery": { "mechanism": "jwks_uri client-metadata field (or a plain client_id JSON document) resolvable at a well-known path", "path": "/.well-known/http-message-signatures-directory" }, "dispute": { "claims": [ "Whether this draft will be adopted by the webbotauth WG (as its sibling httpsig-protocol draft was) or superseded is not yet resolved." ], "summary": "The seed record's name implied this was the identity card format only; the draft text shows it also functions as the IANA registry establishment document for the web_bot_auth metadata namespace, and its examples show operators listing multiple bot/platform cards (crawlers, gateways) at a shared discovery path, not just one card per origin." }, "evidence": [ { "claim": "The draft defines the Signature Agent Card as a JSON metadata document reusing OAuth Dynamic Client Registration Metadata fields extended with a single web_bot_auth object, and registers that object with IANA", "date": "2026-06-26", "label": "VERIFIED", "url": "https://www.ietf.org/archive/id/draft-meunier-webbotauth-registry-03.html" }, { "claim": "As of this check the document remains an individual submission (not yet a webbotauth WG document), unlike the sibling httpsig-protocol draft which was WG-adopted on 2026-09-01", "date": "2026-09-06", "label": "VERIFIED", "url": "https://datatracker.ietf.org/doc/draft-meunier-webbotauth-registry/" } ], "form": "document-format", "governance": "IETF individual draft, discussed on the web-bot-auth@ietf.org list; not yet adopted by the webbotauth WG (unlike the sibling httpsig-protocol draft)", "group": "Web Bot Auth family", "history": [ { "date": "2026-09-05", "note": "seeded from Exa Agent research run" }, { "date": "2026-09-06", "note": "verified against draft-meunier-webbotauth-registry-03 primary text and its current datatracker status page" } ], "id": "web-bot-auth-signature-agent-card", "implementation": "prototype", "last_verified": "2026-09-06", "name": "Signature Agent Card (Web Bot Auth registry)", "native_status": "Active Internet-Draft (individual), Intended Status: Informational", "origin": { "date": "2025-09", "org": "Maxime Guerreiro (Cloudflare), Ulas Kirazci (Amazon), Thibault Meunier (Cloudflare)" }, "part_of": null, "parties": [ "agent-site" ], "phase": "draft", "probe": { "method": "GET", "on_absent": "No Signature Agent Card is published; a verifier can still validate the raw signature via the plain key directory but has no machine-readable identity, purpose or rate-limit metadata for the signer", "parse": "JSON object with OAuth Dynamic Client Registration fields (client_id, client_name, client_uri, jwks_uri or jwks, contacts) plus a web_bot_auth extension object (e.g. expected-user-agent, rfc9309-product, trigger, purpose)", "path": "https://{origin}/.well-known/http-message-signatures-directory" }, "question": "What identity, purpose, rate expectations and cryptographic keys belong to a signed bot?", "scope": "general", "spec_url": "https://datatracker.ietf.org/doc/draft-meunier-webbotauth-registry/", "step": "identify", "summary_md": "This draft defines the \"Signature Agent Card\": a JSON metadata document that a Web Bot Auth signer (a crawler, agent, or bot operator) publishes to describe itself — its identity, purpose, expected request rate, and cryptographic keys [1]. Rather than inventing a new schema, it reuses the OAuth Dynamic Client Registration Metadata field set (client_id, client_name, client_uri, logo_uri, contacts, jwks_uri/jwks) and extends it with a single `web_bot_auth` object (fields observed in the spec include expected-user-agent, an RFC 9309 robots.txt product token, a trigger type such as \"fetcher\", and a purpose such as \"tdm\" for text-and-data-mining) [1]. The same document also formally establishes an IANA registry for that `web_bot_auth` object's members, so third parties can register new fields.\n\nIt solves the metadata gap left by the base Web Bot Auth signature protocol: RFC 9421 signatures and the Signature-Agent header prove *that* a request was signed by a given key, but not *who* holds that key, *why* they are crawling, or *how fast* they intend to request — this card supplies that context in a machine-readable form at the same well-known path used for the key directory [1]. It does not itself carry the cryptographic proof (that is RFC 9421 plus the base Web Bot Auth protocol) and does not define enforcement — a site is free to ignore the declared purpose or rate.\n\nCurrent state: an individual Internet-Draft, draft-meunier-webbotauth-registry-03, published 2026-06-26, authored by engineers at Cloudflare and Amazon [1]. As of this check (2026-09-06) it has not been adopted by the newly chartered IETF webbotauth Working Group, unlike its sibling protocol draft, which was adopted as a WG document on 2026-09-01 [2]. Its examples show the same well-known path (/.well-known/http-message-signatures-directory) can list multiple signer cards — individual bots as well as \"platform\" gateways that sign on behalf of several downstream operators.\n\nImplementers: as an Informational registry-and-schema draft rather than a running protocol, no dedicated client/server implementations beyond the base Web Bot Auth signing/verifying stack (Cloudflare's libraries, see the sibling httpsig-protocol record) were found in this pass; none is claimed in the draft itself.\n\nDisputed or unknown: whether this draft will be folded into the WG's adopted protocol document or remain a separate track, and how much of the `web_bot_auth` extension object will change before any WG adoption, are both open.", "track": "ietf", "version": { "date": "2026-06-26", "label": "draft-meunier-webbotauth-registry-03, 2026-06-26" } }, { "acronym": "", "adoption": { "by": "Multiple libraries and at least one profile in production use (Web Bot Auth / Cloudflare); RFC 9421 is a general-purpose base standard, not agent-specific", "level": "observed", "probe_run": null }, "aliases": [], "analog": "JWS for HTTP components", "collisions": [], "discovery": { "mechanism": "Signature and Signature-Input HTTP fields carried directly on the message; no fixed discovery path of its own", "path": "none" }, "dispute": null, "evidence": [ { "claim": "RFC 9421 is a Proposed Standard published by the IETF (2024) defining a mechanism for creating, encoding and verifying signatures over HTTP message components, including a means to request that a signature be applied to a subsequent message", "date": "2024-02", "label": "VERIFIED", "url": "https://www.rfc-editor.org/info/rfc9421" }, { "claim": "Web Bot Auth's protocol draft explicitly builds its Agent/Origin signature exchange on top of RFC 9421's Signature and Signature-Input fields, adding the Signature-Agent field as an RFC 9421 signature component", "date": "2026-06-26", "label": "VERIFIED", "url": "https://datatracker.ietf.org/doc/html/draft-meunier-webbotauth-httpsig-protocol-00" } ], "form": "http-header", "governance": "IETF", "group": "Web Bot Auth family", "history": [ { "date": "2026-09-05", "note": "seeded from Exa Agent research run" }, { "date": "2026-09-06", "note": "verified against RFC 9421 primary source and confirmed as the base standard profiled by Web Bot Auth" } ], "id": "http-message-signatures", "implementation": "multi-implementation", "last_verified": "2026-09-06", "name": "HTTP Message Signatures", "native_status": "Proposed Standard", "origin": { "date": "2024-02", "org": "A. Backman, J. Richer, M. Sporny (IETF httpbis Working Group)" }, "part_of": null, "parties": [ "agent-site" ], "phase": "stable", "probe": { "method": "GET", "on_absent": "The message carries no RFC 9421 signature; any profile built on it (e.g. Web Bot Auth) cannot be verified", "parse": "Presence of Signature and Signature-Input HTTP fields (or their Content-Digest/Signature-related trailers) conforming to RFC 9421's structured-field syntax", "path": "n/a — inspect response/request headers on any HTTP exchange" }, "question": "How can HTTP messages carry end-to-end component integrity and proof of possession, independent of transport-layer security?", "scope": "general", "spec_url": "https://www.rfc-editor.org/info/rfc9421", "step": "identify", "summary_md": "RFC 9421 (HTTP Message Signatures) is a general-purpose IETF Proposed Standard, not specific to agents. It defines how to create, encode and verify digital signatures or message authentication codes over selected components of an HTTP message (headers, derived components like @authority or @method, and optionally the body), so that a signature survives intermediaries that might otherwise alter or drop parts of the message [1]. It also defines how to request that a future message in an ongoing exchange be signed [1].\n\nIt solves message-level integrity and proof-of-possession for HTTP independent of transport security (TLS terminates at intermediaries; RFC 9421 signatures do not) [1]. It does not define identity discovery, key distribution, or any notion of \"bot\" or \"agent\" — those are added by profiles built on top of it. In this map, it is the base standard that Web Bot Auth (see the `webbotauth` record) profiles: Web Bot Auth adds the Signature-Agent header as a signed component and defines a specific key-discovery mechanism (a well-known JWKS directory), while RFC 9421 itself stays agnostic to what a signature proves or where keys come from [2].\n\nCurrent state: published as a Proposed Standard in February 2024 and stable since; it is not itself under active revision as far as this check found.\n\nWho implements it: general HTTP signing libraries exist across languages (this check did not re-survey the full ecosystem); its most visible agent-relevant use is as the substrate for Web Bot Auth, which Cloudflare verifies at the edge [2].\n\nDisputed or unknown: none specific to the base standard found in this pass. Because RFC 9421 is general and widely referenced, this record exists mainly to anchor the agent-specific profiles (Web Bot Auth, and potentially others) that depend on it; it should not be read as agent-specific adoption evidence on its own.", "track": "ietf", "version": { "date": "2024-02", "label": "RFC 9421, February 2024, Proposed Standard" } }, { "acronym": "ARD", "adoption": { "by": "agenticresources.dev own probe, 2026-09-04", "level": "observed", "probe_run": null }, "aliases": [ "AI Catalog", "ai-catalog.json (predecessor path)" ], "analog": "sitemap plus a search engine index", "collisions": [ "ARDP (Agent Registration and Discovery Protocol, unrelated IETF draft)", "AIR (the urn:air: identifier namespace this spec defines is sometimes referred to standalone)" ], "discovery": { "mechanism": "well-known manifest, robots.txt Agentmap directive, HTML , DNS SVCB, in-page JSON-LD", "path": "/.well-known/ard.json" }, "dispute": { "claims": [ "v0.91 text: /.well-known/ard.json is canonical; /.well-known/ai-catalog.json is an optional predecessor", "2026-09-04 probe: 100% of observed manifests are still at ai-catalog.json; only 19% also serve ard.json", "Identifier form is urn:air:::, not urn:ard as some earlier notes assumed" ], "summary": "The path this specification calls canonical has changed between revisions and prior internal notes got this backwards: v0.91 (26 Aug 2026) makes /.well-known/ard.json canonical and demotes /.well-known/ai-catalog.json to an optional, non-required-to-consult predecessor path. Our own probe (2026-09-04, prior to this verification) found the entire observed deployment base still on the old ai-catalog.json path, with only 6 of 31 also serving the new path -- so real-world adoption lags the spec text by at least one full path rename. Adoption level is left as \"observed\" rather than \"measured\" here because no probe-run artifact exists inside this repository (data/) to cite by filename; the probe that produced the 31/50 figure lives in the sibling agenticresources.dev project." }, "evidence": [ { "claim": "ARD v0.91 (26 Aug 2026), authored by Google/Microsoft/Hugging Face individuals, defines the ARD entry as a JSON-LD node and moves the canonical manifest path to /.well-known/ard.json, explicitly naming /.well-known/ai-catalog.json as the deprecated predecessor path that consumers MAY but need not consult.", "date": "2026-08-26", "label": "VERIFIED", "url": "https://raw.githubusercontent.com/ards-project/ard-spec/main/spec/ard.md" }, { "claim": "Google announced the Agentic Resource Discovery Specification and directed publishers to a well-known catalog mechanism.", "date": "2026-06-17", "label": "REPORTED", "url": "https://developers.googleblog.com/en/announcing-the-agentic-resource-discovery-specification/" }, { "claim": "AGNTCY's Agent Directory Service (ADS) implements AI Catalog interoperability, serving /.well-known/ai-catalog.json and exporting records to a2a/mcp/oasf formats -- one real implementation of the ARD manifest side.", "date": "2026-07-06", "label": "VERIFIED", "url": "https://datatracker.ietf.org/doc/html/draft-mp-agntcy-ads-02" }, { "claim": "A probe of 50 domains run by this site's publisher (agenticresources) on 2026-09-04 found 31 serving a manifest, all 31 on the predecessor ai-catalog.json path, and only 6 of those also on the new ard.json path -- i.e. the ecosystem has not yet moved to the canonical path this v0.91 revision defines.", "date": "2026-09-04", "label": "REPORTED", "url": "https://agenticresources.dev/" } ], "form": "well-known-file", "governance": "Authored by individuals at Google, Microsoft and Hugging Face (Junjie Bu, R.V. Guha, Shaun Smith); published as an open GitHub project (ards-project/ard-spec) with no formal standards body yet; contributions acknowledged from AWS, Cisco, Databricks, GitHub, GoDaddy, Nvidia, Salesforce and Snowflake", "group": null, "history": [ { "date": "2026-09-05", "note": "seeded from Exa Agent research run" }, { "date": "2026-09-06", "note": "verified against ARD v0.91 spec text (raw.githubusercontent.com/ards-project/ard-spec/main/spec/ard.md); corrected canonical path from ai-catalog.json to ard.json; folded ai-catalog-well-known-file into this record" } ], "id": "ard", "implementation": "shipping", "last_verified": "2026-09-06", "name": "Agentic Resource Discovery", "native_status": "Proposal", "origin": { "date": "2026-06-17", "org": "Google, Microsoft, Hugging Face" }, "part_of": null, "parties": [ "agent-site", "agent-registry" ], "phase": "draft", "probe": { "method": "GET", "on_absent": "Domain publishes no ARD manifest at the current canonical path; it may still publish at the deprecated predecessor path /.well-known/ai-catalog.json, which conformant consumers are not required to consult", "parse": "200 response is JSON with a top-level \"entries\" array of ARD entries (each with identifier/displayName/type/url-or-data); a consumer MAY also check the predecessor /.well-known/ai-catalog.json and an HTML tag", "path": "https://{origin}/.well-known/ard.json" }, "question": "Where are an organization's discoverable agentic resources (MCP servers, A2A agents, skills, registries), and how can they be found by search rather than pre-installed one at a time?", "scope": "general", "spec_url": "https://raw.githubusercontent.com/ards-project/ard-spec/main/spec/ard.md", "step": "discover", "summary_md": "Agentic Resource Discovery (ARD) is a specification for how agentic resources -- MCP servers, A2A agents, skills, and other callable services -- are described, discovered, and searched across a federated network of registries [1]. It is authored by individuals at Google, Microsoft and Hugging Face and published as an open GitHub project (ards-project/ard-spec) rather than through a formal standards body; the current text is version v0.91, dated 26 August 2026, and is explicitly labelled a \"Proposal\" [1].\n\nARD solves the problem of scaling tool selection beyond an LLM's context window: instead of injecting every possible tool description into a prompt, a client searches a registry's index using natural language plus structured filters, and the registry returns ranked entries [1]. Each entry is a JSON-LD node with a small set of required terms (identifier, displayName, type, and either url or data), and publishers can extend it with arbitrary namespaced terms without waiting for a spec revision [1]. Entries are advertised through a well-known manifest, robots.txt Agentmap directives, an HTML `` tag, DNS SVCB records, or in-page markup; the manifest path is `/.well-known/ard.json` [1].\n\nA significant correction to earlier internal notes: the v0.91 text makes `/.well-known/ard.json` the canonical path and explicitly demotes the older `/.well-known/ai-catalog.json` path (and the `ai-catalog` link relation) to an optional predecessor that a conformant consumer is not required to consult [1]. Prior assumptions that ai-catalog.json was still canonical as of this version are wrong as of the text fetched 2026-09-06.\n\nARD does not define a signing or authentication scheme of its own (it defers to whatever trust framework a publisher's `trustManifest` declares), does not constrain artifact-specific schemas (MCP, A2A, etc. remain external), and does not define a normative way to fetch a full entry by identifier from a search result [1].\n\nImplementation exists: AGNTCY's Agent Directory Service explicitly serves `/.well-known/ai-catalog.json` and can export records into a2a, mcp, oasf and agent-skill formats, functioning as one real ARD-manifest-compatible implementation [3]. Beyond that, adoption is thin and lagging the spec's own migration: a probe of 50 domains run by this site's publisher (agenticresources) on 2026-09-04 found 31 serving some manifest, all 31 still on the deprecated ai-catalog.json path, and only 6 of those also serving the new ard.json path [4] -- meaning the observed deployment base predates this very revision's path rename. Because that probe artifact is not present in this repository, adoption here is recorded as \"observed\" rather than \"measured\".\n\nWhat is disputed or unknown: whether the ecosystem migrates to ard.json before a competing discovery mechanism (DNS-AID, AID, ADP) becomes the practical default; whether any registry beyond ADS has implemented the POST /search and POST /explore REST surface this spec mandates; and how the optional `trustManifest` verification step will be operationalized across publishers who have never coordinated on a trust framework.\n\nThe record `ai-catalog-well-known-file`, which previously modelled the manifest file as a separate entity, has been folded into this record: it described the same well-known artifact that this specification now supersedes with `ard.json`, and keeping it separate obscured that the two are one lineage, not two competing formats.", "track": "vendor-consortium", "version": { "date": "2026-08-26", "label": "v0.91" } }, { "acronym": "", "adoption": { "by": null, "level": "unmeasured", "probe_run": null }, "aliases": [ "ai-catalog.json" ], "analog": "sitemap.xml", "collisions": [], "discovery": { "mechanism": "superseded -- see ard", "path": "/.well-known/ai-catalog.json" }, "dispute": null, "evidence": [ { "claim": "ARD v0.91 names /.well-known/ai-catalog.json as its own predecessor path, not a separate specification: \"ARD's predecessor specified the path /.well-known/ai-catalog.json and the link relation ai-catalog; a consumer MAY additionally consult these.\"", "date": "2026-08-26", "label": "VERIFIED", "url": "https://raw.githubusercontent.com/ards-project/ard-spec/main/spec/ard.md" }, { "claim": "Google's own launch post for ARD instructs publishers to host an ai-catalog.json file at a well-known path on their domain as step 1 of the four-phase discovery flow, confirming this well-known file is ARD's original (now-predecessor) publishing mechanism rather than a separate specification.", "date": "2026-06-17", "label": "VERIFIED", "url": "https://developers.googleblog.com/en/announcing-the-agentic-resource-discovery-specification/" } ], "form": "well-known-file", "governance": "ARD / ards-project (see ard)", "group": null, "history": [ { "date": "2026-09-05", "note": "seeded from Exa Agent research run" }, { "date": "2026-09-06", "note": "merged into ard: confirmed via ARD v0.91 spec text that ai-catalog.json is ARD's own deprecated predecessor path, not a separate specification" }, { "date": "2026-09-06", "note": "fix round 1: added second evidence entry (Google ARD launch blog post, fetched directly) to satisfy the two-evidence gate" } ], "id": "ai-catalog-well-known-file", "implementation": "deprecated", "last_verified": "2026-09-06", "name": "AI Catalog well-known file", "native_status": "Deprecated predecessor path of the ARD manifest", "origin": { "date": "2026-06-17", "org": "ARD ecosystem (Google, Microsoft, Hugging Face)" }, "part_of": "ard", "parties": [ "agent-site" ], "phase": "withdrawn", "probe": { "method": "GET", "on_absent": "superseded; see ard", "parse": "superseded; see the ard record's probe for the current canonical path", "path": "https://{origin}/.well-known/ai-catalog.json" }, "question": "Which AI-capable artifacts and registries does this domain publish? (superseded question -- see ard)", "scope": "general", "spec_url": "https://raw.githubusercontent.com/ards-project/ard-spec/main/spec/ard.md", "step": "discover", "summary_md": "This record modelled the `/.well-known/ai-catalog.json` well-known file as if it were a distinct, separately maintained artifact alongside the `ard` record. Reading the ARD v0.91 specification text directly [1] shows this is incorrect: ai-catalog.json is the *same lineage* as ARD -- it is explicitly named in the current spec as \"ARD's predecessor\" path, kept only as an optional legacy fallback that a conformant ARD consumer is not required to read. There is no independent governance, schema, or spec document for ai-catalog.json distinct from the ARD project; it is a prior version of the same well-known manifest concept, now superseded by /.well-known/ard.json.\n\nKeeping this as a separate map entry created a false impression of two competing discovery mechanisms. All content that was useful here (its role as the file most publishers currently serve, per our probe evidence) has been moved into the `ard` record's summary and dispute fields, where the version history and the adoption lag it represents can be read together. This record is marked `withdrawn` rather than deleted so the id remains resolvable and the merge history is auditable; readers of agenticweb.wiki should be pointed to `ard` instead.", "track": "vendor-consortium", "version": { "date": null, "label": "n/a -- not a separately versioned artifact" } }, { "acronym": "DNS-AID", "adoption": { "by": "Infoblox and GoDaddy joint press release", "level": "claimed", "probe_run": null }, "aliases": [], "analog": "DNS-based Service Discovery (DNS-SD) for agents", "collisions": [ "AID (Agent Identity and Discovery, a separate, unrelated agentcommunity.org spec that also does DNS-first discovery)" ], "discovery": { "mechanism": "DNS SVCB records at the agent's owner name; DNS-SD-style well-known labels _agents/_index for an organization index; optional TXT fallback and DNSSEC/DANE TLSA for trust", "path": "_index._agents. (SVCB); _agent-name. (SVCB)" }, "dispute": { "claims": [ "DNS-AID: SVCB-based, IETF dnsop, multi-vendor (Infoblox/Deutsche Telekom/Amazon/GoDaddy)", "AID: TXT-based, agentcommunity.org, unrelated authorship" ], "summary": "Two IETF drafts now build on top of DNS-AID's SVCB mechanism (ADP explicitly, ARD's informative discussion) while a third, unrelated spec (AID, agentcommunity.org) independently chose the DNS TXT record at _agent. for the same job. The two are not compatible: DNS-AID uses SVCB records with a _agents/_index label structure; AID (agentcommunity) uses a flat TXT record. No evidence found that these projects coordinate." }, "evidence": [ { "claim": "draft-mozleywilliams-dnsop-dnsaid-02 (27 May 2026, IETF dnsop, authors from Infoblox, Deutsche Telekom, Amazon) defines SVCB records at an agent's owner name plus a well-known DNS-SD-style _index._agents. organization index, with optional TXT fallback and DANE TLSA for endpoint authentication.", "date": "2026-05-27", "label": "VERIFIED", "url": "https://datatracker.ietf.org/doc/html/draft-mozleywilliams-dnsop-dnsaid/" }, { "claim": "Infoblox and GoDaddy jointly announced support for open standards for AI agent discovery, identity and verification, naming this DNS-based approach.", "date": "2026-05-14", "label": "REPORTED", "url": "https://aboutus.godaddy.net/newsroom/news-releases/press-release-details/2026/Infoblox-and-GoDaddy-Support-Open-Standards-for-AI-Agent-Discovery-Identity-and-Verification-2026-0acKMntvOC/default.aspx" }, { "claim": "ARD v0.91 itself names DNS-AID as a candidate mechanism for federated routing (\"leveraging DNS-AID to discover authoritative registries for specific domains\"), and ADP (draft-pro-adp) explicitly delegates its DNS layer to DNS-AID.", "date": "2026-08-26", "label": "VERIFIED", "url": "https://raw.githubusercontent.com/ards-project/ard-spec/main/spec/ard.md" } ], "form": "dns-record", "governance": "IETF dnsop working group Internet-Draft (individual submission track, not yet WG-adopted)", "group": null, "history": [ { "date": "2026-09-05", "note": "seeded from Exa Agent research run" }, { "date": "2026-09-06", "note": "verified against draft-mozleywilliams-dnsop-dnsaid-02 spec text via datatracker.ietf.org" } ], "id": "dns-aid", "implementation": "unknown", "last_verified": "2026-09-06", "name": "DNS for AI Discovery", "native_status": "Internet-Draft, Standards Track intended status", "origin": { "date": "2026-05-27", "org": "Infoblox, with Deutsche Telekom and Amazon co-authors" }, "part_of": null, "parties": [ "agent-site", "agent-agent" ], "phase": "draft", "probe": { "method": "DNS", "on_absent": "Domain publishes no DNS-AID SVCB records; DNS-AID cannot be used to bootstrap discovery for this domain", "parse": "SVCB RRset present with alpn/well-known/cap SvcParamKeys; absence of TargetName error and presence of at least one SvcParamKey confirms an agent record", "path": "SVCB query for _index._agents.{domain}, then SVCB query for the target agent owner name it returns" }, "question": "Given a domain, where is its agent endpoint, what protocol does it speak, and how can that be verified via DNSSEC/DANE?", "scope": "general", "spec_url": "https://datatracker.ietf.org/doc/html/draft-mozleywilliams-dnsop-dnsaid/", "step": "discover", "summary_md": "DNS for AI Discovery (DNS-AID) standardizes publishing AI agents in the Domain Name System so other agents can discover them, using DNS Service Binding (SVCB) records for connectivity and key metadata, a well-known DNS-SD-style entry point (`_index._agents.`) into an organization's agent index, and optionally DNSSEC and DANE TLSA records for trust [1]. It is an IETF Internet-Draft in the dnsop working group's area (individual submission, not yet WG-adopted), authored by engineers at Infoblox, Deutsche Telekom and Amazon, current revision -02 dated 27 May 2026 with intended status Standards Track [1].\n\nIt solves the \"given a domain, where is the agent and which protocol does it speak\" problem entirely within DNS, so that once a client has resolved an organization's agents once, subsequent lookups are cacheable and require no extra round trip beyond ordinary DNS resolution [1]. The mechanism defines two record shapes: an SVCB record at an individual agent's owner name carrying `TargetName`, `alpn`, `well-known` (a well-known URI path per RFC 8615) and other SvcParamKeys, and an SVCB record at the fixed label `_index._agents.` pointing to an organization-wide index [1]. A TXT-record fallback and a DNSSEC/DANE-authenticated TLSA companion record are both discussed but explicitly not the primary mechanism [1]. The document introduces no new DNS resource record types, opcodes, or response codes -- it is a usage convention over existing SVCB/TXT/TLSA record types [1].\n\nDNS-AID does not itself define authentication or authorization beyond DANE-based TLS endpoint verification, does not define the schema of the capability descriptor referenced by `well-known` (that is out of scope), and use case 3 (discovery by capability alone, with neither organization nor agent known) is explicitly out of scope for this document, though the authors note it \"can be derived\" from the spec [1].\n\nCurrent state: as of 27 May 2026 this is a dnsop-area individual Internet-Draft, expiring 28 November 2026 unless refreshed [1]. Infoblox and GoDaddy issued a joint press release on 14 May 2026 announcing support for \"open standards for AI agent discovery, identity and verification\" that names this effort [2], but that is a vendor-support announcement, not evidence of production deployments; no independent implementation count was found. Two other agentic-web specifications explicitly build on it: ADP (draft-pro-adp) delegates its entire DNS discovery layer to DNS-AID rather than duplicating it [3], and ARD's informative discussion of federated query resolution names DNS-AID as a way to \"discover authoritative registries for specific domains\" [3].\n\nWhat is disputed or unknown: whether DNS-AID's SVCB-based approach and the separately-authored AID specification's flat TXT-record approach (see `aid`) will converge, coexist, or one will win out -- no evidence of coordination between the two projects was found. Adoption is recorded as \"claimed\" (by the Infoblox/GoDaddy announcement) rather than measured, since no independent DNS probe of a domain sample was run for this record.", "track": "ietf", "version": { "date": "2026-05-27", "label": "draft-mozleywilliams-dnsop-dnsaid-02" } }, { "acronym": "ANS", "adoption": { "by": null, "level": "unmeasured", "probe_run": null }, "aliases": [ "Agent Name Service" ], "analog": "DNS/DNSSEC name plus certificate transparency log", "collisions": [], "discovery": { "mechanism": "A Registration Authority verifies domain ownership via ACME and issues a dual certificate (public-CA Server Certificate + private-CA Identity Certificate binding a version-specific ANSName); lifecycle events are sealed into an append-only SCITT-aligned Transparency Log", "path": "none" }, "dispute": { "claims": [ "Whether GoDaddy's announced support targets this exact draft (v2, replacing draft-narajala-ans) or the agentic-identity space in general is not established by the press release alone." ], "summary": "This is an Independent Submission with no IETF working-group sponsorship and no implementation found in this pass; the GoDaddy/Infoblox press release announces support for standards in this space generally and should not be read as confirmation that ANS v2 specifically has been deployed." }, "evidence": [ { "claim": "ANS v2 anchors every agent identity to a DNS domain name, issues dual PKI certificates via an ACME-verified Registration Authority, seals lifecycle events into a SCITT-aligned Transparency Log, and defines three assurance tiers (Bronze: PKI; Silver: PKI+DANE; Gold: PKI+DANE+Transparency Log)", "date": "2026-04-15", "label": "VERIFIED", "url": "https://datatracker.ietf.org/doc/draft-narajala-courtney-ansv2/" }, { "claim": "GoDaddy and Infoblox announced joint support for open standards for AI-agent discovery, identity and verification", "date": "2026-05-14", "label": "REPORTED", "url": "https://aboutus.godaddy.net/newsroom/news-releases/press-release-details/2026/Infoblox-and-GoDaddy-Support-Open-Standards-for-AI-Agent-Discovery-Identity-and-Verification-2026-0acKMntvOC/default.aspx" } ], "form": "dns-record", "governance": "IETF Independent Submission (individual draft; not sponsored by a chartered WG); replaces the authors' earlier draft-narajala-ans", "group": null, "history": [ { "date": "2026-09-05", "note": "seeded from Exa Agent research run" }, { "date": "2026-09-06", "note": "verified against draft-narajala-courtney-ansv2-01 primary text and the GoDaddy/Infoblox press release" } ], "id": "ans", "implementation": "none-found", "last_verified": "2026-09-06", "name": "Agent Name Service v2 (ANS)", "native_status": "Active Internet-Draft, Intended Status: Informational", "origin": { "date": "2025-05", "org": "Scott Courtney (GoDaddy), Vineeth Sai Narajala (OWASP), Ken Huang, Idan Habler, Akram Sheriff (Cisco) — Independent Submission" }, "part_of": null, "parties": [ "agent-agent", "agent-registry" ], "phase": "draft", "probe": { "method": "GET", "on_absent": "No ANS identity is bound to the domain; the agent cannot be verified at any of ANS's three assurance tiers (Bronze/Silver/Gold)", "parse": "Resolve the ANSName's Identity Certificate chain and check the Transparency Log for a matching sealed registration event", "path": "n/a — no fixed well-known path or DNS record type is defined in the draft text reviewed" }, "question": "What domain-anchored identity belongs to an autonomous agent, and at what assurance tier can that identity be trusted?", "scope": "general", "spec_url": "https://datatracker.ietf.org/doc/draft-narajala-courtney-ansv2/", "step": "identify", "summary_md": "Agent Name Service v2 (ANS) is a proposed identity architecture that anchors every autonomous agent's identity to a DNS domain name it controls, rather than to a platform-specific account or an unverified self-asserted name [1]. A Registration Authority (RA) verifies domain ownership via the ACME protocol (the same mechanism Let's Encrypt uses for TLS certificates) and then issues two certificates: a Server Certificate from a public Certificate Authority, and an Identity Certificate from a private CA binding a version-specific \"ANSName\" to that domain [1]. Every lifecycle event (issuance, rotation, revocation) is sealed into an append-only Transparency Log aligned with the IETF's SCITT (Supply Chain Integrity, Transparency, and Trust) work, and clients can pick from three assurance tiers — Bronze (PKI only), Silver (PKI plus DANE), or Gold (PKI plus DANE plus the Transparency Log) — matched to how much a given transaction has at risk [1].\n\nIt solves domain-anchored, auditable agent identity where the party relying on the identity did not provision it. Its design explicitly decouples identity issuance (owned by the RA) from discovery (left to independent, competing Discovery Services that index the sealed events), and separates a three-layer trust model: Layer 1 foundational identity (this protocol), Layer 2 operational-maturity attestation by third-party assessors, and Layer 3 real-time behavioral reputation scoring — only Layer 1 is specified here [1]. It does not itself define reputation scoring, message formats for agent-to-agent communication, or any fixed DNS record type or well-known HTTP path we could locate in the text reviewed; those remain open or left to Discovery Services.\n\nCurrent state: an Independent Submission Internet-Draft — not sponsored by any IETF working group — first published as draft-narajala-ans in May 2025 and renamed/rewritten as draft-narajala-courtney-ansv2, currently at revision -01 (last updated 2026-04-15) [1]. Authors span GoDaddy, OWASP, and Cisco.\n\nWho implements it: no running implementation, reference code, or deployed Registration Authority was found in this pass. GoDaddy and Infoblox issued a joint press release in May 2026 announcing support for open standards for AI-agent discovery, identity and verification, but this is a statement of intent about the space rather than confirmed evidence that ANS v2 specifically is deployed [2].\n\nDisputed or unknown: whether GoDaddy's announced support is for this exact spec version; whether any Registration Authority or Discovery Service exists yet; and how the fixed discovery mechanics (DNS record type, well-known path) will be finalized are all open.", "track": "community", "version": { "date": "2026-04-15", "label": "draft-narajala-courtney-ansv2-01, last updated 2026-04-15 (replaces draft-narajala-ans, first published 2025-05)" } }, { "acronym": "AID", "adoption": { "by": null, "level": "observed", "probe_run": null }, "aliases": [], "analog": "a DNS SRV/TXT record for agents, with a TLS-certificate-like endpoint proof bolted on", "collisions": [ "DNS-AID (unrelated IETF dnsop draft that solves the same problem with SVCB instead of TXT)", "AID also collides with generic 'agent ID' usage elsewhere" ], "discovery": { "mechanism": "DNS TXT record at a fixed base name, with an HTTPS well-known fallback", "path": "_agent. (DNS TXT); /.well-known/agent (HTTP fallback)" }, "dispute": { "claims": [ "AID: _agent. TXT record, agentcommunity.org, community-governed", "DNS-AID: SVCB records at agent + _index._agents labels, IETF dnsop draft, Infoblox/Deutsche Telekom/Amazon" ], "summary": "AID (agentcommunity.org) and DNS-AID (IETF dnsop draft-mozleywilliams) both answer 'given a domain, where is the agent and which protocol' but chose incompatible DNS shapes -- a single TXT record with key=value pairs, versus an SVCB RRset with SvcParamKeys and a separate _index._agents label. No evidence either project references or coordinates with the other in the text fetched for this record." }, "evidence": [ { "claim": "AID v2.1.0 (1 June 2026, agentcommunity.org) defines a DNS TXT record at the canonical base name _agent. with required keys v/u/p (version/uri/proto), an optional Ed25519 endpoint-proof key (pka/k), and a JSON .well-known/agent HTTP fallback for environments where DNS TXT record creation is restricted.", "date": "2026-06-01", "label": "VERIFIED", "url": "https://raw.githubusercontent.com/agentcommunity/agent-identity-discovery/main/packages/docs/specification.md" }, { "claim": "The agentcommunity/agent-identity-discovery GitHub repository (47 stars, 8 forks, 5 contributors, fetched 2026-09-06) shows AID v2 shipped as published packages -- npm @agentcommunity/aid, PyPI aid-discovery, plus source-available Go/Rust/.NET/Java libraries -- an official aid-doctor CLI, a live interactive workbench at aid.agentcommunity.org, and a documented live showcase domain (supabase.agentcommunity.org) used in the README's own Go example, i.e. a real, multi-language, actively maintained implementation exists beyond the specification text alone.", "date": "2026-09-06", "label": "VERIFIED", "url": "https://github.com/agentcommunity/agent-identity-discovery" } ], "form": "dns-record", "governance": "Agent Community open-source project; editor listed as 'Agent Community'; no formal standards body, though the spec discusses composing with IETF-track work (RFC 9421, RFC 7638, RFC 9728, RFC 8414)", "group": null, "history": [ { "date": "2026-09-05", "note": "seeded from Exa Agent research run" }, { "date": "2026-09-06", "note": "verified against AID v2.1.0 spec text via raw.githubusercontent.com" }, { "date": "2026-09-06", "note": "fix round 1: added second evidence entry (agentcommunity GitHub repo, fetched directly) showing real published multi-language packages; upgraded implementation unknown -> shipping and adoption unmeasured -> observed on that basis" } ], "id": "aid", "implementation": "shipping", "last_verified": "2026-09-06", "name": "Agent Identity and Discovery", "native_status": "Current normative specification", "origin": { "date": "2026-06-01", "org": "Agent Community (agentcommunity.org)" }, "part_of": null, "parties": [ "agent-site", "agent-agent" ], "phase": "living", "probe": { "method": "GET", "on_absent": "No well-known fallback; query DNS TXT at _agent.{domain} directly (not curl-executable) -- absence of both means the domain does not publish AID", "parse": "200 response is JSON mirroring the v2 TXT record keys (version, uri, proto, auth, ...); trustSource is reported as well-known-tls rather than dns for this path", "path": "https://{origin}/.well-known/agent" }, "question": "Given a domain, where is the agent and which protocol should I speak, with cryptographic proof the endpoint controls the matching key?", "scope": "general", "spec_url": "https://raw.githubusercontent.com/agentcommunity/agent-identity-discovery/main/packages/docs/specification.md", "step": "discover", "summary_md": "Agent Identity & Discovery (AID) answers \"given a domain, where is the agent and which protocol should I speak?\" using a single DNS TXT record published at the fixed base name `_agent.` [1]. It is deliberately minimal: after AID resolves an endpoint and protocol token, richer protocols (MCP, A2A, OpenAPI, OAuth) take over for the actual interaction [1]. It is maintained by \"Agent Community\" as an open-source project (agentcommunity/agent-identity-discovery on GitHub) rather than through any formal standards body.\n\nThe current wire format is v2 (`aid2`), current since 1 June 2026, which supersedes a legacy `aid1` format kept only for backward compatibility during a migration window [1]. A record is a semicolon-delimited `key=value` string with required `version`/`uri`/`proto` (or their single-letter aliases `v`/`u`/`p`), and optional fields for auth hints, description, docs link, deprecation date, and an Ed25519 public key (`pka`/`k`) used for endpoint proof [1]. When a key is present, an AID client performs a PKA (Public-Key-for-Agent) handshake -- HTTP Message Signatures (RFC 9421) over a nonce challenge, keyed by an RFC 7638 JWK thumbprint -- to verify the endpoint controls the corresponding private key [1]. A newer \"domain-binding\" profile (Appendix B.7) lets the endpoint additionally attest that it consents to serve the specific queried domain, closing a gap where any domain could otherwise publish another party's endpoint and key without that endpoint's consent [1].\n\nAID is explicit about what it does not do: it does not issue credentials, grant authorization, prove human approval, define SPIFFE/WIMSE trust-domain federation, or manage cryptographic key rotation -- a key change is simply a key change, with no DNS-level provenance chain [1]. Discovery is exact-host only; clients must not walk up to parent domains, though CNAME delegation lets child hosts share a record explicitly [1]. A `.well-known/agent` HTTP fallback exists for environments (some managed DNS panels) where TXT record creation is restricted, but that path's trust rests on TLS rather than DNS, and cannot satisfy a `dnssec=require` policy [1].\n\nThe project's own GitHub repository (47 stars, 8 forks, fetched 2026-09-06) shows real shipped code: published npm (`@agentcommunity/aid`) and PyPI (`aid-discovery`) packages, source-available Go/Rust/.NET/Java libraries, an `aid-doctor` CLI, a live interactive workbench, and at least one documented live showcase domain (`supabase.agentcommunity.org`) [2] -- so implementation is recorded as shipping. No independent count of AID-publishing domains beyond that one showcase example was located, so adoption is recorded as observed rather than measured. The specification's own roadmap flags that a future major version (`aid3`) is expected to make domain-binding mandatory rather than optional-with-default, once adoption is broad enough that the switching cost is low [1].\n\nWhat is disputed: AID's DNS-TXT approach and the separately-authored, IETF-track DNS-AID specification (see `dns-aid`) solve the identical \"resolve a domain to an agent endpoint\" problem with incompatible record shapes (TXT vs. SVCB), and no evidence of coordination between the two efforts was found in the texts read for this verification.", "track": "community", "version": { "date": "2026-06-01", "label": "v2.1.0 (aid2 wire format; aid1 legacy)" } }, { "acronym": "ADP", "adoption": { "by": null, "level": "unmeasured", "probe_run": null }, "aliases": [], "analog": "a layered service-discovery stack (DNS SRV -> REST descriptor -> live connection), akin to how email escalates from MX lookup to SMTP handshake", "collisions": [ "ADP is a generic acronym also used for 'Agile Development Process' and unrelated ADP payroll/HR company; within the agentic space, distinct from ARDP (Agent Registration and Discovery Protocol) and AID/DNS-AID" ], "discovery": { "mechanism": "Layer 1 DNS-AID (SVCB/TLSA), Layer 2 well-known JSON metadata, Layer 3 HTML landing page + JSON-LD + WebSocket (Agent Gateway Protocol)", "path": "/.well-known/agent.json" }, "dispute": null, "evidence": [ { "claim": "draft-pro-adp-agent-discovery-02 (18 June 2026) defines ADP v1.1 as a three-layer stack: Layer 1 delegates entirely to DNS-AID (SVCB records), Layer 2 defines a GET-able /.well-known/agent.json metadata document, and Layer 3 defines an HTML landing page plus a WebSocket-based Agent Gateway Protocol (AGP) with Ed25519 signature authentication for real-time messaging.", "date": "2026-06-18", "label": "VERIFIED", "url": "https://datatracker.ietf.org/doc/html/draft-pro-adp-agent-discovery-02" }, { "claim": "A reference implementation exists at github.com/harrylian8766/adp-protocol (5 stars, 1 fork, fetched 2026-09-06): a Node.js SDK (protocol identifier urn:adp:1.1) implementing SVCB-first DNS discovery, TLSA/DANE, the /.well-known/agent.json builder, HTML landing-page generation, and a CLI, explicitly version-aligned with draft-pro-adp-agent-discovery-02 and cross-referencing draft-mozleywilliams-dnsop-dnsaid for SvcParamKey usage.", "date": "2026-09-06", "label": "VERIFIED", "url": "https://github.com/harrylian8766/adp-protocol" } ], "form": "well-known-file", "governance": "IETF individual Internet-Draft; explicitly delegates its DNS layer to the separate dnsop-area DNS-AID draft rather than defining its own", "group": null, "history": [ { "date": "2026-09-05", "note": "seeded from Exa Agent research run" }, { "date": "2026-09-06", "note": "verified against draft-pro-adp-agent-discovery-02 spec text via datatracker.ietf.org" }, { "date": "2026-09-06", "note": "fix round 1: added second evidence entry (harrylian8766/adp-protocol reference implementation, fetched directly); upgraded implementation unknown -> prototype on that basis" } ], "id": "adp", "implementation": "prototype", "last_verified": "2026-09-06", "name": "Agent Discovery Protocol", "native_status": "Internet-Draft; work in progress", "origin": { "date": "2026-06-18", "org": "Individual IETF submission" }, "part_of": null, "parties": [ "agent-site", "agent-agent" ], "phase": "draft", "probe": { "method": "GET", "on_absent": "Domain does not publish ADP Layer 2 metadata; check for a DNS-AID SVCB record with a well-known SvcParamKey as a possible Layer 1-only deployment", "parse": "200 response is a JSON document with identity/endpoints/capabilities/security top-level blocks", "path": "https://{origin}/.well-known/agent.json" }, "question": "How does an agent escalate from a cheap DNS lookup, to a well-known JSON metadata document, to a real-time WebSocket session, using only as much machinery as the task needs?", "scope": "general", "spec_url": "https://datatracker.ietf.org/doc/html/draft-pro-adp-agent-discovery-02", "step": "discover", "summary_md": "The Agent Discovery Protocol (ADP) is a layered protocol, currently at v1.1, for discovering, verifying, and interacting with AI agents on the internet [1]. It is an individual IETF Internet-Draft (not adopted by any working group), revision -02, dated 18 June 2026 [1].\n\nADP's organizing idea is escalation: \"if SVCB answers your question, do not issue an HTTP request; if Well-Known suffices, do not open a WebSocket\" [1]. It is explicitly a three-layer stack. Layer 1 is DNS discovery, and rather than redefine it, ADP delegates entirely to the separate DNS-AID Internet-Draft (see `dns-aid`), reusing its SVCB records, its `well-known`/`cap`/`cap-sha256` SvcParamKeys, and its DANE TLSA-based endpoint authentication [1]. Layer 2 is a well-known JSON metadata document, published by default at `/.well-known/agent.json`, containing identity, capability, relationship, security-policy and endpoint-map blocks [1]. Layer 3 covers interaction endpoints: an HTML landing page at the domain root with embedded JSON-LD structured data for human-facing discovery, plus a WebSocket transport -- the Agent Gateway Protocol (AGP) -- for real-time inter-agent messaging authenticated with Ed25519 signatures [1]. A TXT+SRV fallback exists for organizations that cannot deploy SVCB records [1].\n\nADP does not itself mint a new DNS mechanism (Layer 1 is DNS-AID verbatim) and does not define the internal schema of whatever protocol Layer 3 ultimately hands off to (MCP, A2A, etc. remain external, similar to ARD's artifact-agnostic envelope) [1]. Because it explicitly reuses DNS-AID, the two drafts should be read together rather than as fully independent proposals: ADP's Layer 1 section is a summary that points back to the normative DNS-AID text.\n\nCurrent state: revision -02 was published 18 June 2026, expiring 20 December 2026 unless refreshed, and its \"Changes from -00\" section (part of the table of contents) indicates it is still actively being revised rather than stable [1]. A single-author reference implementation was located at github.com/harrylian8766/adp-protocol (5 stars, 1 fork, fetched 2026-09-06): a Node.js SDK and CLI implementing all three layers (SVCB-first DNS discovery aligned with DNS-AID's SvcParamKeys, the agent.json builder, HTML landing-page generation, and Ed25519 verification), published under a CC0 protocol license / MIT SDK license [2]. This is a solo hobbyist project rather than a vendor or standards-body implementation, so implementation is recorded as prototype rather than shipping; no independent deployment or adopter evidence was located, so adoption remains unmeasured.\n\nWhat is disputed or unknown: whether ADP's Layer 2/3 additions (the well-known JSON schema, the WebSocket AGP transport) will be adopted independently of whether DNS-AID itself is adopted, since the two are only loosely coupled (an implementer could deploy DNS-AID without ADP's higher layers, or vice versa using the TXT+SRV fallback); and how ADP's `/.well-known/agent.json` relates to the similarly-named but structurally different `/.well-known/agent` fallback defined by the unrelated AID specification (see `aid`) -- both use the word \"agent\" in a well-known path but are not the same document format.", "track": "ietf", "version": { "date": "2026-06-18", "label": "draft-pro-adp-agent-discovery-02" } }, { "acronym": "ARDP", "adoption": { "by": null, "level": "unmeasured", "probe_run": null }, "aliases": [], "analog": "a service registry with dynamic health/TTL semantics (like Consul or a SIP registrar), applied to agents", "collisions": [ "ARD (Agentic Resource Discovery, unrelated Google/Microsoft/HF spec with a similar acronym and near-identical name)" ], "discovery": { "mechanism": "RESOLVE/QUERY operations over an HTTPS binding, with a minimal metadata resource advertising TTL bounds and supported auth profiles", "path": "/.well-known/ardp/meta" }, "dispute": { "claims": [ "ARDP (this record): RESOLVE/QUERY over HTTPS, TTL-bound presence, single-author IETF draft, expired 5 Aug 2026 with no follow-up seen", "ARD (see ard): search-first federated registry model, Google/Microsoft/HF, actively revised through v0.91 (26 Aug 2026)" ], "summary": "This draft's own name and acronym (ARDP, Agent Registration and Discovery Protocol) is one character and one word away from the entirely unrelated, much more prominent ARD (Agentic Resource Discovery, ard.md) from Google/Microsoft/Hugging Face. They are independent specifications with no shared authorship or mechanism found in the texts read." }, "evidence": [ { "claim": "draft-pioli-agent-discovery-00 (February 2026) specifies ARDP, a lightweight protocol providing stable agent identities (AIDs), dynamic endpoint resolution via RESOLVE/QUERY operations, capability advertisement across MCP/A2A/HTTP/gRPC, TTL-bounded presence records, and a minimal /.well-known/ardp/meta resource; this Internet-Draft expired 5 August 2026 with no successor revision found.", "date": "2026-02", "label": "VERIFIED", "url": "https://datatracker.ietf.org/doc/html/draft-pioli-agent-discovery-00" }, { "claim": "IETF Datatracker's status page for draft-pioli-agent-discovery (fetched 2026-09-06, distinct page from the htmlized draft text) shows the document's IESG state as \"Expired\", type \"Expired Internet-Draft (individual) -- Expired & archived\", with a single author (Roberto Pioli) whose listed e-mail \"may no longer be valid\", and only one revision beyond -00 (the -01 text, latest revision dated 2026-02-24) -- independently confirming this is a lapsed, unrenewed single-author submission rather than an active track.", "date": "2026-09-06", "label": "VERIFIED", "url": "https://datatracker.ietf.org/doc/draft-pioli-agent-discovery/" } ], "form": "endpoint", "governance": "IETF individual Internet-Draft", "group": null, "history": [ { "date": "2026-09-05", "note": "seeded from Exa Agent research run" }, { "date": "2026-09-06", "note": "verified against draft-pioli-agent-discovery-00 spec text via datatracker.ietf.org; noted draft expired 2026-08-05 with no successor found" }, { "date": "2026-09-06", "note": "fix round 1: fetched IETF Datatracker status page as second, independent evidence entry confirming Expired/archived state; corrected version/spec_url from -00 to the actual latest revision -01; set phase from unknown to withdrawn on the strength of the datatracker's own Expired status (resolves the phase-unknown gate without needing an explanatory sentence)" } ], "id": "ardp", "implementation": "none-found", "last_verified": "2026-09-06", "name": "Agent Registration and Discovery Protocol", "native_status": "Internet-Draft; work in progress", "origin": { "date": "2026-02", "org": "Individual IETF submission" }, "part_of": null, "parties": [ "agent-site", "agent-agent", "agent-registry" ], "phase": "withdrawn", "probe": { "method": "GET", "on_absent": "Domain does not run an ARDP-compliant registration/discovery endpoint", "parse": "200 response is JSON with ttl_min, ttl_max, auth_profiles and supported_protocols fields", "path": "https://{origin}/.well-known/ardp/meta" }, "question": "How can an autonomous agent register a stable identity, advertise its capabilities and current endpoints with a TTL, and be discovered by others with minimal metadata leakage?", "scope": "general", "spec_url": "https://datatracker.ietf.org/doc/html/draft-pioli-agent-discovery-01", "step": "discover", "summary_md": "The Agent Registration and Discovery Protocol (ARDP) specifies a lightweight, transport-agnostic protocol for registering, discovering, and reaching autonomous agents in distributed and federated environments, providing stable agent identities, dynamic endpoint resolution, capability advertisement across MCP/A2A/HTTP/gRPC, minimal presence signaling, and a security-first discovery control plane [1]. It is a single-author IETF individual Internet-Draft; the latest text is revision -01, dated 24 February 2026 [1].\n\nIt solves agent liveness and endpoint churn using a TTL-based model: an agent registers with a server, the server assigns and enforces TTL bounds (advertised at `/.well-known/ardp/meta`, e.g. `ttl_min`/`ttl_max`/`auth_profiles`/`supported_protocols`), and clients are expected to refresh at roughly half the TTL with jitter [1]. Discovery is split into a `RESOLVE` operation (map a registered agent identifier to active endpoints and capabilities, access-controlled) and a `QUERY` operation (discover by capability or namespace, also authorized) [1]. Privacy is a first-class concern: `QUERY` responses are minimized by default to just an identifier and status, with full detail gated behind an explicit `detail=full` request parameter, and the server must mark a response `\"redacted\": true` when fields are withheld [1].\n\nARDP does not define its own transport-security handshake beyond referencing a `jws-proof-of-control` auth profile in its example metadata, and does not attempt to be a full registry federation protocol -- there is no evidence in the text read of a cross-registry query mechanism comparable to ARD's `federation` parameter [1].\n\nCurrent state: the IETF Datatracker's own status page (a separate fetch from the draft text itself) shows this document's IESG state as \"Expired -- Expired & archived\", the sole author's listed contact \"may no longer be valid\", and no revision beyond -01 [1][2]. Phase is recorded as withdrawn on the strength of that authoritative status confirmation, not \"unknown\": the document is formally lapsed and archived, not merely undocumented. No implementation, deployment, or adopter evidence was located; implementation is recorded as \"none found\" rather than unknown, since a specific negative search (checking for a follow-up draft and any linked reference implementation) turned up nothing, as distinct from simply not having looked.\n\nWhat is disputed or unknown: whether this specification is abandoned (an expired, unrenewed single-author draft is a weak signal either way, since many individual IETF drafts lapse and are later resubmitted) or quietly superseded by the author moving to a different venue; and, separately, the confusable-name risk with the unrelated, much more actively developed ARD (Agentic Resource Discovery) specification, which shares three of four words in its expansion and a similar acronym but has no connection in governance, mechanism, or authorship.", "track": "ietf", "version": { "date": "2026-02-24", "label": "draft-pioli-agent-discovery-01 (latest revision, expired)" } }, { "acronym": "ADS", "adoption": { "by": null, "level": "unmeasured", "probe_run": null }, "aliases": [ "AGNTCY Directory", "dir" ], "analog": "a distributed package registry (like npm or an OCI container registry) combined with an LDAP-style directory, applied to agents", "collisions": [ "ADS is a generic acronym also used for Active Directory Services and Alternate Data Streams; within the agentic space, unrelated to ARDS/ARD" ], "discovery": { "mechanism": "Content-addressed OCI-artifact storage plus a DHT for global skill-based discovery; a host-local AI Finder service exposes the same records over gRPC and a REST gateway", "path": "/.well-known/ai-catalog.json (host-local AI Finder); GET /v1/agents (REST API)" }, "dispute": null, "evidence": [ { "claim": "draft-mp-agntcy-ads-02 (6 July 2026) defines ADS as a distributed directory service storing agent metadata as content-addressed OCI artifacts, discoverable via a DHT keyed on a skill taxonomy, and exposes an AI Finder service over gRPC and REST (GET /v1/agents, GET /v1/agents/{cid}, GET /v1/agents/{cid}/export, GET /.well-known/ai-catalog.json) that is explicitly interoperable with the AI Catalog / ARD ecosystem.", "date": "2026-07-06", "label": "VERIFIED", "url": "https://datatracker.ietf.org/doc/html/draft-mp-agntcy-ads-02" }, { "claim": "AGNTCY published a technical note describing AI Catalog interoperability layered over its directory service.", "date": "2026-06-17", "label": "REPORTED", "url": "https://blogs.agntcy.org/technical/2026/06/17/ai-catalog-over-directory.html" } ], "form": "endpoint", "governance": "AGNTCY project (github.com/agntcy/dir); submitted as an individual IETF Internet-Draft (draft-mp-agntcy-ads)", "group": null, "history": [ { "date": "2026-09-05", "note": "seeded from Exa Agent research run" }, { "date": "2026-09-06", "note": "verified against draft-mp-agntcy-ads-02 spec text via datatracker.ietf.org" } ], "id": "ads", "implementation": "shipping", "last_verified": "2026-09-06", "name": "Agent Directory Service", "native_status": "Internet-Draft; work in progress; canonical spec tracked at spec.dir.agntcy.org", "origin": { "date": "2026-07-06", "org": "AGNTCY (Cisco Outshift-led project, now under the Linux Foundation)" }, "part_of": null, "parties": [ "agent-site", "agent-registry" ], "phase": "draft", "probe": { "method": "GET", "on_absent": "Host does not run an AGNTCY ADS AI Finder REST gateway; the record may still exist in the distributed hash table without a host-local HTTP surface", "parse": "200 response is a paginated JSON list of CatalogEntry records; a companion GET /.well-known/ai-catalog.json returns the host's WellKnownCatalog document", "path": "https://{origin}/v1/agents" }, "question": "Given a required skill, which agents provide it, where are they, and how can I fetch a verifiable, content-addressed record describing them?", "scope": "general", "spec_url": "https://datatracker.ietf.org/doc/html/draft-mp-agntcy-ads-02", "step": "discover", "summary_md": "The Agent Directory Service (ADS) is a distributed directory for storing and discovering metadata about AI agent applications, structured as records that can be searched by the skills they claim to provide [1]. It originates from AGNTCY (an Outshift/Cisco-led project now positioned under the Linux Foundation) and is written up as an individual IETF Internet-Draft, revision -02, dated 6 July 2026, with its living canonical text tracked outside the IETF at spec.dir.agntcy.org and source at github.com/agntcy/dir [1].\n\nADS solves agent discovery at scale using content-addressed storage: each agent record is packaged as an OCI-compliant artifact (reusing container-registry infrastructure and its manifest/layer model) and identified by a content ID (CID) derived from a cryptographic digest [1]. Records are indexed into a distributed hash table keyed by a multi-level skill taxonomy (plus domain and module taxonomies), so a query for a capability resolves to the CIDs and peer IDs of agents that claim it, without a central registry [1]. Distribution between directory nodes happens over the OCI protocol's peer-to-peer synchronization [1].\n\nDistinct from the DHT-based global layer, ADS also runs a host-local \"AI Finder\" service, exposed over gRPC and, via a gateway, as a REST API: `GET /v1/agents` lists catalog entries with deterministic pagination, `GET /v1/agents/{cid}` retrieves one entry, `GET /v1/agents/{cid}/export` renders a stored OASF record into other ecosystems' native formats (a2a, agent-skill, mcp-ghcopilot), and `GET /.well-known/ai-catalog.json` serves the host's catalog document at the well-known URI this project explicitly designed to interoperate with the ARD/AI Catalog ecosystem [1]. The export operation is described as ADS's \"heterogeneity bridge\" -- one canonical OASF record materialized into several downstream protocols' native card formats without changing its underlying storage representation [1].\n\nADS does not define its own agent capability schema from scratch; it uses the separately-maintained Open Agentic Schema Framework (OASF, see `oasf`) as its native record format, and treats other ecosystems' formats (A2A cards, MCP server descriptors) as export targets rather than first-class stored types [1].\n\nCurrent state: the draft was published 6 July 2026 and expires 7 January 2027; it explicitly states it is \"to be removed before publishing as an RFC,\" i.e. still a working draft rather than a finished document [1]. Unlike several other records on this map, this one has a concrete, buildable open-source implementation (github.com/agntcy/dir) referenced directly from the spec text, which supports recording implementation as \"shipping\" -- but no independent count of production deployments or registered agents was located, so adoption remains unmeasured.\n\nWhat is disputed or unknown: how ADS's DHT-based global layer interacts in practice with a search-first, centralized-registry model like ARD's -- the \"AI Catalog Interoperability\" section of the draft describes projection and export, but whether third parties beyond AGNTCY's own tooling actually consume ADS-hosted records via the ai-catalog.json path was not independently verified here.", "track": "linux-foundation", "version": { "date": "2026-07-06", "label": "draft-mp-agntcy-ads-02" } }, { "acronym": "OASF", "adoption": { "by": null, "level": "observed", "probe_run": null }, "aliases": [], "analog": "schema.org for agents, or an industry-standard product taxonomy (like GS1) applied to AI capabilities", "collisions": [], "discovery": { "mechanism": "not a discovery-path mechanism itself; consumed as the record schema underlying AGNTCY's Agent Directory Service (ADS) and its OCI-artifact export format", "path": "none" }, "dispute": null, "evidence": [ { "claim": "The OASF schema browser (schema.oasf.outshift.com), fetched 2026-09-06, currently serves versions 0.7.0 through 1.1.0 and defines a multi-level taxonomy of Skills (e.g. Language Processing > Language Understanding > Contextual Comprehension), Domains and Modules, plus Record Dictionary Objects and Data Types, with linked API documentation and a public GitHub contribution flow.", "date": "2026-09-06", "label": "VERIFIED", "url": "https://schema.oasf.outshift.com/" }, { "claim": "AGNTCY's Agent Directory Service (ADS) draft names OASF explicitly as the native record format its Agent Directory Records are stored in, and as one of the export targets from its AI Finder REST API.", "date": "2026-07-06", "label": "VERIFIED", "url": "https://datatracker.ietf.org/doc/html/draft-mp-agntcy-ads-02" } ], "form": "document-format", "governance": "AGNTCY project, published under Linux Foundation-adjacent open governance; source and issue tracker on GitHub, browsable schema at schema.oasf.outshift.com", "group": null, "history": [ { "date": "2026-09-05", "note": "seeded from Exa Agent research run" }, { "date": "2026-09-06", "note": "verified against live OASF schema browser at schema.oasf.outshift.com and cross-checked against draft-mp-agntcy-ads-02" } ], "id": "oasf", "implementation": "shipping", "last_verified": "2026-09-06", "name": "Open Agentic Schema Framework", "native_status": "Active, versioned schema framework", "origin": { "date": null, "org": "Cisco Outshift / AGNTCY" }, "part_of": null, "parties": [ "agent-registry", "agent-site" ], "phase": "living", "probe": { "method": "GET", "on_absent": "Not applicable at a per-domain level -- OASF is a shared taxonomy consumed by registries and records, not a well-known site artifact; absence just means a given record does not declare an OASF-conformant schema_version", "parse": "200 response is a JSON Schema document for the requested OASF class/version, confirming which schema version a given record or registry claims to conform to", "path": "https://schema.oasf.outshift.com/{version}/objects/{class}.json" }, "question": "How can an agent's skills, domains, deployment modules and identity be described using a shared, versioned taxonomy so registries can classify and filter it consistently?", "scope": "general", "spec_url": "https://schema.oasf.outshift.com/", "step": "discover", "summary_md": "The Open Agentic Schema Framework (OASF) is a versioned, hierarchical taxonomy and JSON Schema set for describing an AI agent's skills, domains, and deployment modules, published by Cisco Outshift's AGNTCY project [1]. Unlike most other records under Discover, OASF is not itself a discovery *mechanism* (there is no well-known path or DNS record that \"is\" OASF); it is a shared vocabulary that other discovery mechanisms use to classify what they find.\n\nIt solves a taxonomy-consistency problem: without a shared vocabulary, one registry's \"text summarization\" and another's \"document condensation\" cannot be matched by an automated filter. OASF assigns every skill, domain and module a stable numeric code within a browsable, versioned hierarchy -- for example, Language Processing [1] > Language Understanding [101] > Contextual Comprehension [10101] -- so registries and search clients can filter and aggregate on identical codes rather than free text [1]. The live schema browser at schema.oasf.outshift.com, fetched 6 September 2026, serves four schema versions concurrently (0.7.0, 0.8.0, 1.0.0, 1.1.0), each with its own Classes, Skills, Domains, Modules, Record Dictionary, Objects and Data Types sections, plus linked API documentation and a GitHub-based contribution path [1].\n\nOASF does not define transport, discovery paths, or a registry protocol of its own -- those are the job of AGNTCY's separate Agent Directory Service (ADS, see `ads`), which stores records natively in OASF and can export them into other ecosystems' formats (A2A cards, MCP server descriptors, agent-skill files) without changing the underlying OASF-tagged storage [2]. This makes OASF's own adoption hard to measure independently of ADS's: the clearest evidence of use found during this verification is that ADS's specification names OASF as its native record schema and export source, which is direct but is a single implementer's declared dependency rather than an independent count of registries or agents tagged against the taxonomy [2].\n\nCurrent state: the schema is actively versioned (four concurrent versions browsable, with a \"show deprecated items\" toggle implying an active deprecation/lifecycle process) but carries no publication date of its own on the browser page, unlike the dated IETF drafts and the ARD spec elsewhere on this map -- version history is tracked through the schema browser's version selector rather than a single canonical spec document with a title-page date [1]. Implementation is recorded as \"shipping\" on the strength of the AGNTCY/ADS dependency; adoption is recorded as \"observed\" rather than \"measured\" or \"claimed,\" since no adopter beyond AGNTCY's own tooling was independently verified and no probe was run.\n\nWhat is disputed or unknown: whether any registry or agent framework outside the AGNTCY/ADS lineage has adopted OASF as its primary skill taxonomy, versus ADS being currently its only real consumer; and how OASF's numeric skill codes relate (if at all) to ARD's free-text `capabilities` filter tokens or `representativeQueries` mechanism, which solve an adjacent classification problem without a shared taxonomy.", "track": "linux-foundation", "version": { "date": null, "label": "1.1.0 (also serving 0.7.0, 0.8.0, 1.0.0)" } }, { "acronym": "A2UI", "adoption": { "by": null, "level": "observed", "probe_run": null }, "aliases": [ "Agent-to-UI Protocol", "Agent to UI Protocol" ], "analog": "HTML (declarative UI markup)", "collisions": [ "AG-UI" ], "discovery": { "mechanism": "No fixed well-known path; renderer and agent capabilities (supported catalogs, custom components) are exchanged via transport-specific handshakes, e.g. A2A Agent Cards or MCP initialization metadata", "path": null }, "dispute": { "claims": [ "a2ui.org 'View source' points to github.com/a2ui-project/a2ui (used as canonical here)", "docs.ag-ui.com/introduction links A2UI to github.com/google/A2UI" ], "summary": "Two GitHub locations are both cited for A2UI: the canonical 'View source of this page' link on a2ui.org points to a2ui-project/a2ui, but AG-UI's own docs (fetched 2026-09-05) still link A2UI to github.com/google/A2UI. This looks like an org rename or fork that the AG-UI docs have not caught up with, not a governance dispute, but it is unresolved which is authoritative going forward." }, "evidence": [ { "claim": "A2UI Protocol v1.0 spec text (Status: Candidate, Created Nov 20 2025, Last Updated Jun 8 2026) defines a streaming JSON UI protocol with four agent-to-renderer message types (createSurface, updateComponents, updateDataModel, deleteSurface) and named transport bindings for AG-UI, A2A, and MCP.", "date": "2026-06-08", "label": "VERIFIED", "url": "https://a2ui.org/specification/v1.0-a2ui/" }, { "claim": "Canonical repo github.com/a2ui-project/a2ui: Apache-2.0 license, Google LLC copyright headers, README states current status 'Early stage public preview' with v0.9.1 as the current production release, v1.0 a release candidate, v0.8 legacy; renderers/host frameworks listed are Web and Flutter, with Lit/Angular/React renderer demos.", "date": "2026-09-05", "label": "VERIFIED", "url": "https://github.com/a2ui-project/a2ui" }, { "claim": "AG-UI's own documentation lists A2UI as a supported 'Generative UI, declarative' spec and names AG-UI as A2UI's standard transport binding, but still links A2UI to github.com/google/A2UI rather than the current a2ui-project org.", "date": "2026-09-05", "label": "VERIFIED", "url": "https://docs.ag-ui.com/introduction" } ], "form": "document-format", "governance": "a2ui-project (Google-originated, open-source on GitHub; Apache-2.0)", "group": null, "history": [ { "date": "2026-09-05", "note": "seeded from Exa Agent research run" }, { "date": "2026-09-06", "note": "verified against a2ui.org v1.0 spec and github.com/a2ui-project/a2ui" } ], "id": "a2ui", "implementation": "multi-implementation", "last_verified": "2026-09-06", "name": "A2UI (Agent to UI) Protocol", "native_status": "Early stage public preview: v0.9.1 is the 'Current' production release, v1.0 is a release 'Candidate', v0.8 is legacy", "origin": { "date": "2025-11-20", "org": "Google LLC" }, "part_of": null, "parties": [ "agent-human" ], "phase": "candidate", "probe": { "method": "GET", "on_absent": "No A2UI capability declared; the agent returns only text or opaque structured JSON, not a declarative UI surface", "parse": "Presence of an A2UI catalogId/capability declaration in the handshake metadata, or a createSurface/updateComponents/updateDataModel/deleteSurface message in the response stream", "path": "{endpoint} — the AG-UI, A2A, or MCP endpoint the agent exposes; inspect its handshake/Agent Card/initialization payload" }, "question": "How can an agent describe and stream a framework-neutral, declarative UI to a renderer?", "scope": "general", "spec_url": "https://a2ui.org/specification/v1.0-a2ui/", "step": "present", "summary_md": "A2UI (Agent to UI) is a JSON message protocol that lets an agent describe and incrementally stream a declarative, framework-neutral user interface to a client renderer. Communication is a stream of JSON objects; the agent-to-renderer protocol defines four message types — `createSurface`, `updateComponents`, `updateDataModel`, and `deleteSurface` — and the renderer maps abstract component descriptions (Card, Button, TextField, etc.) onto its own native widgets (Flutter, Angular, Lit, React, SwiftUI, or plain web components) [1]. The core design goal is safety: agents can only reference components from a client-defined, pre-approved 'catalog,' so a UI payload is 'safe like data, but expressive like code' rather than executable code [2].\n\nA2UI does not define its own transport. It is explicitly transport-agnostic and is documented with named bindings for three carriers: AG-UI (described as A2UI's 'standard transport binding'), the A2A protocol (via a dedicated A2A extension spec), and MCP (carried over tool calls, tool outputs, or resource subscriptions), plus generic support for SSE+JSON-RPC, WebSockets, and REST [1]. It solves the problem of agents needing to present rich, interactive interfaces — especially remote agents or agents running across a trust boundary — without shipping arbitrary executable code to the client [2]. It does not itself specify authentication, payment, or discovery of an agent's existence; those are left to whichever transport (AG-UI, A2A, MCP) carries it.\n\nCurrent state (as of 2026-09-05): the project describes itself as an 'early stage public preview.' The production-recommended version is v0.9.1 (a patch on the stable v0.9 family); v1.0 is a release candidate adding bidirectional typed function calls and single-message UI instantiation; v0.8 is legacy [2]. The canonical repository, github.com/a2ui-project/a2ui, carries an Apache-2.0 license and Google LLC copyright headers, and the spec site's own 'view source' link resolves to that same repository [1][2]. Reference renderers exist for Flutter and web frameworks (Lit, Angular, React), with a visual 'A2UI Composer' and a multi-renderer 'A2UI Theater' demo; the AG-UI project ships an `a2ui-toolkit` package and CopilotKit has added catalog-forwarding integration, indicating active cross-project use rather than a single-vendor demo [3].\n\nWhat is disputed or unknown: whether A2UI should be classified as a single-vendor (Google) spec or something closer to a vendor-consortium is judgment-dependent — the code and copyright are Google's, but the working GitHub org name ('a2ui-project') and the AG-UI/CopilotKit integration suggest broader de facto involvement. AG-UI's own docs (fetched 2026-09-05) still point to `github.com/google/A2UI` rather than the current `a2ui-project` org, an unresolved naming/rename inconsistency. No independent adoption count exists; observed ecosystem activity (16.3k GitHub stars, AG-UI/CopilotKit integration, multiple demo renderers) has not been converted into a documented probe run, so adoption here is 'observed,' not 'measured.'", "track": "single-vendor", "version": { "date": "2026-06-08", "label": "v1.0 (Candidate); v0.9.1 (Current)" } }, { "acronym": "AG-UI", "adoption": { "by": null, "level": "observed", "probe_run": null }, "aliases": [ "AG-UI Protocol" ], "analog": "A server-sent-events/WebSocket API contract between a web frontend and its backend", "collisions": [ "A2UI" ], "discovery": { "mechanism": "No fixed well-known path; a client is coded against a known agent backend endpoint that emits an AG-UI-compatible event stream over an agreed transport (SSE, WebSockets, webhooks)", "path": null }, "dispute": null, "evidence": [ { "claim": "CopilotKit's own announcement post, dated May 12, 2025, introduces AG-UI as 'an open, lightweight protocol that streams a single sequence of JSON events over standard HTTP or an optional binary channel.'", "date": "2025-05-12", "label": "VERIFIED", "url": "https://webflow.copilotkit.ai/blog/introducing-ag-ui-the-protocol-where-agents-meet-users" }, { "claim": "docs.ag-ui.com/introduction (fetched 2026-09-05) describes AG-UI as an open, lightweight, event-based protocol, positions it as the 'Agent ↔ User Interaction' layer alongside MCP (Agent ↔ Tools & Data, from Anthropic) and A2A (Agent ↔ Agent, from Google), and lists 1st-party integrations from Microsoft Agent Framework, Google ADK, AWS Strands/Bedrock AgentCore, plus SDKs in Kotlin, Go, Dart, Java, Rust, Ruby, C++, .NET.", "date": "2026-09-05", "label": "VERIFIED", "url": "https://docs.ag-ui.com/introduction" }, { "claim": "GitHub repo github.com/ag-ui-protocol/ag-ui carries an MIT license, 15.7k stars, 3,840+ commits, and daily commit activity as of Sep 4-5, 2026, indicating an actively maintained, multi-contributor project rather than a dormant announcement.", "date": "2026-09-05", "label": "VERIFIED", "url": "https://github.com/ag-ui-protocol/ag-ui" } ], "form": "endpoint", "governance": "AG-UI open-source project (github.com/ag-ui-protocol), originated and still primarily stewarded by CopilotKit; biweekly public working group", "group": null, "history": [ { "date": "2026-09-05", "note": "seeded from Exa Agent research run" }, { "date": "2026-09-06", "note": "verified against docs.ag-ui.com/introduction, github.com/ag-ui-protocol/ag-ui, and CopilotKit's original announcement" } ], "id": "ag-ui", "implementation": "multi-implementation", "last_verified": "2026-09-06", "name": "Agent-User Interaction Protocol", "native_status": "Open, lightweight, event-based protocol; described by its maintainers as the general-purpose, bi-directional connection between a user-facing application and any agentic backend", "origin": { "date": "2025-05-12", "org": "CopilotKit" }, "part_of": null, "parties": [ "agent-human" ], "phase": "living", "probe": { "method": "POST", "on_absent": "No AG-UI-shaped event stream; the backend is not exposing an AG-UI-compatible interface", "parse": "Response is an event stream using AG-UI's ~16 standard event types (e.g. TEXT_MESSAGE_START/CONTENT/END, RUN_ERROR, STATE_SNAPSHOT); presence of these event names confirms AG-UI compliance", "path": "{endpoint} — the application-defined AG-UI run endpoint (no fixed path; confirmed per-integration, e.g. via a framework's AG-UI adapter)" }, "question": "How does an agent stream state, generative UI, messages, and tool activity into a user-facing application in real time?", "scope": "general", "spec_url": "https://docs.ag-ui.com/introduction", "step": "present", "summary_md": "AG-UI (Agent-User Interaction Protocol) is an open, lightweight, event-based protocol that standardizes how an AI agent backend streams state, messages, generative-UI updates, and tool activity into a user-facing frontend application, and how the frontend sends interactions and tool results back. CopilotKit announced it on May 12, 2025 as 'an open, lightweight protocol that streams a single sequence of JSON events over standard HTTP or an optional binary channel' [1]. Its own docs position it as one of three complementary 'agentic protocols': MCP handles Agent↔Tools/Data, A2A handles Agent↔Agent, and AG-UI handles Agent↔User Interaction — it is explicitly not a competitor to either [2].\n\nMechanically, an agent backend emits roughly sixteen standard event types (e.g. streaming text message chunks, tool-call events, state snapshots and diffs, run lifecycle/error events) over whatever transport the integration chooses — SSE, WebSockets, or webhooks are all named as compatible — and a middleware layer normalizes 'loose event format matching' so different backend frameworks and different frontend clients can interoperate without agreeing on a single wire transport [2]. AG-UI itself does not define a fixed origin path or well-known discovery file; a given application wires its own agent endpoint and a client library (or hand-rolled parser) that speaks the event vocabulary. AG-UI does not solve tool invocation (that is MCP's job) or agent-to-agent delegation (A2A's job), and it does not define authentication, payment, or content-permission mechanics.\n\nCurrent state (as of 2026-09-05): the protocol is actively developed under github.com/ag-ui-protocol/ag-ui (MIT license), which shows 15.7k stars, 170 branches, and near-daily commits including a merge less than a day before this check. It is described in its own docs as supported 'first-party' by Microsoft Agent Framework, Google ADK, AWS Strands Agents, Mastra, Pydantic AI, Agno, LlamaIndex, AG2, and AWS Bedrock AgentCore, with community-maintained SDKs in Kotlin, Go, Dart, Java, Rust, Ruby, C++, and .NET, and CopilotKit itself as the reference first-party client [2][3]. AG-UI also documents relationships with two adjacent generative-UI specs — A2UI (which it calls its own declarative generative-UI companion, with AG-UI as A2UI's 'standard transport binding') and MCP Apps — treating both as things it can carry rather than as competitors.\n\nWhat is disputed or unknown: there is no independent, documented count of production deployments; the evidence here is repository activity and named partner integrations, which is 'observed,' not a measured census. The relationship between AG-UI, originated and still steered largely by CopilotKit, and 'community' governance is informal — there is a public Discord and a biweekly working group, but no independent foundation. It is unclear how much of the 1st-party partner list reflects deployed production traffic versus documented compatibility.", "track": "community", "version": { "date": null, "label": "protocol stable, packages versioned independently (e.g. @ag-ui/core on npm)" } }, { "acronym": "OSI", "adoption": { "by": null, "level": "unmeasured", "probe_run": null }, "aliases": [ "Open Semantic Interchange", "Apache Ossie" ], "analog": "a shared data dictionary made machine-readable, distributed like a schema file rather than an API", "collisions": [ "Open Source Initiative (osi.org)" ], "discovery": { "mechanism": "none", "path": null }, "dispute": { "claims": [ "Marketing claims the spec is 'finalized'; the repository's own version marker says draft/unreleased.", "track=community is a placeholder; the real governance is 'ASF Incubator podling,' which the current vocab does not model." ], "summary": "Snowflake's January 2026 post is titled 'OSI Specification Finalized,' but the specification text in the repository is versioned 0.2.0.dev0 and explicitly marked DRAFT, with the only tagged release a release-candidate (osi-0.1.1-rc1). 'Finalized' appears to describe the *initial publication* of a spec document, not a stable/final version number. Separately, vocab.json has no track value for 'Apache Software Foundation incubator project' distinct from 'linux-foundation' (LF-specific) or 'industry-body' (trade association); 'community' was chosen as the least-wrong fit but understates that Ossie now has ASF Incubator governance (mentors, PPMC, a defined graduation process) rather than no formal governance." }, "evidence": [ { "claim": "Snowflake announced the Open Semantic Interchange initiative on 2025-09-23 with Salesforce, BlackRock, dbt Labs and RelationalAI as co-leading partners, plus a wider coalition (Alation, Atlan, Tableau, ThoughtSpot, Sigma, Omni and others).", "date": "2025-09-23", "label": "VERIFIED", "url": "https://www.snowflake.com/en/news/press-releases/snowflake-salesforce-dbt-labs-and-more-revolutionize-data-readiness-for-ai-with-open-semantic-interchange-initiative/" }, { "claim": "Snowflake's 2026-01-27 post says 'the first version of the OSI specification is now available' via an Apache-2.0 licensed repo at github.com/open-semantic-interchange/OSI, and that OSI would later move to 'a neutral, foundation-led governance model.'", "date": "2026-01-27", "label": "VERIFIED", "url": "https://www.snowflake.com/en/blog/open-semantic-interchanges-specs-finalized/" }, { "claim": "The project entered the Apache Incubator on 2026-06-22 as 'Apache Ossie (incubating)'; the original open-semantic-interchange GitHub org now shows 0 public repositories and github.com/open-semantic-interchange/OSI redirects to github.com/apache/ossie.", "date": "2026-06-22", "label": "VERIFIED", "url": "https://incubator.apache.org/projects/ossie.html" }, { "claim": "The current core specification file (core-spec/spec.md) is headed 'DRAFT version -- in development, schema may change before 0.2.0 is released' and labelled Version 0.2.0.dev0; the repository's only Git tag is osi-0.1.1-rc1, not a v1.0 -- contradicting the 'specification finalized' framing of the January 2026 announcement.", "date": "2026-09-05", "label": "VERIFIED", "url": "https://raw.githubusercontent.com/apache/ossie/main/core-spec/spec.md" } ], "form": "document-format", "governance": "Apache Software Foundation, Apache Incubator (Ossie Podling Project Management Committee); formerly a Snowflake-led multi-vendor working group", "group": null, "history": [ { "date": "2026-09-05", "note": "seeded from Exa Agent research run" }, { "date": "2026-09-06", "note": "verified against github.com/apache/ossie (README, core-spec/spec.md), incubator.apache.org/projects/ossie.html, and Snowflake's 2025-09-23 and 2026-01-27 posts; moved step from 'account' to 'read', corrected spec_url, name, governance, and version; flagged draft-vs-finalized dispute" } ], "id": "osi", "implementation": "prototype", "last_verified": "2026-09-06", "name": "Apache Ossie (formerly Open Semantic Interchange)", "native_status": "Undergoing incubation at the Apache Software Foundation ('Apache Ossie (incubating)'); not yet a top-level ASF project. Core spec is marked DRAFT.", "origin": { "date": "2025-09-23", "org": "Snowflake, with Salesforce, dbt Labs, BlackRock and RelationalAI as founding partners" }, "part_of": null, "parties": [ "agent-site" ], "phase": "draft", "probe": { "method": "GET", "on_absent": "If a tool claims 'OSI' or 'Ossie compatibility' but cannot produce a document that validates against this schema, the claim cannot be confirmed.", "parse": "Fetch the JSON Schema, then validate a candidate semantic-model file (dataset/metric/dimension document) against it; a pass confirms the file is Ossie/OSI-conformant. There is no fixed well-known path or origin endpoint — OSI/Ossie is an exchanged document format, not a runtime discovery protocol.", "path": "https://raw.githubusercontent.com/apache/ossie/main/core-spec/ossie-schema.json" }, "question": "How can an AI agent or BI tool read a metric or data-model definition and get the same meaning another tool intended?", "scope": "general", "spec_url": "https://github.com/apache/ossie", "step": "read", "summary_md": "OSI/Apache Ossie is a JSON- and YAML-based specification for representing semantic-layer objects (datasets, metrics, dimensions, relationships) so that BI tools, data catalogs and AI/agentic applications compute a term like \"churn rate\" the same way regardless of which vendor's tool wrote the definition [1]. It is a document/interchange format, not a network protocol: there is no discovery endpoint or well-known path, and no runtime negotiation. Consumption happens by reading (or generating) a semantic-model file against the published JSON Schema -- which is why this record has been moved from the site's original 'account' placement to 'read': OSI is squarely about machine-readable representations of content (metric/data definitions) for consumption by BI and agent tooling, not about recording or attributing actions after the fact.\n\n**What it does not do:** OSI/Ossie does not define an API, an audit trail, an authentication scheme, or a discovery mechanism. It says nothing about who is allowed to read or write a given semantic model, and it does not itself measure or certify adoption.\n\n**Current state.** Snowflake announced OSI on 2025-09-23 with Salesforce, BlackRock, dbt Labs and RelationalAI as co-leads, alongside a larger coalition of BI/data vendors [1]. On 2026-01-27 Snowflake published \"the first version of the OSI specification\" as an Apache-2.0 repository and said governance would eventually move to a neutral foundation [2]. That move happened on 2026-06-22, when the project entered the Apache Incubator as \"Apache Ossie (incubating)\"; the original open-semantic-interchange GitHub organization now has zero public repositories, and its old repo URL redirects to github.com/apache/ossie [3]. As of this verification, the live core specification is versioned 0.2.0.dev0 and is explicitly marked DRAFT -- \"schema may change before 0.2.0 is released\" -- and the only Git tag in the history is a release-candidate, osi-0.1.1-rc1, not a 1.0 [4]. This means the January 2026 \"specification finalized\" headline describes the spec's first public release, not a stable/versioned final; readers should not assume OSI has reached a frozen v1.0.\n\n**Who implements it.** The repository ships reference converters for a dozen vendor ecosystems -- Snowflake, Databricks, Salesforce, dbt, GoodData, NVIDIA, Omni, Polaris, Honeydew, Wisdom, OrionBelt and an ontology bridge -- but these live in a converters/ directory of a repo whose core spec is still draft, so they read as reference/example integrations rather than confirmed production deployments; this record conservatively marks implementation as 'prototype' rather than 'multi-implementation.'\n\n**Disputed / unknown.** Whether OSI's broad vendor coalition (dbt Labs, Salesforce, BlackRock, Databricks, Mistral AI and ~30 others) reflects production adoption of the spec itself, or membership in a working group around a still-drafting spec, is not independently measurable from public sources. No probe has been run; adoption is marked unmeasured rather than claimed, because no single party made a countable claim we could cite. The vocabulary used by this site for 'track' does not have a category for an ASF Incubator podling, which is a materially different governance state from an informal community project.", "track": "community", "version": { "date": null, "label": "0.2.0.dev0 (draft, in development); last tagged pre-release osi-0.1.1-rc1" } }, { "acronym": "OKF", "adoption": { "by": null, "level": "unmeasured", "probe_run": null }, "aliases": [], "analog": "a wiki or knowledge base (Obsidian vault, Notion space) with structured frontmatter, kept in git", "collisions": [ "Open Knowledge Foundation (okfn.org) — an unrelated, pre-existing nonprofit that also uses the initialism OKF" ], "discovery": { "mechanism": "none — a bundle is a directory of markdown files distributed as a git repository, tarball/zip, or subdirectory of a larger repo; there is no fixed web-origin path or well-known convention for locating one", "path": "none" }, "dispute": null, "evidence": [ { "claim": "Full OKF v0.2 specification: bundle structure, concept documents and frontmatter, provenance/trust/lifecycle fields (`sources`, `generated`, `verified`, `status`, `stale_after`), cross-linking, actor convention, index/log files, Attested Computation concepts, conformance rules (only `type` is required; consumers must not reject unknown fields/types/broken links), and versioning policy", "date": "2026-08", "label": "VERIFIED", "url": "https://raw.githubusercontent.com/GoogleCloudPlatform/open-knowledge-format/main/SPEC.md" }, { "claim": "Google Cloud announced OKF v0.1 on 2026-06-12: a directory of markdown files with YAML frontmatter, requiring no SDK or new runtime; shipped with a reference enrichment agent, a static HTML visualizer, and three sample bundles (GA4, Stack Overflow, Bitcoin) explicitly described as 'proofs of concept'", "date": "2026-06-12", "label": "VERIFIED", "url": "https://cloud.google.com/blog/products/data-analytics/how-the-open-knowledge-format-can-improve-data-sharing" }, { "claim": "The OKF specification and reference implementation moved out of GoogleCloudPlatform/knowledge-catalog into its own dedicated repository, GoogleCloudPlatform/open-knowledge-format; the old location is marked a frozen, unmaintained snapshot with an explicit notice to stop using it", "date": "2026-08", "label": "VERIFIED", "url": "https://raw.githubusercontent.com/GoogleCloudPlatform/knowledge-catalog/main/okf/README.md" }, { "claim": "The dedicated open-knowledge-format GitHub repository was created 2026-08-11 and had 288 stargazers and 11 forks as of this verification", "date": "2026-09-05", "label": "VERIFIED", "url": "https://github.com/GoogleCloudPlatform/open-knowledge-format" } ], "form": "document-format", "governance": "Google Cloud open-source project; canonical repository is GoogleCloudPlatform/open-knowledge-format on GitHub (moved out of the GoogleCloudPlatform/knowledge-catalog monorepo in August 2026, which now carries only a frozen, unmaintained snapshot)", "group": null, "history": [ { "date": "2026-09-05", "note": "seeded from Exa Agent research run" }, { "date": "2026-09-06", "note": "verified against the OKF v0.2 SPEC.md, the original Google Cloud blog announcement, and the repo-migration notice in the old knowledge-catalog/okf directory" } ], "id": "okf", "implementation": "prototype", "last_verified": "2026-09-06", "name": "Open Knowledge Format", "native_status": "\"An open specification; contributions, alternative implementations, and adoption beyond Google products are all explicitly welcomed\"", "origin": { "date": "2026-06-12", "org": "Google Cloud (Data Cloud team: Sam McVeety, Amir Hormati)" }, "part_of": null, "parties": [ "agent-site" ], "phase": "draft", "probe": { "method": "N/A", "on_absent": "No conformant OKF bundle at the given location; this says nothing about whether the org has other, non-OKF internal documentation", "parse": "Every non-reserved `.md` file in the tree has a parseable YAML frontmatter block containing a non-empty `type` field (OKF §11 conformance); an optional root `index.md` may declare `okf_version`", "path": "none — bundle location is producer-defined (git repo URL, tarball, or subdirectory path); not servable via a fixed {origin} convention" }, "question": "How can an organization package durable, structured knowledge (schemas, metrics, playbooks, runbooks) so both humans and agents can read, produce, and trust it without a bespoke SDK?", "scope": "general", "spec_url": "https://github.com/GoogleCloudPlatform/open-knowledge-format/blob/main/SPEC.md", "step": "read", "summary_md": "The Open Knowledge Format (OKF) is a Google-originated specification for representing organizational knowledge — table schemas, metric definitions, playbooks, API references — as a directory of plain markdown files with YAML frontmatter [1][2]. Each unit of knowledge (a \"concept\") is one markdown file; the only required field is `type`, everything else (title, description, tags, and an open-ended set of trust/provenance/lifecycle fields) is optional, and unknown fields or types must be tolerated by any conformant consumer [1]. Concepts cross-link with ordinary markdown links, so a bundle forms a graph, not just a directory tree.\n\nIt solves the problem of fragmented, non-portable \"tribal knowledge\" that today lives in metadata catalogs, wikis, code comments, and senior engineers' heads, and that every organization and every catalog vendor re-solves from scratch with incompatible schemas and SDKs [2]. Because a bundle is just files, it is git-diffable, requires no proprietary API to read or write, and formalizes an already-emerging pattern (the \"LLM-wiki\": Obsidian vaults, `AGENTS.md`/`CLAUDE.md` files, ad hoc `index.md`/`log.md` conventions) rather than inventing a new one [2]. v0.2, the current version, adds first-class provenance (`sources`, with per-source credibility signals like `usage_count` and `last_modified`), trust tiers derived from `verified` events, lifecycle fields (`status`, `stale_after`), and a dedicated \"Attested Computation\" concept type that lets a value's sanctioned computation be checked against what actually ran [1].\n\nWhat it does not do: define a fixed taxonomy of concept types, prescribe any storage/serving/query infrastructure, replace domain-specific schemas such as Avro or OpenAPI (it references them, not subsumes them), or specify a packaging/invocation standard for the code an executor or attester points at [1]. It also has no discovery mechanism of its own — there is no well-known path or fixed convention for finding a bundle at a web origin; a bundle's location is whatever the producer chooses (a git repo URL, a tarball, a subdirectory).\n\nCurrent state, as of this verification (September 2026): OKF v0.1 was announced 2026-06-12 and v0.2 followed by August 2026, when the project also moved out of the `GoogleCloudPlatform/knowledge-catalog` monorepo into its own dedicated repository, `GoogleCloudPlatform/open-knowledge-format`; the old location now carries only a frozen, explicitly unmaintained snapshot [3]. The dedicated repo, created 2026-08-11, had 288 GitHub stars and 11 forks as of 2026-09-05 [4]. All shipped tooling — the reference enrichment agent (BigQuery-to-OKF) and the static HTML graph visualizer — is explicitly described by Google as a \"proof of concept,\" and the only public examples of conformant bundles are the sample datasets Google itself produced (GA4, Stack Overflow, Bitcoin, and a fourth 'Acme Retail' sample added after the initial announcement) [1][3].\n\nWhat is disputed or unknown: no adoption beyond Google's own samples and Google Cloud's Knowledge Catalog integration was found; there is no independent producer or consumer implementation, no third-party adoption count, and no evidence yet of OKF being used to back a production agent system outside Google. \"OKF\" also collides with the pre-existing Open Knowledge Foundation (okfn.org), an unrelated nonprofit; care is needed to distinguish the two in any listing.", "track": "single-vendor", "version": { "date": "2026-08", "label": "v0.2" } }, { "acronym": "", "adoption": { "by": null, "level": "unmeasured", "probe_run": null }, "aliases": [ "Apps SDK", "ChatGPT Apps", "OpenAI Apps SDK" ], "analog": "Plugin manifest plus iframe component", "collisions": [ "ChatGPT Plugins (the 2023 predecessor product, since retired)", "MCP Apps (the underlying open standard OpenAI's UI layer now builds on)" ], "discovery": { "mechanism": "A plugin is an MCP server (streamable-HTTP, stable endpoint) plus optional Skills and an optional UI resource; ChatGPT/Codex discover a plugin's tools through the standard MCP tools/list call after a user installs/connects it, not through open web crawling", "path": "none public/well-known; plugins are submitted to and listed in OpenAI's plugin directory (developers.openai.com/plugins) rather than self-announced by a site" }, "dispute": null, "evidence": [ { "claim": "developers.openai.com/apps-sdk now redirects to developers.openai.com/plugins; the section is branded 'Plugins', described as extending 'ChatGPT and Codex with reusable skills and connections to external services', built from three core concepts: Plugin architecture, Skills, and an MCP server.", "date": "2026", "label": "VERIFIED", "url": "https://developers.openai.com/apps-sdk" }, { "claim": "A plugin's MCP server can expose tools, resources, prompts, and instructions; plugins primarily use tools; production MCP servers must be deployed at stable HTTPS endpoints using the streamable HTTP transport and, if handling private data, must implement the MCP specification's authorization flow. The official Python and TypeScript MCP SDKs are the recommended implementation path.", "date": "2026", "label": "VERIFIED", "url": "https://developers.openai.com/plugins/concepts/mcp-server" }, { "claim": "ChatGPT implements the open MCP Apps standard for optional plugin UI: a tool declares `_meta.ui.resourceUri`, communication runs over a `ui/*` JSON-RPC bridge via postMessage, and OpenAI-specific `window.openai` extensions (checkout, file upload, widget state) are explicitly positioned as a secondary layer to use 'only for capabilities the shared specification does not cover' — with documented compatibility aliases mapping each ChatGPT-specific field/method to its MCP Apps equivalent.", "date": "2026", "label": "VERIFIED", "url": "https://developers.openai.com/plugins/build/chatgpt-ui" } ], "form": "endpoint", "governance": "OpenAI, unilaterally, for the ChatGPT-specific extension layer (window.openai bridge, submission/review process); the underlying UI transport (MCP Apps) is co-governed via the modelcontextprotocol org, and OpenAI's documentation explicitly directs developers to prefer the shared MCP Apps standard over ChatGPT-specific extensions wherever it covers the need", "group": null, "history": [ { "date": "2026-09-05", "note": "seeded from Exa Agent research run" }, { "date": "2026-09-06", "note": "verified against developers.openai.com/apps-sdk (redirects to /plugins), developers.openai.com/plugins/concepts/mcp-server, developers.openai.com/plugins/build/chatgpt-ui, modelcontextprotocol.io/docs/extensions/apps; name changed to reflect OpenAI's Apps SDK -> Plugins rebrand" } ], "id": "openai-apps-sdk-manifests", "implementation": "shipping", "last_verified": "2026-09-06", "name": "OpenAI Plugins (formerly Apps SDK)", "native_status": "Active vendor product, rebranded from \"Apps SDK\" to \"Plugins\" as the top-level developers.openai.com section name (developers.openai.com/apps-sdk now redirects to developers.openai.com/plugins)", "origin": { "date": "2025-10", "org": "OpenAI" }, "part_of": null, "parties": [ "agent-site" ], "phase": "living", "probe": { "method": "POST", "on_absent": "no `_meta.ui.resourceUri`/`_meta[\"openai/outputTemplate\"]` on any tool: the plugin is tools-only with no custom UI (this is an explicitly supported, non-deficient configuration)", "parse": "a tool whose definition includes `_meta.ui.resourceUri` (or the ChatGPT compatibility alias `_meta[\"openai/outputTemplate\"]`) pointing to a `ui://` resource with mimeType `text/html;profile=mcp-app` indicates this plugin serves an MCP Apps-style interactive component; the tool list itself confirms a plugin/MCP server regardless of UI", "path": "{endpoint}/mcp (initialize, then tools/list)" }, "question": "How does a developer publish a tool with an optional interactive UI that ChatGPT and Codex can call?", "scope": "general", "spec_url": "https://developers.openai.com/plugins/concepts/mcp-server", "step": "act", "summary_md": "OpenAI's developer platform for extending ChatGPT and Codex — previously branded \"Apps SDK\" and now branded \"Plugins\" on developers.openai.com — lets a developer publish an MCP server (tools, and optionally resources/prompts) plus optional Skills and an optional interactive UI component that renders inside a ChatGPT conversation [1][2]. It solves the same problem the original 2023 ChatGPT Plugins tried to solve — third-party capability extension for a chat assistant — but rebuilt on top of MCP as the tool-calling transport instead of a bespoke OpenAPI-based manifest format, and on top of the open MCP Apps standard (rather than a proprietary iframe protocol) for the optional UI layer [2][3].\n\nA plugin is not required to have custom UI: OpenAI's own guidance is to \"keep the MCP tools useful without a component so ChatGPT and Codex can complete the workflow\" even when no UI renders [3]. When a plugin does return UI, the tool's `_meta.ui.resourceUri` field points at a `ui://` HTML resource that ChatGPT renders in a sandboxed iframe and communicates with over a `ui/*` JSON-RPC bridge via `postMessage` — this is the shared, portable MCP Apps mechanism, not something ChatGPT-specific [3]. OpenAI layers optional, ChatGPT-only extensions on top (`window.openai.requestCheckout`, file upload/selection, host-controlled modals, widget-state persistence) but explicitly instructs developers to prefer the shared MCP Apps field or method whenever one exists, providing a documented compatibility-alias table so integrations can use either [3].\n\nThis row does not cover general MCP server discovery or the MCP protocol itself (see the `mcp` record), and it does not cover the MCP Apps extension in general, which other MCP hosts besides ChatGPT also implement (Claude Desktop, VS Code Copilot, Microsoft 365 Copilot, Goose, and others) — MCP Apps may deserve its own row in a future pass rather than being folded entirely into this OpenAI-specific one, since it is not actually OpenAI-governed.\n\nThe most consequential change found in this verification: the product's public name changed. `developers.openai.com/apps-sdk` — the URL named in the task brief and the seed record's `spec_url` — now redirects to `developers.openai.com/plugins`; the entire documentation section is rebranded \"Plugins,\" with \"Apps SDK\" surviving only as the name of an optional component-styling library (`@openai/apps-sdk-ui`) [1]. This record's `id` (`openai-apps-sdk-manifests`) and `name` should be revisited in a future pass to reflect the new branding more fully (name updated here to \"OpenAI Plugins (formerly Apps SDK)\" with both terms kept as aliases); the `step` is correctly `act` since a plugin's primary function remains exposing callable tools, though the UI-manifest half of the original seed description now points mostly at the separate, W3C-adjacent-but-actually-MCP-governed MCP Apps standard. No adoption count (number of published plugins, install counts) was found in the pages checked, so adoption remains unmeasured.", "track": "single-vendor", "version": { "date": null, "label": "current, 2026 (unversioned docs; MCP Apps sub-standard dated 2026-01-26)" } }, { "acronym": "AAMP", "adoption": { "by": "IAB Tech Lab and named partners (AWS, HyperMindZ, Mixpeek, SafeGuard Privacy, Adform)", "level": "claimed", "probe_run": null }, "aliases": [], "analog": "no single classic-web analog; closest is an umbrella of OpenRTB/OpenDirect-style transaction protocols reworked for agent-to-agent negotiation", "collisions": [ "Agent Authorization Profile (also abbreviated AAP, IETF OAuth draft, unrelated)" ], "discovery": { "mechanism": "endpoint", "path": "https://registry.iabtechlab.ai/" }, "dispute": { "claims": [ "'AAMP 2.3' names a coordinated release of several independently-versioned repos, not a version of one document.", "Its Trust and Transparency pillar (Agent Registry) functions like an identity/disclosure directory, which arguably also belongs partly under this site's 'identify' step." ], "summary": "AAMP is not one protocol: it is a named umbrella for at least five separately-versioned repositories and three conceptually distinct pillars (execution via ARTF, which this site tracks as its own record under 'act'; negotiation/transaction via Agentic Direct and Agentic Audiences; and identity/disclosure via the Agent Registry, which overlaps with this site's 'identify' step). 'AAMP 2.3' is a marketing-level release label for the coalition's roadmap, not a single spec version that a probe can confirm end-to-end. This record is kept (per instructions, not withdrawn) but should be read as a program name whose most testable component (ARTF) already has its own row; readers wanting a single executable spec should look at ARTF, Agentic Direct or the Agent Registry individually." }, "evidence": [ { "claim": "IAB Tech Lab's AAMP standards page (last updated 2026-08-12) describes AAMP as an umbrella of three pillars -- Agent Foundations (ARTF), Agentic Protocols (Agentic Direct, Buyer/Seller Agent SDKs, Agentic Audiences fka UCP), and Trust and Transparency (the Agent Registry) -- and links five open-source GitHub repos plus the registry.", "date": "2026-08-12", "label": "VERIFIED", "url": "https://iabtechlab.com/standards/aamp-agentic-advertising-management-protocols/" }, { "claim": "IAB Tech Lab's 2026-07-30 press release announces AAMP 2.3, adding Amazon Bedrock AgentCore deployment, Meta buying, Google Ad Manager reporting, an IAB Diligence Platform/SafeGuard Privacy integration, and open-source contributions (Deals Sync MCP Server from HyperMindZ, Content Taxonomy Parser from Mixpeek); quotes named executives from AWS, SafeGuard Privacy, HyperMindZ, Mixpeek and Adform describing integration work.", "date": "2026-07-30", "label": "VERIFIED", "url": "https://iabtechlab.com/press-releases/iab-tech-lab-releases-aamp-2-3-bringing-enterprise-grade-infrastructure-and-privacy-diligence-to-agentic-advertising/" }, { "claim": "The AAMP GitHub hub repository lists five constituent repositories with independent semantic versioning per repo (Agentic Direct, Buyer Agent, Seller Agent, Registry Agent example, and ARTF), coordinated only via 'governance coordination' rather than a single version number.", "date": "2026-09-05", "label": "VERIFIED", "url": "https://github.com/IABTechLab/AAMP" } ], "form": "endpoint", "governance": "IAB Tech Lab (non-profit standards consortium); Agentic Task Force working group", "group": null, "history": [ { "date": "2026-09-05", "note": "seeded from Exa Agent research run" }, { "date": "2026-09-06", "note": "verified against iabtechlab.com/standards/aamp-agentic-advertising-management-protocols/, the 2026-07-30 AAMP 2.3 press release, and github.com/IABTechLab/AAMP; moved step from 'account' to 'coordinate'; flagged umbrella-program dispute and acronym collision with IETF AAP (Agent Authorization Profile)" } ], "id": "aamp", "implementation": "multi-implementation", "last_verified": "2026-09-06", "name": "Agentic Advertising Management Protocols", "native_status": "Active umbrella initiative, current release AAMP 2.3, described by its own authors as 'far more than a single framework'", "origin": { "date": "2025-10", "org": "IAB Tech Lab, Agentic Task Force" }, "part_of": null, "parties": [ "agent-agent" ], "phase": "living", "probe": { "method": "GET", "on_absent": "No registry entry for a company does not mean no AAMP deployment -- only that it has not self-registered.", "parse": "A response listing registered agents (buyer/seller/registry agents) indicates the IAB Tech Lab Agent Registry, AAMP's 'Trust and Transparency' pillar, is live; absence of a listing for a given company is not proof they lack an AAMP integration, since registration is voluntary.", "path": "https://registry.iabtechlab.ai/" }, "question": "How do a buyer's agent and a seller's agent discover each other's inventory, negotiate terms and hand off a transaction inside the existing ad-tech stack?", "scope": "advertising", "spec_url": "https://github.com/IABTechLab/AAMP", "step": "coordinate", "summary_md": "AAMP is IAB Tech Lab's umbrella name for its agentic-advertising program: how a buyer's agent and a seller's agent (and the platforms behind them) discover inventory, negotiate, and execute an advertising transaction using agent-to-agent workflows layered on existing ad-tech standards (OpenRTB, OpenDirect, AdCOM, the Deals API) [1]. This record has been moved from the site's original 'account' placement to 'coordinate' because its core, distinguishing content -- beyond ARTF, which already has its own record under 'act' -- is agent-to-agent negotiation and deal-making (Agentic Direct, Agentic Audiences, buyer/seller agent SDKs), not post-hoc recording or judgment of what happened.\n\n**What it is.** Three pillars: Agent Foundations (high-performance execution -- this is ARTF), Agentic Protocols (schemas and reference SDKs for buyer/seller agent discovery, negotiation and transacting), and Trust and Transparency (the free, IAB-run Agent Registry for agent identity and disclosure) [1]. AAMP 2.3, released 2026-07-30, added enterprise deployment paths (Amazon Bedrock AgentCore, Databricks), Meta buying support, Google Ad Manager reporting integration, embedded privacy diligence (IAB Diligence Platform, SafeGuard Privacy) inside the reference Buyer Agent, and open-source contributions from named partners HyperMindZ (a Deals Sync MCP Server) and Mixpeek (a Content Taxonomy Parser) [2].\n\n**What it does not do.** AAMP is not itself a single wire protocol: it has no one spec document or version number that a probe can confirm end-to-end. Its GitHub hub instead points to five separately-versioned repositories -- Agentic Direct, Buyer Agent, Seller Agent, a Registry Agent example, and ARTF -- aligned only through 'governance coordination,' not a shared release [3]. It does not define payment settlement (that sits with card-network specs like Verifiable Intent) and does not provide an independent audit-trail format of its own.\n\n**Current state.** Governed by IAB Tech Lab's Agentic Task Force, an open working group any member or non-member can join; AAMP 2.3 (2026-07-30) is the current named release, with named-executive quotes from AWS, SafeGuard Privacy, HyperMindZ, Mixpeek and Adform describing production integration work, though none of the fetched sources gives an independently countable adoption figure [1][2].\n\n**Who implements it.** IAB Tech Lab publishes open-source reference implementations for each pillar (Agentic Direct, Buyer Agent, Seller Agent SDKs; ARTF's Go and Rust servers); AWS supports AAMP on Bedrock AgentCore; HyperMindZ and Mixpeek have contributed named components.\n\n**Disputed / unknown.** Because AAMP names a coordinated program rather than one spec, 'AAMP 2.3 adoption' is not a single measurable quantity; adoption claims here are attributed to IAB Tech Lab and the named partner quotes, not independently verified counts. Readers evaluating whether a given ad-tech company 'supports AAMP' should ask which constituent repo/version they mean.", "track": "industry-body", "version": { "date": "2026-07-30", "label": "AAMP 2.3" } }, { "acronym": "ARTF", "adoption": { "by": "IAB Tech Lab", "level": "claimed", "probe_run": null }, "aliases": [ "agentic-rtb-framework" ], "analog": "a plugin/sidecar execution framework for real-time bidding -- closer to a serverless function contract than a classic-web analog", "collisions": [], "discovery": { "mechanism": "endpoint", "path": "http://{host}:{health-port}/health/ready" }, "dispute": null, "evidence": [ { "claim": "IAB Tech Lab announced ARTF v1.0 for public comment on 2025-11-13, open until 2026-01-15, describing a containerized architecture aiming to cut bid request/response time up to 80%; quotes from Index Exchange, Chalice and The Trade Desk describe early implementation work.", "date": "2025-11-13", "label": "VERIFIED", "url": "https://iabtechlab.com/press-releases/iab-tech-lab-announces-agentic-rtb-framework-artf-v1-0-for-public-comment/" }, { "claim": "The standards page (last modified 2026-08-12) says public comment ran until 2026-01-15 and links to the finalized v1.0 specification and sample code repositories.", "date": "2026-08-12", "label": "VERIFIED", "url": "https://iabtechlab.com/standards/artf/" }, { "claim": "IAB Tech Lab's 2026-08-12 milestone post says v1.0 'is now being used in production by various companies, including several of the organizations that helped design it,' adds a Rust reference implementation and an orchestration layer for chaining ARTF nodes, and states that v2.0 work has already begun -- without naming which companies are in production.", "date": "2026-08-12", "label": "VERIFIED", "url": "https://iabtechlab.com/a-milestone-for-the-agentic-advertising-ecosystem/" }, { "claim": "The GitHub repository's v1.0 tag/release was published 2026-07-20; the Go reference implementation exposes gRPC (port 50051), an MCP server (port 50052, or /mcp on the web-UI port), a web UI (8081) and Kubernetes health endpoints at /health/live and /health/ready (port 8080, default).", "date": "2026-07-20", "label": "VERIFIED", "url": "https://github.com/IABTechLab/agentic-real-time-framework" } ], "form": "endpoint", "governance": "IAB Tech Lab (non-profit standards consortium); Agentic Task Force working group", "group": null, "history": [ { "date": "2026-09-05", "note": "seeded from Exa Agent research run" }, { "date": "2026-09-06", "note": "verified against iabtechlab.com/standards/artf/, the 2025-11-13 launch press release, the 2026-08-12 milestone post, and github.com/IABTechLab/agentic-real-time-framework (README, internal/health, cmd/agent/main.go); moved step from 'account' to 'act'; filled probe, discovery, adoption=claimed" } ], "id": "artf", "implementation": "multi-implementation", "last_verified": "2026-09-06", "name": "Agentic Real Time Framework", "native_status": "Final v1.0 specification, published after public comment; v2.0 development already underway", "origin": { "date": "2025-11-13", "org": "IAB Tech Lab, Agentic Task Force" }, "part_of": null, "parties": [ "agent-site" ], "phase": "stable", "probe": { "method": "GET", "on_absent": "Connection refused or non-200 means no ARTF container is deployed at that host/port -- expected for the overwhelming majority of ad-tech origins, since ARTF nodes run inside a host platform's private infrastructure rather than being publicly addressable.", "parse": "HTTP 200 with the readiness handler's OK body indicates a running ARTF node (per internal/health in the Go reference implementation); a companion MCP tool 'extend_rtb' is exposed at {host}:8081/mcp and a gRPC RTBExtensionPoint.GetMutations service at port 50051.", "path": "http://{host}:8080/health/ready" }, "question": "How does a host advertising platform invoke a third party's agent service, deployed as a container inside its own infrastructure, to mutate a bid request in real time?", "scope": "advertising", "spec_url": "https://github.com/IABTechLab/agentic-real-time-framework", "step": "act", "summary_md": "ARTF defines how a host advertising platform (an SSP or DSP) can let a third party's agent service run inside the host's own infrastructure -- packaged as a container -- and be called directly to mutate an OpenRTB bid request in real time: fraud detection, bid shading, audience augmentation, viewability scoring and similar tasks [1][2]. It is the execution/runtime layer of IAB Tech Lab's broader AAMP advertising-agent program (see the separate AAMP record), specifically the piece that answers \"how does an agent invoke a capability inside someone else's system\" -- which is why this record has been moved from the site's original 'account' placement to 'act.' The framework standardizes container runtime behavior, a gRPC RTBExtensionPoint.GetMutations service, an MCP tool (extend_rtb) as an alternative interface for AI agents, and Kubernetes-style health endpoints, all built on existing infrastructure primitives (Kubernetes, Docker, Protobuf, gRPC) rather than inventing new transport [3][4].\n\n**What it does not do.** ARTF does not define agent identity or authentication (containers run inside the host's own trusted network, with no external network access by default), does not standardize commercial terms or negotiation (that is AAMP's Agentic Direct/Deals-API layer), and does not itself provide an audit trail beyond whatever the host platform's own logging does.\n\n**Current state.** IAB Tech Lab opened public comment on ARTF v1.0 on 2025-11-13, closing 2026-01-15 [1]. The finalized v1.0 specification and a Git tag were published 2026-07-20, with an accompanying Go reference implementation, and the project's own August 2026 recap describes v1.0 as already in production use by unnamed companies, several of whom helped design it, while adding a Rust reference implementation and cross-node orchestration; work on v2.0 was already underway at that point [2][3][4].\n\n**Who implements it.** IAB Tech Lab publishes an open-source Go reference server (gRPC + MCP + web UI + health checks) and, per the August 2026 post, a Rust reference implementation; the November 2025 launch quoted named ad-tech companies (Index Exchange, Chalice, The Trade Desk) describing implementation work, though none of those sources names a company as live in production as of the v1.0 release.\n\n**Disputed / unknown.** No independent, named list of production deployments exists in public sources; \"used in production by a number of companies\" is IAB Tech Lab's own claim, not something this site has measured. Because ARTF nodes are deployed inside a host's private infrastructure by design, there is no public origin to probe for adoption counting -- the probe above will almost always come back absent from the outside, which is expected behavior, not evidence of non-adoption.", "track": "industry-body", "version": { "date": "2026-07-20", "label": "v1.0" } }, { "acronym": "AdCP", "adoption": { "by": null, "level": "observed", "probe_run": null }, "aliases": [], "analog": "Ad-tech capability and transaction API", "collisions": [], "discovery": { "mechanism": "Publisher-side well-known file (adagents.json) declares authorized agent endpoints and capabilities; brand-side well-known file (brand.json) declares operator identity, agent endpoints, and signing-key discovery; a hosted Registry API additionally resolves brands/publishers to AdCP agents by capability, category, or geography", "path": "/.well-known/adagents.json (publisher) and /.well-known/brand.json (brand/operator)" }, "dispute": null, "evidence": [ { "claim": "AdCP is a project of AgenticAdvertising.org and coordinates the full ad campaign lifecycle (discovery, accounts, product/creative, media buy execution, real-time serve-time matching via the Trusted Match Protocol, signals/audiences, governance, performance tracking, catalog sync, brand protection) across two transport protocols, MCP and A2A. Current documented version is 3.1.20. adagents.json and brand.json are the two well-known discovery files; a hosted Registry API also resolves agents by capability. Client SDKs are published and versioned for JavaScript/TypeScript (npm @adcp/sdk), Python (PyPI adcp), and Go (github.com/adcontextprotocol/adcp-go); an open-source community example implementation, the Prebid Sales Agent, is built by a Prebid working group (explicitly a community example, not a maintained reference implementation) with GAM integration. Foundation governance (structure, voting classes, Board composition, specification lifecycle, conduct rules) is documented in the project's CHARTER.md and published at agenticadvertising.org/governance.", "date": "2026", "label": "VERIFIED", "url": "https://docs.adcontextprotocol.org/" }, { "claim": "AgenticAdvertising.org's own homepage (schema.org Organization markup) names itself 'the member organization pioneering a human-centric advertising future through Agentic AI,' founded 2025, and lists github.com/adcontextprotocol/adcp as its sameAs project repository, corroborating the docs site's governance claims from an independent page on the same organization's root domain.", "date": "2026", "label": "REPORTED", "url": "https://agenticadvertising.org" } ], "form": "well-known-file", "governance": "AgenticAdvertising.org, an industry organization of publishers, platforms, agencies, and technology providers; foundation governance (structure, voting classes, Board composition, spec lifecycle) is set out in the project's CHARTER.md and published at agenticadvertising.org/governance", "group": null, "history": [ { "date": "2026-09-05", "note": "seeded from Exa Agent research run" }, { "date": "2026-09-06", "note": "verified against docs.adcontextprotocol.org/dist/docs/3.1.20/intro" } ], "id": "adcp", "implementation": "shipping", "last_verified": "2026-09-06", "name": "Ad Context Protocol", "native_status": "Active open protocol, documented current release 3.1.20", "origin": { "date": "2025", "org": "AgenticAdvertising.org" }, "part_of": null, "parties": [ "agent-site", "agent-agent" ], "phase": "working-group", "probe": { "method": "GET", "on_absent": "404 or non-JSON response at /.well-known/adagents.json: the origin has not published AdCP publisher discovery (it may still run an AdCP agent without publishing the file, but that cannot be crawled)", "parse": "JSON body with `version`, `publisher.name`/`publisher.domain`, and an `agents[]` array of {url, protocol, capabilities}; a `get_adcp_capabilities` MCP/A2A call against a listed agent url confirms the endpoint actually speaks AdCP", "path": "{origin}/.well-known/adagents.json" }, "question": "How can an AI agent discover ad inventory, execute a media buy, sync creative, and report performance across many ad platforms through one protocol?", "scope": "advertising", "spec_url": "https://docs.adcontextprotocol.org/dist/docs/3.1.20/intro", "step": "act", "summary_md": "The Ad Context Protocol (AdCP) is an open standard, published by the industry organization AgenticAdvertising.org, that lets AI agents discover ad inventory, set up commercial relationships, plan and execute media buys, generate and distribute creative, activate targeting data, run governance checks, and report performance across many ad platforms through one set of tasks instead of a bespoke integration per platform [1]. It explicitly targets more than programmatic exchange: it covers direct deals, sponsorships, broadcast, and out-of-home, since most global ad spend still flows through non-programmatic channels [1].\n\nAdCP solves ad-tech's fragmentation problem for agentic buying: a media buyer's agent sends one natural-language brief via `get_products` to every connected seller and receives back a common schema (pricing, forecasts, targeting, creative requirements) instead of comparing incompatible dashboards; `create_media_buy` then executes across sellers in one call, and `get_media_buy_delivery` aggregates reporting the same way [1]. Publisher-side discovery runs through a well-known `adagents.json` file (analogous to `robots.txt`) declaring authorized agent endpoints and capabilities, and brand-side identity/authorization runs through `brand.json`; a hosted Registry API additionally resolves publishers and brands to their AdCP agents by capability, category, or geography for broader discovery beyond known domains [1]. Trust is handled structurally: requests are signed with RFC 9421 HTTP Message Signatures against operator-published JWKS, idempotency keys make retried writes safe, and governance approvals travel as signed JWS tokens so no intermediate agent can forge a human sign-off [1].\n\nAdCP does not itself run ad auctions or hold inventory — it is a transaction and coordination layer that sits on top of two existing agent-transport protocols, MCP (for AI-assistant tool calls) and A2A (for agent-to-agent collaboration), using the same task schemas over either transport [1]. It also does not claim every listed agent's capability claims are true by construction: the protocol ships compliance storyboards (a testable, runnable verification suite) precisely because claims otherwise would not be independently checkable [1].\n\nAs of this verification, the documented current release is 3.1.20, with published, versioned client SDKs for JavaScript/TypeScript, Python, and Go [1]. The one open-source implementation surfaced in the docs, the Prebid Sales Agent (Python backend, TypeScript protocol layer, GAM integration), is explicitly labeled a community example built by a Prebid working group rather than a maintained reference implementation — a caveat AdCP's own documentation states outright, which this record treats as direct evidence of at least one independent, named implementer rather than as proof of broad adoption [1]. Foundation-level governance (voting classes, Board composition, spec lifecycle) is documented in a public CHARTER.md, which is more governance transparency than many single-vendor competitors in this space disclose [1][2]. What remains unverified: no independent count of publishers actually serving `adagents.json` in production, nor of live AdCP agent endpoints, was located in this pass — that would need this project's own probe run before adoption could be upgraded from `observed` to `measured`.", "track": "industry-body", "version": { "date": "2026", "label": "3.1.20" } }, { "acronym": "TAP", "adoption": { "by": "Visa's own launch announcement, naming ecosystem participants including Cloudflare", "level": "claimed", "probe_run": null }, "aliases": [ "Trusted Agent Protocol" ], "analog": "Signed merchant/client verification layered on card-network trust", "collisions": [], "discovery": { "mechanism": "Signed HTTP headers/body during browsing and payment interactions, verified against Visa's Public Keys Retrieval Service", "path": "/keys" }, "dispute": { "claims": [ "Visa's own text frames TAP as complementary to, not a replacement for, bilateral merchant-agent agreements and other bot-detection signals (user-agent headers, IP allow-listing, registries)." ], "summary": "TAP is a single-vendor (Visa) specification, not an open standard; it is designed for the two-sided scenario where the agent is initially unknown to the merchant, and is explicitly scoped to commerce (browsing and payment interactions), unlike the general-purpose Web Bot Auth." }, "evidence": [ { "claim": "Visa's launch announcement introduces the Trusted Agent Protocol as an ecosystem-led framework for AI commerce, naming participating partners", "date": "2025-10-14", "label": "VERIFIED", "url": "https://investor.visa.com/news/news-details/2025/Visa-Introduces-Trusted-Agent-Protocol-An-Ecosystem-Led-Framework-for-AI-Commerce/default.aspx" }, { "claim": "Visa's merchant specification defines a Public Key Retrieval operation (GET /keys with a keyID parameter, returning a JWK) used to verify agent-recognition signatures and a Visa-signed ID Token compliant with RFC 7519/7515", "date": "2026-09-06", "label": "VERIFIED", "url": "https://developer.visa.com/capabilities/trusted-agent-protocol/trusted-agent-protocol-specifications" } ], "form": "http-header", "governance": "Visa (single-vendor specification, published for merchant/developer adoption)", "group": null, "history": [ { "date": "2026-09-05", "note": "seeded from Exa Agent research run" }, { "date": "2026-09-06", "note": "verified against Visa's live merchant specification page and the 2025-10-14 launch announcement" } ], "id": "tap", "implementation": "prototype", "last_verified": "2026-09-06", "name": "Visa Trusted Agent Protocol", "native_status": "Active vendor-led merchant specification", "origin": { "date": "2025-10", "org": "Visa (with Cloudflare as an early ecosystem participant)" }, "part_of": null, "parties": [ "agent-site", "agent-payment" ], "phase": "candidate", "probe": { "method": "GET", "on_absent": "The referenced key cannot be retrieved, so the agent-recognition signature or Visa ID Token cannot be verified", "parse": "200 response body is a JWK object (kty, kid, use, alg, and RSA/EC key material) matching the keyID used to sign the agent's request or the Visa-issued ID Token", "path": "https://{tap-key-service}/keys?keyID={kid}" }, "question": "How does a merchant recognize that an approved commerce agent, rather than a crawler or fraudulent bot, is interacting with its site or API?", "scope": "commerce", "spec_url": "https://developer.visa.com/capabilities/trusted-agent-protocol/trusted-agent-protocol-specifications", "step": "identify", "summary_md": "Visa's Trusted Agent Protocol (TAP) lets a merchant recognize that an \"approved agent with commerce intent\" — rather than a scraper, reseller bot, or attacker — is interacting with its website or API, and lets the merchant request additional information (payment, consumer email) back from that agent [1]. It is designed specifically for the case where the agent is not already known to the merchant through a bilateral agreement: instead of user-agent strings, IP allow-lists, approved-agent registries, or shared keys, TAP carries linked, verifiable, purpose-identifying, time-bound signed credentials in the request headers or body [2].\n\nIt solves agent recognition across two specific interaction types: a browsing interaction (an agent, acting for a consumer with commerce intent, checks product availability, size/color and final cost) and a payment interaction (the agent supplies everything needed to complete a purchase or gain paid access to a merchant resource) [2]. Verification relies on a Visa-run Public Keys Retrieval Service (`GET /keys`, returning a JWK by keyID) and a Visa-issued ID Token — a JWT compliant with RFC 7519, signed per RFC 7515, carrying standard and Visa-private claims [2]. It does not replace existing bot-detection signals — Visa's own text frames it as one more, more efficient, signal merchants can choose to check, and any of these signatures can simply be ignored by merchants that have not adopted TAP [2]. It is also explicitly scoped to commerce, unlike the general-purpose Web Bot Auth; the two overlap conceptually (both sign HTTP requests to prove client identity) but serve different scopes and are governed by different parties.\n\nCurrent state: launched by Visa on 2025-10-14 as an \"ecosystem-led framework for AI commerce,\" naming early partners [1]. As of this check (2026-09-06) Visa Developer publishes a full merchant specification covering the trust model, agent recognition signature, consumer recognition, contextual data, payment object, card metadata, credential hashing, and the ID Token format [2] — this is a live, vendor-maintained document rather than a versioned, dated standard.\n\nWho implements it: Visa (issuer of the ID Token and key service) and named ecosystem participants from the 2025 launch, including Cloudflare per the earlier seed research (not independently re-verified as an implementer of this exact spec in this pass). No independent, non-Visa implementation was confirmed here.\n\nDisputed or unknown: because this is a single-vendor specification without a formal versioning scheme visible on the page, dating a specific \"current version\" is not possible from the page alone; whether other card networks will adopt a compatible or competing scheme is unresolved.", "track": "single-vendor", "version": { "date": null, "label": "Current merchant specification, 2026, published on Visa Developer" } }, { "acronym": "VI", "adoption": { "by": null, "level": "unmeasured", "probe_run": null }, "aliases": [], "analog": "a verifiable-credential audit trail for a single transaction's chain of consent -- closest classic-web analog is a signed receipt plus consent log", "collisions": [], "discovery": { "mechanism": "none", "path": null }, "dispute": null, "evidence": [ { "claim": "Mastercard's 2026-03-05 story, co-authored with a Google Payments VP quote, introduces Verifiable Intent as a standards-based trust layer for agentic commerce, aligned with Google's AP2 and UCP, and says Mastercard is 'open-sourcing the Verifiable Intent specification and an initial reference implementation' on GitHub and at verifiableintent.dev; integration into Mastercard Agent Pay's intent APIs is described as forthcoming, not live.", "date": "2026-03-05", "label": "VERIFIED", "url": "https://www.mastercard.com/global/en/news-and-trends/stories/2026/verifiable-intent.html" }, { "claim": "The public specification (version 0.1-draft, dated 2026-02-18) defines a layered SD-JWT credential format binding credential provider, user and agent through key-confirmation claims, with Immediate and Autonomous execution modes and selective disclosure per role.", "date": "2026-02-18", "label": "VERIFIED", "url": "https://verifiableintent.dev/spec/" }, { "claim": "The GitHub repository README describes VI's status as 'Draft (v0.1). Maintained by Mastercard; open to multi-stakeholder contribution,' and lists transport protocols, key management, credential-provider enrollment, agent-platform APIs and dispute resolution as explicitly out of scope for the spec.", "date": "2026-09-05", "label": "VERIFIED", "url": "https://github.com/agent-intent/verifiable-intent" } ], "form": "document-format", "governance": "Maintained by Mastercard; open to multi-stakeholder contribution per the project's CONTRIBUTING.md; built on FIDO Alliance, EMVCo, IETF and W3C primitives (SD-JWT/RFC 9901, key confirmation/RFC 7800)", "group": null, "history": [ { "date": "2026-09-05", "note": "seeded from Exa Agent research run" }, { "date": "2026-09-06", "note": "verified against mastercard.com/.../verifiable-intent.html (via firecrawl, curl 403s), verifiableintent.dev/spec/, and github.com/agent-intent/verifiable-intent README and spec/credential-format.md; corrected version date to 2026-02-18, origin.date to 2026-03-05, governance and scope; kept step=account" } ], "id": "vi", "implementation": "prototype", "last_verified": "2026-09-06", "name": "Verifiable Intent", "native_status": "Draft (v0.1); open-sourced specification and reference implementation", "origin": { "date": "2026-03-05", "org": "Mastercard, co-developed with Google" }, "part_of": null, "parties": [ "agent-payment" ], "phase": "draft", "probe": { "method": "GET", "on_absent": "Expected in nearly all cases today: VI has not defined a well-known discovery path, and Mastercard states integration into Mastercard Agent Pay's intent APIs is still 'in the coming months' as of the 2026-03-05 announcement.", "parse": "Non-normative: the VI specification does not define a discovery mechanism (transport, agent-platform APIs and credential-provider enrollment are explicitly out of scope). This checks a plausible-but-unofficial convention only; a real signal of VI usage is the presence of an SD-JWT credential in a checkout flow with header typ 'kb-sd-jwt' (Immediate/Autonomous modes) or 'sd+jwt' (L1), and vct 'https://credentials.mastercard.com/card' for the Mastercard reference profile.", "path": "{merchant_origin}/.well-known/verifiable-intent" }, "question": "After an agent completes a purchase on a user's behalf, can the merchant, issuer and consumer all point to the same cryptographic record of what the user actually authorized?", "scope": "payments", "spec_url": "https://verifiableintent.dev/spec/", "step": "account", "summary_md": "Verifiable Intent (VI) is a credential format -- not a network protocol -- that creates a tamper-evident, cryptographic chain of who authorized what when an AI agent makes a purchase on a person's behalf: a credential provider (bank or card network) signs an identity layer (L1), the user's wallet signs a layer binding specific constraints such as amount range, allowed merchants or line items (L2), and, in 'Autonomous' mode, the agent's own key is bound into a further layer (L3) before it acts without the user present [2][3]. Selective disclosure (SD-JWT, per IETF RFC 9901) means a merchant, issuer or agent platform each sees only the claims relevant to their role. This is squarely an 'account' spec in this site's sense: its entire purpose is producing a record that can be checked after the fact -- if a dispute arises, all parties can point to the same signed chain rather than reconstructing intent from logs [1].\n\n**What it solves.** Before VI, a merchant accepting an agent-initiated purchase has no standard way to prove the user actually authorized that specific transaction, and issuers cannot cleanly separate legitimate agent purchases from fraud. VI gives all parties a shared, privacy-preserving evidence trail [1].\n\n**What it does not do.** VI does not define transport protocols, key management/provisioning, credential-provider enrollment, agent-platform APIs, dispute-resolution process, or regulatory-compliance mapping -- all explicitly out of scope in the spec itself [3]. It has no discovery mechanism (no well-known path, no registry); a merchant currently has to know out-of-band that a given credential provider or agent supports it.\n\n**Current state.** Announced 2026-03-05 by Mastercard with a co-authorship/quote from Google's VP of Payments, positioned as complementary to Google's Agent Payments Protocol (AP2) and Universal Commerce Protocol (UCP) [1]. The public specification is version 0.1-draft, dated 2026-02-18 [2]. As of the announcement, Mastercard describes integration into its own Agent Pay intent APIs as forthcoming ('in the coming months'), not yet live, and the GitHub repository is explicitly labelled Draft (v0.1) [1][3].\n\n**Who implements it.** Mastercard has published an initial reference implementation alongside the specification. Quoted partners in the launch material -- Google, Adyen, Basis Theory, Checkout.com, Getnet, Fiserv, IBM and Worldpay/Global Payments -- describe alignment or planned integration, but none of the fetched sources documents a live, independent production implementation outside Mastercard's own reference code, so implementation is marked 'prototype' rather than 'shipping' or 'multi-implementation.'\n\n**Disputed / unknown.** No adoption count exists; this record marks adoption 'unmeasured' rather than 'claimed' because no single source stated a specific number of live integrations. Whether VI becomes a true multi-network standard or remains Mastercard-centric (the Mastercard reference credential profile, vct 'https://credentials.mastercard.com/card,' is the only concretely specified profile) is unresolved.", "track": "vendor-consortium", "version": { "date": "2026-02-18", "label": "0.1-draft" } }, { "acronym": "SPIFFE", "adoption": { "by": "SPIFFE's own ecosystem page lists SPIRE, cert-manager, Consul, Dapr, Istio as open-source implementers and GCP, Teleport, Palo Alto Networks/Idira, Red Hat, Defakto, Cofide and Greymatter.io as commercial implementers — none of this is agent-specific adoption", "level": "observed", "probe_run": null }, "aliases": [ "Secure Production Identity Framework for Everyone" ], "analog": "Workload-scoped X.509/mTLS or JWT identity, analogous to per-service TLS certs", "collisions": [], "discovery": { "mechanism": "Local Workload API (a Unix domain socket, not a network-reachable endpoint) issues short-lived X.509-SVID or JWT-SVID identity documents to an attested workload", "path": "none" }, "dispute": { "claims": [ "It is not yet established whether the SPIFFE project itself will adopt an agent-specific profile, or whether this remains solely the proposal of the outside aiagent-auth draft." ], "summary": "SPIFFE itself is not an agent-specific standard — it is a general workload-identity framework. Its relevance to this map comes entirely from a separate, non-SPIFFE-governed IETF individual draft that proposes profiling SPIFFE (and WIMSE) for AI agents." }, "evidence": [ { "claim": "SPIFFE is a CNCF set of open-source specifications for issuing short-lived cryptographic workload identities (SVIDs) via a local Workload API; its own overview and ecosystem pages describe general workload identity for services, not AI agents specifically", "date": null, "label": "VERIFIED", "url": "https://spiffe.io/docs/latest/spiffe-about/overview/" }, { "claim": "The IETF individual draft \"AI Agent Authentication and Authorization\" (draft-klrc-aiagent-auth-03, authored by engineers from Defakto, AWS, Zscaler, Ping Identity, OpenAI and Okta) proposes applying SPIFFE/WIMSE and OAuth 2.0 to AI-agent authentication, rather than defining new protocols", "date": "2026-07-06", "label": "VERIFIED", "url": "https://www.ietf.org/ietf-ftp/internet-drafts/draft-klrc-aiagent-auth-03.html" } ], "form": "endpoint", "governance": "CNCF (SPIFFE is a graduated CNCF project); the AI-agent profile is governed separately as an IETF individual draft, not by the SPIFFE project itself", "group": null, "history": [ { "date": "2026-09-05", "note": "seeded from Exa Agent research run" }, { "date": "2026-09-06", "note": "verified against spiffe.io's own overview/ecosystem page and draft-klrc-aiagent-auth-03; corrected framing to make clear SPIFFE itself is agent-agnostic and the agent application is an outside proposal" } ], "id": "spiffe", "implementation": "multi-implementation", "last_verified": "2026-09-06", "name": "SPIFFE (Secure Production Identity Framework for Everyone)", "native_status": "Active, stable open-source specification set (SPIFFE/SPIRE); SPIFFE itself makes no agent-specific claims", "origin": { "date": null, "org": "SPIFFE project (CNCF-graduated); AI-agent application profiled separately by IETF individual draft authors" }, "part_of": null, "parties": [ "agent-site" ], "phase": "stable", "probe": { "method": "n/a (local IPC, not remotely probable)", "on_absent": "No SPIFFE identity is available to the workload; it cannot present an SVID for mTLS or JWT-based authentication", "parse": "Workload API FetchX509SVID/FetchJWTSVID response contains a SPIFFE ID (spiffe://trust-domain/path) and a short-lived SVID", "path": "unix:///run/spire/sockets/agent.sock (SPIRE's default; not part of the SPIFFE spec itself)" }, "question": "Which workload instance — potentially including an AI agent process — is making this request, verifiable independent of network location?", "scope": "general", "spec_url": "https://spiffe.io/docs/latest/spiffe-about/overview/", "step": "identify", "summary_md": "SPIFFE (Secure Production Identity Framework for Everyone) is a CNCF-graduated set of open-source specifications for issuing short-lived, cryptographic identity documents (SVIDs — SPIFFE Verifiable Identity Documents, either X.509 or JWT) to software workloads via a local Workload API, so that services can mutually authenticate across dynamic, heterogeneous infrastructure without relying on network location [1]. It is included in this map's Identify layer because an active IETF individual draft proposes applying it — alongside WIMSE and OAuth 2.0 — to AI-agent authentication specifically [2].\n\nIt solves workload-to-workload mutual authentication at scale: instead of IP-based network policies, each workload instance attests to a SPIRE server (or another SPIFFE-compliant issuer) and receives a short-lived, automatically rotated identity bound to a `spiffe://trust-domain/path` name [1]. What it does not do is anything agent-specific by itself: the SPIFFE specification and its own documentation make no claims about AI agents, delegation from a human principal, or any of the semantics an autonomous-agent identity system would need beyond \"this is workload X.\" That gap is what the separate draft-klrc-aiagent-auth draft (co-authored by engineers from Defakto, AWS, Zscaler, Ping Identity, OpenAI and Okta) attempts to address by describing how SPIFFE and WIMSE identities, combined with OAuth 2.0 token exchange, could carry an agent's identity and a delegation chain from its human or organizational principal — without SPIFFE itself defining any new protocol for this [2].\n\nCurrent state: SPIFFE's core specifications (SPIFFE ID, X509-SVID, JWT-SVID, Workload API, Federation) are stable and have been for years; SPIFFE and its reference implementation SPIRE are both CNCF-graduated projects. The AI-agent application is at draft-klrc-aiagent-auth-03 (July 2026), an Informational individual draft under the IETF Network Working Group umbrella, not a SPIFFE-project deliverable [2].\n\nWho implements it: SPIFFE's own ecosystem page lists SPIRE, cert-manager, Consul, Dapr and Istio as open-source implementers, and GCP, Teleport, Palo Alto Networks (Idira), Red Hat, Defakto, Cofide and Greymatter.io as commercial implementers of the general workload-identity spec [1] — none of this reflects AI-agent-specific deployment.\n\nDisputed or unknown: whether SPIFFE will formally adopt an agent identity profile, versus this remaining an outside proposal layered on top of it, is unresolved. No production system was found in this pass actually issuing SPIFFE SVIDs to AI agents specifically (as opposed to conventional microservice workloads).", "track": "linux-foundation", "version": { "date": null, "label": "SPIFFE core specs (SPIFFE ID, X509-SVID, JWT-SVID, Workload API) are stable and versioned independently; the AI-agent profile is draft-klrc-aiagent-auth-03, published 2026-07-06" } }, { "acronym": "WIMSE", "adoption": { "by": null, "level": "unmeasured", "probe_run": null }, "aliases": [ "Workload Identity in a Multi System Environment" ], "analog": "Cross-domain workload identity and token-exchange architecture", "collisions": [], "discovery": { "mechanism": "Workload identity issuance and cross-trust-domain token exchange (architecture defines roles and flows; concrete wire mechanics are in sibling WIMSE WG documents)", "path": "none" }, "dispute": { "claims": [ "This architecture document alone does not define a probeable wire protocol; the concrete mechanics live in sibling WIMSE WG drafts not reviewed here." ], "summary": "Like SPIFFE, WIMSE is a general workload-identity architecture; its relevance to agent identity comes from a separate, unaffiliated IETF individual draft that proposes applying it to AI agents. Unlike the Signature Agent Card, WIMSE IS a chartered-WG document, giving it a firmer governance footing than several other records in this step." }, "evidence": [ { "claim": "WIMSE architecture draft-ietf-wimse-arch is an active WG Document of the IETF wimse Working Group, RFC stream IETF, currently at revision -08 (last updated 2026-07-06), replacing the earlier individual draft-salowey-wimse-arch", "date": "2026-07-06", "label": "REPORTED", "url": "https://datatracker.ietf.org/doc/draft-ietf-wimse-arch/08/" }, { "claim": "The IETF individual draft on AI-agent authentication (draft-klrc-aiagent-auth-03) explicitly proposes using the WIMSE architecture, alongside SPIFFE and OAuth 2.0, as the basis for agent authentication rather than defining new protocols", "date": "2026-07-06", "label": "VERIFIED", "url": "https://www.ietf.org/ietf-ftp/internet-drafts/draft-klrc-aiagent-auth-03.html" } ], "form": "endpoint", "governance": "IETF wimse Working Group (chartered WG; RFC stream IETF)", "group": null, "history": [ { "date": "2026-09-05", "note": "seeded from Exa Agent research run" }, { "date": "2026-09-06", "note": "verified against draft-ietf-wimse-arch-08's datatracker status page, confirming chartered WG status and 2026-07-06 update" } ], "id": "wimse", "implementation": "prototype", "last_verified": "2026-09-06", "name": "Workload Identity in Multi System Environments (WIMSE) Architecture", "native_status": "Active Internet-Draft, WG Document, Intended Status: Informational", "origin": { "date": "2024-03", "org": "J. Salowey (Palo Alto Networks), Y. Rosomakho (Zscaler), H. Tschofenig (UniBw M.)" }, "part_of": null, "parties": [ "agent-site" ], "phase": "working-group", "probe": { "method": "n/a", "on_absent": "Absence of a site artifact means nothing; WIMSE governs workload-to-workload identity, not a site-facing endpoint.", "parse": "n/a", "path": "n/a (workload identity architecture; no fixed origin artifact)" }, "question": "How do workloads — including, per a related draft, AI agents — authenticate to each other and to services across platforms and trust domains?", "scope": "general", "spec_url": "https://datatracker.ietf.org/doc/draft-ietf-wimse-arch/", "step": "identify", "summary_md": "WIMSE (Workload Identity in Multi System Environments) is an IETF architecture for how software workloads authenticate to each other and to services when they span multiple platforms, cloud providers, or trust domains — a scope broader than SPIFFE's original single-organization workload identity model [1]. It is relevant to the Identify layer of this map because a separate IETF individual draft on AI-agent authentication explicitly proposes using WIMSE (together with SPIFFE and OAuth 2.0) as the basis for how an agent authenticates, rather than inventing a new agent-specific protocol [2].\n\nIt solves cross-domain workload authentication architecture: defining the roles, trust relationships and token-exchange flows needed when a workload in one organization's environment needs to prove its identity to a service in another's. It does not itself define a single concrete wire protocol usable end to end — as an architecture document, its concrete mechanics (issuance formats, token exchange endpoints) are specified in sibling documents produced by the same WIMSE Working Group, which this pass did not review in depth. It also makes no agent-specific claims on its own; \"AI agent\" does not appear to be native vocabulary of the WIMSE WG's charter as reviewed here — the agent application again comes from the outside aiagent-auth draft.\n\nCurrent state: this is a genuine chartered IETF Working Group document — draft-ietf-wimse-arch, currently at revision -08, last updated 2026-07-06, on the IETF RFC stream — which gives it firmer standards-track footing than several of the individual-submission drafts elsewhere in this map [1]. It replaces the authors' earlier individual submission, draft-salowey-wimse-arch, first published in March 2024 [1].\n\nWho implements it: no concrete implementation was verified in this pass; the wimse WG maintains its work in a public GitHub organization (ietf-wg-wimse) referenced from the datatracker page [1], but this check did not survey deployed implementations.\n\nDisputed or unknown: whether or when WIMSE will produce a companion document specifically profiling AI agents (as opposed to the outside aiagent-auth draft doing so unofficially), and what concrete, probeable endpoint the architecture resolves to in practice, are both open.", "track": "ietf", "version": { "date": "2026-07-06", "label": "draft-ietf-wimse-arch-08, last updated 2026-07-06 (supersedes draft-salowey-wimse-arch, first published 2024-03)" } }, { "acronym": "AAuth", "adoption": { "by": null, "level": "unmeasured", "probe_run": null }, "aliases": [], "analog": "OAuth Device Authorization Grant", "collisions": [], "discovery": { "mechanism": "OAuth 2.1 extension grant flow; no well-known file defined", "path": null }, "dispute": { "claims": [ "IETF Datatracker document state: Expired Internet-Draft" ], "summary": "The draft is expired per the IETF Datatracker's own document-state field, and no independent implementation was found; it is retained here as a documented proposal rather than an active spec." }, "evidence": [ { "claim": "draft-rosenberg-oauth-aauth defines an OAuth 2.1 extension letting an AI agent collect PII conversationally (over PSTN or texting, where redirect-based OAuth is unavailable) and exchange it for a scope-constrained access token, with an explicit goal of preventing LLM-hallucination-driven impersonation.", "date": "2025-10-19", "label": "VERIFIED", "url": "https://datatracker.ietf.org/doc/html/draft-rosenberg-oauth-aauth" }, { "claim": "The raw draft-00 HTML text hosted at ietf.org/archive (distinct from the Datatracker's metadata/history page) confirms the same abstract, scope (PSTN/texting channels, PII-collection flow, anti-impersonation goal) and lets the Datatracker's 'Expired' state be cross-checked against the actual spec content rather than taken on the metadata page alone.", "date": "2025-10-19", "label": "VERIFIED", "url": "https://www.ietf.org/archive/id/draft-rosenberg-oauth-aauth-00.html" } ], "form": "endpoint", "governance": "IETF individual Internet-Draft (OAuth-adjacent, not yet adopted by the OAuth Working Group as of this verification)", "group": null, "history": [ { "date": "2026-09-05", "note": "seeded from Exa Agent research run" }, { "date": "2026-09-06", "note": "verified against datatracker.ietf.org/doc/html/draft-rosenberg-oauth-aauth; found expired" } ], "id": "aauth", "implementation": "none-found", "last_verified": "2026-09-06", "name": "Agent Authorization Grant", "native_status": "Internet-Draft, individual submission; page marked \"Expired\" by the IETF Datatracker", "origin": { "date": "2025-10", "org": "IETF individual submission" }, "part_of": null, "parties": [ "agent-site" ], "phase": "withdrawn", "probe": { "method": "POST", "on_absent": "Authorization server does not implement this grant; this is expected, since the draft is expired and no implementation was found", "parse": "A 200 response containing an access_token issued via the collected-PII flow described in the draft", "path": "{authorization_server}/token with grant_type indicating the Agent Authorization Grant (exact grant_type string not fixed in the draft text reviewed)" }, "question": "How can a conversational AI agent, reached over a channel without browser redirect (phone, SMS), obtain a properly scoped OAuth access token without impersonating the user?", "scope": "general", "spec_url": "https://datatracker.ietf.org/doc/html/draft-rosenberg-oauth-aauth", "step": "permit", "summary_md": "The Agent Authorization Grant (AAuth) is an individual IETF Internet-Draft, draft-rosenberg-oauth-aauth-00, dated 2025-10-19, proposing an OAuth 2.1 extension for a specific class of AI agent: one reached through a channel that does not support browser-redirect OAuth flows, such as a phone call over the PSTN or SMS texting [1]. It solves a narrow but real permit-adjacent problem — authorization, not content-use permission — for voice/text-only conversational agents.\n\nIn the flow it describes, the agent collects personally identifying information from the user through natural-language conversation, then presents that collected PII to obtain an access token with an appropriately constrained scope, rather than redirecting the user to a login page it cannot render over a phone call. The draft's stated primary concern is architectural: ensuring that LLM hallucination inside the agent cannot itself cause an impersonation attack against the authorization flow [1].\n\nIt does not define a well-known discovery file, a permission vocabulary, or content-use semantics — it is purely an authorization-grant flow, adjacent to this wiki's 'identify' and 'permit' steps rather than a pure fit for either. It does not specify a concrete `grant_type` string or endpoint schema in enough detail in the sections reviewed to build an executable, generic probe; a probe would need to be implementation-specific.\n\nAs of this verification (2026-09-06), the IETF Datatracker page for this draft shows its document state as an expired Internet-Draft; IETF drafts lapse automatically after roughly six months without a new revision, and no successor version beyond -00 was found. No independent implementation, reference server, or adopting product was located during this pass, so implementation is recorded as none-found rather than prototype. Given the expired status and absence of any implementation or successor draft, this record's phase is set to withdrawn: the proposal exists as a documented idea but has not advanced and appears inactive.\n\nWhat is unresolved: whether the author (Jonathan Rosenberg) or another party intends to revive this line of work, and whether its PII-collection-then-token-exchange pattern will instead be absorbed into a more general draft such as DAAP or AAP, which address overlapping agent-authorization ground within the same OAuth ecosystem.", "track": "ietf", "version": { "date": "2025-10-19", "label": "draft-rosenberg-oauth-aauth-00" } }, { "acronym": "DAAP", "adoption": { "by": null, "level": "unmeasured", "probe_run": null }, "aliases": [ "Delegated Agent Authorization Protocol", "draft-mishra-oauth-agent-grants" ], "analog": "OAuth delegated grant / consent screen", "collisions": [], "discovery": { "mechanism": "Standard OAuth 2.0 authorization/token endpoints; discovery via RFC 8414 Authorization Server Metadata (no new endpoints defined)", "path": "/.well-known/oauth-authorization-server" }, "dispute": null, "evidence": [ { "claim": "draft-mishra-oauth-agent-grants-02 defines an OAuth profile for agent-client identification, user consent, resource-bound sender-constrained tokens, authority attenuation via RFC 8693 Token Exchange, and safe refresh-token rotation, using only existing OAuth/JOSE mechanisms and defining no new claims or endpoints. The draft names 'Grantex' as an incomplete, non-conformance-required reference implementation, distinguishing it from a production deployment.", "date": "2026-08", "label": "VERIFIED", "url": "https://datatracker.ietf.org/doc/html/draft-mishra-oauth-agent-grants-02" }, { "claim": "The IETF Datatracker's document page for draft-mishra-oauth-agent-grants confirms it as an Active Internet-Draft (individual submission) with no working-group affiliation shown, corroborating the draft text's own self-description.", "date": "2026-08", "label": "REPORTED", "url": "https://datatracker.ietf.org/doc/draft-mishra-oauth-agent-grants/" } ], "form": "endpoint", "governance": "IETF individual Internet-Draft (OAuth-adjacent; not yet adopted by the OAuth Working Group as of this verification)", "group": null, "history": [ { "date": "2026-09-05", "note": "seeded from Exa Agent research run" }, { "date": "2026-09-06", "note": "verified against datatracker.ietf.org/doc/html/draft-mishra-oauth-agent-grants-02; corrected name from seed" } ], "id": "daap", "implementation": "prototype", "last_verified": "2026-09-06", "name": "OAuth Profile for Delegated AI Agent Authorization", "native_status": "Internet-Draft, individual submission, Active", "origin": { "date": "2026-02", "org": "IETF individual submission" }, "part_of": null, "parties": [ "agent-site" ], "phase": "draft", "probe": { "method": "GET", "on_absent": "Authorization server does not advertise the OAuth building blocks (Token Exchange, sender-constrained tokens) DAAP requires; this alone does not prove DAAP is unused, since DAAP defines no unique discoverable marker", "parse": "Presence of Token Exchange (RFC 8693) grant support and sender-constraining (DPoP/mTLS) in the advertised grant_types_supported / token_endpoint_auth_methods_supported, as DAAP composes these existing mechanisms rather than adding new ones", "path": "{authorization_server}/.well-known/oauth-authorization-server" }, "question": "How can a human user delegate constrained, attenuable, revocable authority to an AI agent using standard OAuth mechanisms, with no new endpoints or claims required?", "scope": "general", "spec_url": "https://datatracker.ietf.org/doc/html/draft-mishra-oauth-agent-grants-02", "step": "permit", "summary_md": "This record, seeded under the id `daap` and the name 'Delegated Agent Authorization Protocol', is the IETF individual Internet-Draft draft-mishra-oauth-agent-grants, whose own title is 'OAuth Profile for Delegated AI Agent Authorization' — the seed's acronym and description matched a real, verifiable draft, but the name carried by the seed record does not appear in the document text itself; 'Delegated Agent Authorization Protocol' and 'DAAP' are recorded here as aliases rather than the primary name, which has been corrected to the draft's actual title [1].\n\nThe draft addresses AI agents that invoke protected APIs on behalf of a human user. It defines an OAuth profile covering: identifying an agent client instance distinctly from the user's own client, obtaining the user's authenticated consent, issuing access tokens that are both resource-bound (audience-restricted) and sender-constrained (bound to the agent's key), attenuating an agent's authority through RFC 8693 OAuth Token Exchange, and rotating refresh tokens safely [1]. Its central design constraint, stated in its own abstract, is that it 'defines no new JWT claims or OAuth endpoints' — it is explicitly a profile of composition over existing IETF mechanisms (OAuth 2.0/2.1, Token Exchange, JOSE, DPoP-style sender constraints), not a new protocol.\n\nIt explicitly places operational concerns — policy engines, audit stores, spending budgets, event streams, credential vaults — outside its interoperable core, leaving those to implementers. It does not define content-use or crawling permissions; its scope is strictly delegated API-calling authority, positioning it as a 'permit' record specifically for the agent-site API-invocation case, adjacent to AAP and AAuth.\n\nAs of this verification (2026-09-06), the current version is -02, and the Datatracker's own document-state field shows it Active (not expired) with a last-updated date in the 2026-08 range, and an expiry of 3 March 2027 — confirming it is a live, in-progress draft rather than lapsed [1][2]. The draft names 'Grantex' as an incomplete reference implementation, explicitly stating conformance does not require it, so implementation is recorded as prototype rather than shipping [1].\n\nWhat is unresolved: whether this draft will be adopted by the IETF OAuth Working Group as a formal work item (it is currently an individual submission), how it will be reconciled with the overlapping AAP and AAuth proposals covering similar agent-delegation ground within the same working group's orbit, and whether any production authorization server has implemented its specific attenuation/rotation profile beyond the Grantex reference code.", "track": "ietf", "version": { "date": "2026-08", "label": "draft-mishra-oauth-agent-grants-02" } }, { "acronym": "AAP", "adoption": { "by": null, "level": "unmeasured", "probe_run": null }, "aliases": [], "analog": "OAuth profile / scoped service-account token", "collisions": [ "AAP also collides with the unrelated Automated Access Point / Advanced Authoring Program acronyms in other domains", "Agent Attribution Protocol (AAP)" ], "discovery": { "mechanism": "OAuth 2.0 authorization-server metadata plus structured JWT claims; no dedicated well-known file defined in the spec text reviewed", "path": null }, "dispute": { "claims": [ "IETF Datatracker: Expired Internet-Draft (individual), IESG state Expired", "aapspec/spec repository shows zero stars and no post-launch activity" ], "summary": "The spec is an expired, single-author IETF individual submission with no working-group adoption and a stalled companion GitHub project; it is retained as a documented proposal rather than an active or governed spec." }, "evidence": [ { "claim": "The IETF Datatracker's document page for draft-aap-oauth-profile shows Document Type 'Expired Internet-Draft (individual)', IESG state 'Expired', last updated 2026-08-11, author 'angel cruz' with a note that the author's listed e-mail may no longer be valid.", "date": "2026-08-11", "label": "VERIFIED", "url": "https://datatracker.ietf.org/doc/draft-aap-oauth-profile/" }, { "claim": "The aapspec/spec GitHub repository hosts the same spec under an Apache 2.0 license, links a separate reference-impl repository, and its own README's IETF-status checklist shows no item beyond draft submission checked off, with zero GitHub stars and no commits after the 2026-02-07 draft date.", "date": "2026-02-07", "label": "REPORTED", "url": "https://github.com/aapspec/spec" } ], "form": "endpoint", "governance": "No formal governance body; single individual author plus a GitHub organization (aapspec) hosting the spec text, reference implementation, schemas, and test vectors", "group": null, "history": [ { "date": "2026-09-05", "note": "seeded from Exa Agent research run" }, { "date": "2026-09-06", "note": "verified against datatracker.ietf.org/doc/draft-aap-oauth-profile/ and github.com/aapspec/spec; found expired" } ], "id": "aap", "implementation": "prototype", "last_verified": "2026-09-06", "name": "Agent Authorization Profile", "native_status": "Expired Internet-Draft (individual), per the IETF Datatracker; last updated 2026-08-11, latest revision -01 dated 2026-02-07", "origin": { "date": "2026-02-07", "org": "Individual author (\"angel cruz\"), published via IETF individual submission and the aapspec GitHub organization" }, "part_of": null, "parties": [ "agent-site" ], "phase": "withdrawn", "probe": { "method": "GET", "on_absent": "No AAP claims present; given the draft's expired status this is the expected default across the ecosystem", "parse": "Decode a returned access token as a JWT and check for AAP-specific claim names (agent identity, task binding, delegation chain) as documented in the aapspec/spec repository's JSON Schemas", "path": "{authorization_server}/.well-known/oauth-authorization-server" }, "question": "How can OAuth 2.0/JWT claims carry structured agent identity, task context, operational constraints, delegation chains, and human-oversight requirements for machine-to-machine agent calls?", "scope": "general", "spec_url": "https://www.ietf.org/archive/id/draft-aap-oauth-profile-01.html", "step": "permit", "summary_md": "The Agent Authorization Profile (AAP) is a single-author IETF individual Internet-Draft, draft-aap-oauth-profile-01, dated 2026-02-07, proposing structured OAuth 2.0/JWT claims for autonomous AI agents [1]. It extends OAuth 2.0, JWT, RFC 8693 Token Exchange, and proof-of-possession mechanisms so that a resource server can reason about agent identity, task context, operational constraints, delegation chains, and whether human oversight is required for a given call, explicitly without introducing a new protocol [1].\n\nIt does not define a discovery mechanism beyond standard OAuth authorization-server metadata, and it does not define content-use or crawling permissions — like DAAP and AAuth, its scope is agent-to-API (M2M) authorization, not publisher content policy. Its distinguishing claim relative to those two overlapping drafts is a heavier emphasis on structured, machine-reasoned claims (delegation chains, human-oversight flags) rather than a minimal composition of existing mechanisms.\n\nAs of this verification (2026-09-06), the IETF Datatracker's own document-state field shows this draft as an 'Expired Internet-Draft (individual)', IESG state Expired, last updated 2026-08-11 with its single revision (-01) dated 2026-02-07 and no working-group affiliation — it never progressed beyond an individual submission [1]. The author's listed contact is separately flagged by the Datatracker as possibly no longer valid. A companion project exists at github.com/aapspec, including a spec repository (Apache 2.0 licensed), a claimed reference implementation, JSON Schemas, and test vectors, but the repository's own README shows an IETF-status checklist with no box beyond 'draft-00 submitted' checked, no GitHub stars, and no activity beyond the initial 2026-02-07 push found in this pass [2]. On that basis this record's phase is set to withdrawn and implementation to prototype (a reference implementation is claimed to exist, but with no evidence of independent use).\n\nWhat is unresolved: whether 'angel cruz' or another contributor intends to resubmit an active revision; whether any of AAP's specific claim names have been adopted informally by agent-framework builders outside the IETF process; and how AAP's more prescriptive claim-schema approach compares in practice to the lighter-weight DAAP profile, which explicitly avoids new claims. Given three overlapping, none-adopted individual OAuth-for-agents drafts (AAuth, DAAP, AAP) exist in this dataset, a future review should watch for which, if any, the OAuth Working Group formally adopts.", "track": "community", "version": { "date": "2026-02-07", "label": "draft-aap-oauth-profile-01" } }, { "acronym": "AIP", "adoption": { "by": null, "level": "unmeasured", "probe_run": null }, "aliases": [], "analog": "W3C DID plus a delegated-capability credential chain", "collisions": [ "Agent Interaction Protocol (unrelated proposals sometimes use the same AIP initialism)" ], "discovery": { "mechanism": "W3C Decentralized Identifier (DID) resolution plus cryptographic delegation-chain verification", "path": "none" }, "dispute": { "claims": [ "Author-declared 'Intended Status: Standards Track' does not itself confer IETF consensus or WG adoption; treat as aspirational until a WG picks it up." ], "summary": "This is a single-author draft with an author-stated Standards Track intent but no WG sponsorship and no located implementation; the acronym AIP is also used elsewhere for unrelated agent-interaction proposals, which is a collision worth flagging to readers." }, "evidence": [ { "claim": "AIP defines a decentralized identity, delegation and authorization framework for autonomous AI agents combining W3C DIDs, capability-based authorization, cryptographic delegation chains and deterministic validation, aiming to avoid reliance on centralized identity providers; it is a sole-author Internet-Draft (Paras Singla, Independent) with Standards Track as the author's intended status, and no working-group sponsorship, as shown on its ietf.org archive header", "date": "2026-06-10", "label": "REPORTED", "url": "https://www.ietf.org/archive/id/draft-singla-agent-identity-protocol-03.html" }, { "claim": "The IETF Datatracker's document page for draft-singla-agent-identity-protocol shows Document Type 'Active Internet-Draft (individual)', RFC stream '(None)', Intended RFC status '(None)', and last updated 2026-06-09 -- confirming no working-group has taken up the draft.", "date": "2026-06-09", "label": "REPORTED", "url": "https://datatracker.ietf.org/doc/draft-singla-agent-identity-protocol/" } ], "form": "endpoint", "governance": "IETF individual draft; sole author, no working group", "group": null, "history": [ { "date": "2026-09-05", "note": "seeded from Exa Agent research run" }, { "date": "2026-09-06", "note": "verified against draft-singla-agent-identity-protocol-03's abstract, introduction and document header; flagged limited depth of review and the AIP acronym collision" } ], "id": "aip", "implementation": "none-found", "last_verified": "2026-09-06", "name": "Agent Identity Protocol (AIP)", "native_status": "Internet-Draft, Intended Status: Standards Track (author's stated intent; not adopted by any WG)", "origin": { "date": "2026-06-10", "org": "Paras Singla (Independent)" }, "part_of": null, "parties": [ "agent-agent" ], "phase": "draft", "probe": { "method": "n/a", "on_absent": "Absence of a site artifact means nothing; AIP is negotiated between agents.", "parse": "n/a", "path": "n/a (client-side protocol; no fixed origin artifact)" }, "question": "How can an autonomous agent prove a decentralized identity and a verifiable chain of delegated authority from its human or organizational principal?", "scope": "general", "spec_url": "https://www.ietf.org/archive/id/draft-singla-agent-identity-protocol-03.html", "step": "identify", "summary_md": "The Agent Identity Protocol (AIP) is a proposed decentralized identity, delegation, and authorization framework for autonomous AI agents. It combines W3C Decentralized Identifiers (DIDs), capability-based authorization, cryptographic delegation chains, and deterministic validation, explicitly aiming to let multi-agent workflows be secure and auditable without depending on a centralized identity provider [1].\n\nIt targets the \"identity gap\" the author identifies: when an autonomous agent — which may send emails, book appointments, make purchases, access file systems, spawn child agents, or act across multiple platforms without per-action human approval — presents itself to an API, a payment processor, or another agent, there is today no standard way to establish the agent's persistent identity across interactions, which human or organization it acts on behalf of, or exactly which actions it is authorized to take [1]. AIP is not a working, deployed system: this pass reviewed the draft's abstract and introduction and did not verify the full delegation-chain wire format, so claims about a specific probeable endpoint or resolvable path cannot be made honestly at this time.\n\nCurrent state: draft-singla-agent-identity-protocol-03, published 2026-06-10, a sole-author IETF Internet-Draft under the Network Working Group umbrella (not a chartered WG) [2]. The author lists \"Standards Track\" as the intended status, but this is the author's own stated intent, not an indication of IETF working-group consensus or adoption — no WG has taken up this document as far as this check found [2].\n\nWho implements it: no implementation, reference library, or deployment was located in this pass.\n\nDisputed or unknown: whether AIP will be picked up by any chartered WG or remain an individual proposal; how it relates to, competes with, or could compose with ERC-8004's onchain identity model or ANS's DNS-anchored model (both also in this Identify layer) is not addressed in the reviewed text. The AIP acronym also collides with other unrelated agent-interaction proposals circulating in the same space, so readers should confirm they mean this specific draft.", "track": "community", "version": { "date": "2026-06-10", "label": "draft-singla-agent-identity-protocol-03, published 2026-06-10" } }, { "acronym": "AGTP", "adoption": { "by": null, "level": "unmeasured", "probe_run": null }, "aliases": [], "analog": "none", "collisions": [], "discovery": { "mechanism": "none", "path": "none" }, "dispute": null, "evidence": [ { "claim": "draft-hood-independent-agtp is at revision 09 (dated 2026-06-28 per the IETF datatracker document history), authored by Chris Hood of Nomotic, Inc., filed as an independent submission (not a working-group draft).", "date": "2026-09-05", "label": "VERIFIED", "url": "https://datatracker.ietf.org/doc/draft-hood-independent-agtp/" }, { "claim": "The draft defines AGTP as a dedicated application-layer protocol for AI agent traffic, distinct from and layered beneath HTTP-based agent protocols it calls Agent Group Messaging Protocols (AGMP) including MCP, ACP, A2A, and ANP; it prefers QUIC and requires TCP/TLS fallback.", "date": "2026-09-05", "label": "VERIFIED", "url": "https://www.ietf.org/archive/id/draft-hood-independent-agtp-04.html" } ], "form": "endpoint", "governance": "IETF individual/independent submission; not adopted by an IETF working group", "group": null, "history": [ { "date": "2026-09-05", "note": "seeded from Exa Agent research run" }, { "date": "2026-09-06", "note": "verified against IETF datatracker and draft-hood-independent-agtp-09 (updated spec_url from -04 to current -09, dated 2026-06-28); no implementations found" } ], "id": "agtp", "implementation": "none-found", "last_verified": "2026-09-06", "name": "Agent Transfer Protocol", "native_status": "Internet-Draft (work in progress), independent submission", "origin": { "date": "2026-01-15", "org": "Nomotic, Inc. (Chris Hood, independent submission)" }, "part_of": null, "parties": [ "agent-agent", "agent-site" ], "phase": "draft", "probe": { "method": "none", "on_absent": "not applicable — no implementation of AGTP has been located anywhere, so there is nothing to probe for absence against; see summary_md", "parse": "not applicable: there is no HTTP response body or header to parse because AGTP does not run over HTTP", "path": "none — AGTP is a non-HTTP application-layer protocol (QUIC preferred, TCP/TLS fallback) with its own method vocabulary (QUERY, SUMMARIZE, BOOK, SCHEDULE, LEARN, DELEGATE, COLLABORATE, CONFIRM, ESCALATE, NOTIFY, DESCRIBE, SUSPEND); it defines no well-known HTTP path or endpoint that a curl-style probe could hit" }, "question": "How can AI agent traffic be identified, authenticated, and governed as a distinct application-layer protocol rather than blending into ordinary HTTP?", "scope": "general", "spec_url": "https://www.ietf.org/archive/id/draft-hood-independent-agtp-09.html", "step": "coordinate", "summary_md": "The Agent Transfer Protocol (AGTP) is an Internet-Draft proposing a dedicated, non-HTTP, application-layer transport protocol purpose-built for AI agent traffic, submitted independently to the IETF (not sponsored by a working group) by Chris Hood of Nomotic, Inc [1]. It aims to solve a problem the author frames as: HTTP-based \"Agent Group Messaging Protocols\" (the draft's own term, naming MCP, ACP, A2A, and ANP as examples) presuppose HTTP as transport and so lack semantic vocabulary, observability primitives, and agent-identity mechanisms at the transport layer [2]. AGTP proposes its own intent-oriented methods (QUERY, SUMMARIZE, BOOK, SCHEDULE, LEARN, DELEGATE, COLLABORATE, CONFIRM, ESCALATE, NOTIFY, DESCRIBE, SUSPEND), protocol-level agent identity/authority headers, a purpose-built status-code vocabulary, and prefers QUIC with mandatory TCP/TLS fallback [2].\n\nAGTP does not define a discovery mechanism comparable to a well-known URI, and — because it proposes an entirely new wire protocol rather than a convention layered on existing HTTP infrastructure — it has no probe that can be executed with a simple `curl` against an arbitrary origin; there is no evidence of any implementation, reference or otherwise, as of this verification pass.\n\nAs of 2026-09-05 the current revision on the IETF datatracker is -09, dated 2026-06-28, five revisions past the -04 draft this record was originally seeded from (2026-04-17); the abstract that draft-09 preserves has iterated substantially, layering in normative integration hooks for a \"Merchant Identity and Agentic Commerce Binding specification,\" new merchant-related headers, and new authority-scope domains, evidence that the draft is under active, fast-moving individual authorship [1][2]. It remains an independent submission: it has not been adopted by any IETF working group, has no known implementations, and its status track here is recorded as IETF only in the loose sense of venue — it is not on a working-group standards track. What is unresolved: whether any organization beyond the sole named author (Nomotic, Inc.) is contributing to or planning to implement AGTP; no evidence of external implementers or adopters was found.", "track": "ietf", "version": { "date": "2026-06-28", "label": "draft-hood-independent-agtp-09" } }, { "acronym": "VCAP", "adoption": { "by": null, "level": "unmeasured", "probe_run": null }, "aliases": [ "VCAP" ], "analog": "Escrow with proof-of-delivery, formalized as an internet-draft message protocol", "collisions": [], "discovery": { "mechanism": "none published — the draft defines message formats and state machines for agent-to-agent settlement, not a discoverable site-level signal", "path": "none" }, "dispute": null, "evidence": [ { "claim": "draft-stone-vcap-02 is an Active Internet-Draft, Individual Submission, authored solely by Ben Stone of SwarmSync.AI, last updated 2026-09-04, with Intended status Informational and explicitly labeled 'not endorsed by the IETF' with 'no formal standing in the IETF standards process.'", "date": "2026-09-04", "label": "VERIFIED", "url": "https://datatracker.ietf.org/doc/draft-stone-vcap/" }, { "claim": "The draft's abstract defines VCAP as a settlement layer for autonomous AI agents that holds funds in escrow, verifies deliverables via independent verification engines, and releases or refunds payment based on machine-verifiable evidence, positioned as complementary to agent-to-agent communication protocols such as Google A2A rather than a replacement for them.", "date": "2026-09-04", "label": "VERIFIED", "url": "https://www.ietf.org/archive/id/draft-stone-vcap-02.html" } ], "form": "endpoint", "governance": "IETF individual Internet-Draft; not endorsed by the IETF, no working group, no formal standing in the IETF standards process", "group": null, "history": [ { "date": "2026-09-05", "note": "seeded from Exa Agent research run" }, { "date": "2026-09-06", "note": "verified against datatracker.ietf.org/doc/draft-stone-vcap/ and the draft-stone-vcap-02 text; confirmed individual-submission, no-IETF-standing status" } ], "id": "vcap", "implementation": "unknown", "last_verified": "2026-09-06", "name": "VCAP: Verified Commerce for Agent Protocols", "native_status": "Active Internet-Draft (individual); Intended RFC status: Informational", "origin": { "date": "2026-09-04", "org": "Individual submission (Ben Stone, SwarmSync.AI)" }, "part_of": null, "parties": [ "agent-agent" ], "phase": "draft", "probe": { "method": "none", "on_absent": "No probe exists; this is an early-stage individual draft with (per this verification) no known deployed implementation, so absence cannot be distinguished from non-adoption.", "parse": "not applicable — no implementation or endpoint to probe was located", "path": "none" }, "question": "How can two autonomous agent-run marketplaces settle a payment only once independent evidence shows the purchased work was actually delivered?", "scope": "commerce", "spec_url": "https://www.ietf.org/archive/id/draft-stone-vcap-02.html", "step": "pay", "summary_md": "VCAP (Verified Commerce for Agent Protocols) is an Internet-Draft proposing an open settlement-layer standard for autonomous AI agent marketplaces: it specifies message formats, state machines, cryptographic bindings, and callback contracts that would let a marketplace hold funds in escrow, verify a deliverable through an independent verification engine, and release or refund payment based on machine-checkable evidence [1][2]. It positions itself explicitly as complementary to agent-to-agent communication protocols like Google's A2A or \"the Agent Protocol\" — those define how agents find and talk to each other, while VCAP defines how they pay each other with proof the work happened [2].\n\nIt does not define agent discovery or messaging itself, and as of this verification it exists only as text: this is an individual Internet-Draft (draft-stone-vcap-02), authored solely by Ben Stone of a company called SwarmSync.AI, with no co-authors, no working group sponsorship, and no IETF endorsement — the IETF Datatracker page for the draft states plainly that \"this I-D is not endorsed by the IETF and has no formal standing in the IETF standards process\" [1]. Its Intended RFC status is Informational, the lightest-weight IETF track, appropriate for documentation rather than a mandatory-to-implement standard.\n\nThe current version, `-02`, was last updated 2026-09-04, with an expiry date of 2027-03-08 under IETF's standard six-month draft-expiry rule [1]. No implementation, reference code, pilot deployment, or third-party discussion of VCAP was located during this verification pass beyond the draft text and its Ethereum Magicians-style discussion link pattern common to individual submissions; this record should be treated as existence-only evidence of a proposal, not evidence of a working or adopted protocol. What is unresolved: whether this draft has attracted any co-authors, implementers, or working-group interest since version -02, and what \"SwarmSync.AI\" is or does.", "track": "ietf", "version": { "date": "2026-09-04", "label": "draft-stone-vcap-02" } }, { "acronym": "ANP", "adoption": { "by": null, "level": "unmeasured", "probe_run": null }, "aliases": [], "analog": "none", "collisions": [], "discovery": { "mechanism": "Agent Discovery Service Protocol (ADSP), active .well-known discovery", "path": "/.well-known/agent-descriptions" }, "dispute": null, "evidence": [ { "claim": "ANP's released specification suite (v1.1) covers did:wba identity, WNS handles, agent description (ANP-07), agent discovery (ANP-08), end-to-end instant messaging (ANP-09), and the AP2 agent payment protocol (ANP-10); the meta-protocol (ANP-06) remains an unreleased draft.", "date": "2026-09-05", "label": "VERIFIED", "url": "https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/main/README.md" }, { "claim": "ANP-08 (Agent Discovery Protocol, Released v1.1) defines active discovery via the well-known path https://{domain}/.well-known/agent-descriptions, returning a JSON-LD CollectionPage listing agent description documents, plus a passive registration API for search-service agents.", "date": "2026-09-05", "label": "VERIFIED", "url": "https://raw.githubusercontent.com/agent-network-protocol/AgentNetworkProtocol/main/08-ANP-Agent-Discovery-Protocol-Specification.md" } ], "form": "well-known-file", "governance": "Community-led open-source project (agent-network-protocol GitHub org)", "group": null, "history": [ { "date": "2026-09-05", "note": "seeded from Exa Agent research run" }, { "date": "2026-09-06", "note": "verified against agent-network-protocol.com and github.com/agent-network-protocol/AgentNetworkProtocol README + ANP-08 discovery spec; corrected version from v0.1/experimental to released v1.1 and filled discovery path" } ], "id": "anp", "implementation": "shipping", "last_verified": "2026-09-06", "name": "Agent Network Protocol", "native_status": "Released v1.1 (core suite); meta-protocol (ANP-06) remains draft/unreleased", "origin": { "date": null, "org": "Agent Network Protocol community project" }, "part_of": null, "parties": [ "agent-agent" ], "phase": "stable", "probe": { "method": "GET", "on_absent": "404 or non-JSON-LD response means the domain does not expose ANP active discovery; agents there may still be reachable only via passive registration with a search service", "parse": "JSON-LD CollectionPage document with an items[] array of ad:AgentDescription entries confirms ANP active discovery is exposed", "path": "{origin}/.well-known/agent-descriptions" }, "question": "How can decentralized agents from different platforms authenticate, discover, and message each other without a central registry?", "scope": "general", "spec_url": "https://github.com/agent-network-protocol/AgentNetworkProtocol", "step": "coordinate", "summary_md": "The Agent Network Protocol (ANP) is a suite of open specifications describing itself as aiming to become \"the HTTP of the Agentic Web era\": a protocol stack for agent identity, naming, discovery, negotiation, secure messaging, and application-level collaboration [1]. It solves several coordinate-layer problems at once rather than one narrow one: `did:wba` (ANP-03) gives agents a Web-based DID identity method; ANP-04 layers human-readable WNS handles (e.g. `alice.example.com`) over DIDs; ANP-07 defines machine-readable Agent Description documents; ANP-08 (the Agent Discovery Protocol, ADSP) defines active discovery via a well-known JSON-LD collection page and a passive registration API for search-service agents; ANP-09 defines an end-to-end encrypted instant-messaging profile suite (direct and group messaging, attachments, federation, mentions); and ANP-10 layers an agent payment protocol (AP2) on top [1][2].\n\nANP explicitly does not rebuild core internet infrastructure — it reuses HTTP, DNS, CA/TLS, CDN, and search rather than defining a new network stack — and its meta-protocol layer (ANP-06, a semantic negotiation layer analogous in spirit to Agora's protocol negotiation) remains an unreleased draft, not part of the currently released architecture [1].\n\nAs of this verification (2026-09-05), the released specification-document version is 1.1, though the project is explicit that this document-version bump does not change the wire-level `protocolVersion` field, which remains `\"1.0.0\"` in released message examples — a versioning nuance worth flagging for implementers [1]. Discovery is confirmed executable: `GET https://{domain}/.well-known/agent-descriptions` should return a JSON-LD `CollectionPage` whose `items[]` array lists `ad:AgentDescription` entries with pagination via a `next` field, per RFC 8615 conventions [2]. The project also publishes vNext draft revisions (ANP-01 through ANP-09) that do not yet replace the released v1.1 text, and a separately versioned ANP Messaging 1.2 draft for multi-device cryptographic endpoints. What is unresolved: no independently measured count of live ANP deployments was found in this pass — adoption here is recorded as unmeasured, and the seed's prior \"v0.1, experimental\" characterization understated the protocol's actual maturity (v1.1, released), which was corrected in this pass.", "track": "community", "version": { "date": null, "label": "1.1 (protocol document release); protocolVersion field remains 1.0.0" } }, { "acronym": "", "adoption": { "by": null, "level": "unmeasured", "probe_run": null }, "aliases": [ "Agora (academic)" ], "analog": "none", "collisions": [ "Agora (agoraproto.org agent-to-agent marketplace, a different, unrelated project — see agora-commerce-protocol)" ], "discovery": { "mechanism": "well-known list of supported protocol hashes", "path": "/.wellknown" }, "dispute": null, "evidence": [ { "claim": "Agora: \"A Scalable Communication Protocol for Networks of LLMs\" (arXiv:2410.11905) is authored by Samuele Marro, Emanuele La Malfa, Jesse Wright, Guohao Li, Nigel Shadbolt, Michael Wooldridge, and Philip Torr, affiliated with the University of Oxford and Camel AI.", "date": "2026-09-05", "label": "VERIFIED", "url": "https://raw.githubusercontent.com/agora-protocol/paper-demo/main/README.md" }, { "claim": "The Agora specification defines a three-tier interaction model (natural language, LLM-negotiated structured protocol, then deterministic routine scripts), a JSON transaction envelope (protocolHash, protocolSources, body/status), and a /.wellknown endpoint agents expose to advertise supported protocol hashes and their sources.", "date": "2026-09-05", "label": "VERIFIED", "url": "https://raw.githubusercontent.com/agora-protocol/agora-protocol.github.io/master/specs.html" }, { "claim": "agoraproto.org's own machine-readable manifest explicitly disambiguates itself from \"the academic 'Agora Protocol' paper by Marro et al. — that is a different project that happens to share the name,\" confirming the two Agoras are unrelated.", "date": "2026-09-05", "label": "VERIFIED", "url": "https://agoraproto.org" } ], "form": "well-known-file", "governance": "Academic research project (Oxford / Camel AI); community-maintained code", "group": null, "history": [ { "date": "2026-09-05", "note": "seeded from Exa Agent research run" }, { "date": "2026-09-06", "note": "verified against agora-protocol paper-demo README, agora-protocol.github.io specs.html, and agoraproto.org's own disambiguation notice; confirmed distinct from agora-commerce-protocol" } ], "id": "agora-protocol", "implementation": "prototype", "last_verified": "2026-09-06", "name": "Agora Protocol", "native_status": "Research protocol with reference implementation and demo", "origin": { "date": "2024-10", "org": "University of Oxford / Camel AI (Marro, La Malfa, Wright, Li, Shadbolt, Wooldridge, Torr)" }, "part_of": null, "parties": [ "agent-agent" ], "phase": "living", "probe": { "method": "GET", "on_absent": "Absence means the agent does not advertise pre-negotiated protocols and any Agora exchange would fall back to natural-language negotiation over the same transaction envelope", "parse": "JSON object mapping protocol hashes to arrays of protocol-document source URIs confirms the agent declares Agora-supported protocols", "path": "{origin}/.wellknown" }, "question": "How can two heterogeneous LLM agents communicate efficiently, moving from expensive natural-language negotiation to a cheap, mutually agreed structured protocol?", "scope": "general", "spec_url": "https://raw.githubusercontent.com/agora-protocol/agora-protocol.github.io/master/specs.html", "step": "coordinate", "summary_md": "Agora (the academic protocol, arXiv:2410.11905) is a cross-platform communication protocol for networks of heterogeneous LLM-based agents, from University of Oxford and Camel AI researchers [1]. It solves the cost/scalability problem of agent-to-agent natural-language chat: two agents (\"Alice\" and \"Bob\" in the spec's running example) initially converse in natural language via their LLMs; when a communication pattern recurs, they use their LLMs to negotiate a shared structured protocol (typically JSON) in a handful of rounds; once agreed, each side writes a deterministic \"routine\" (a small script) implementing its side, after which further exchanges no longer require invoking an LLM at all [2]. This lets very different agents that have never met communicate at low up-front cost while converging toward near-zero marginal cost, which the authors frame as achieving efficiency, versatility, and portability simultaneously.\n\nEach Agora message is a JSON envelope carrying `protocolHash` (a hash of the negotiated protocol document, or null for natural-language exchanges), `protocolSources` (URIs where the protocol document can be fetched), and a `body`; responses carry `status` (\"success\"/\"failure\") and `body` [2]. Agents may expose a `/.wellknown` endpoint listing the protocol hashes and source URIs they already support, letting a sender skip negotiation entirely when a suitable shared protocol already exists [2].\n\nAgora does not define payments, identity/authentication, or a marketplace — it is purely a communication/negotiation protocol between agents that already know how to reach each other over HTTPS. It is explicitly and importantly a different project from the same-named agent marketplace at agoraproto.org (see `agora-commerce-protocol`); agoraproto.org's own site states this disambiguation directly [3]. As of this verification, the project's code has moved past the original paper-demo (aimed at a 100-agent network with mixed LLM backends and DB technologies) toward an updated HuggingFace demo and a general-purpose Python library, but there is no versioned \"1.0\" release and no measured count of production deployments — it remains a research/community project rather than a standards-track spec. Governance is informal (the original academic authors plus open community contribution via GitHub/Discord); no formal standards body is involved.", "track": "academic", "version": { "date": null, "label": "current repository (post-paper iteration)" } }, { "acronym": "", "adoption": { "by": null, "level": "unmeasured", "probe_run": null }, "aliases": [ "Agora Protocol (agoraproto.org)" ], "analog": "freelance marketplace plus escrow", "collisions": [ "Agora Protocol (Marro et al., academic negotiation protocol — unrelated, see agora-protocol)" ], "discovery": { "mechanism": "/.well-known/ai-services.json manifest plus /.well-known/agora.json webhook-signing config", "path": "https://api.agoraproto.org/.well-known/ai-services.json" }, "dispute": { "claims": [ "agoraproto.org's schema.org markup: \"Not to be confused with the academic 'Agora Protocol' paper by Marro et al. — that is a different project that happens to share the name.\"" ], "summary": "This project and the academic 'Agora Protocol' (arXiv:2410.11905, Oxford/Camel AI) share the name \"Agora\" but are confirmed, by the marketplace project's own published manifest, to be unrelated, independently authored projects." }, "evidence": [ { "claim": "agoraproto.org's homepage schema.org markup and its own manifest explicitly state it is not to be confused with the academic Agora Protocol paper by Marro et al., describing itself instead as \"Open marketplace and communication protocol where AI agents discover, hire, and pay other AI agents for paid work,\" settling on-chain on Base Sepolia in USDC via HTTP-402 escrow.", "date": "2026-09-05", "label": "VERIFIED", "url": "https://agoraproto.org" }, { "claim": "The live OpenAPI spec at api.agoraproto.org/v1/openapi.json exposes payments/escrow endpoints (/v1/payments/quote, /v1/payments/execute), an x402 payment-protocol job flow (/v1/x402/jobs, /v1/x402/quote), and a jobs/listings/bids marketplace surface, confirming this is a commerce/payments protocol rather than a general negotiation protocol.", "date": "2026-09-05", "label": "VERIFIED", "url": "https://api.agoraproto.org/v1/openapi.json" }, { "claim": "The project's own /.well-known/ai-services.json manifest discloses production_status \"testnet-only\", chain \"base-sepolia\", settlement_currency \"USDC\", and documents known security limitations (C-01, C-02, H-01, H-02) in its V1 escrow contract from a 2026-05-27 external audit, stating the V2 contract fixing them is written but not yet deployed or audited.", "date": "2026-09-05", "label": "VERIFIED", "url": "https://api.agoraproto.org/.well-known/ai-services.json" } ], "form": "well-known-file", "governance": "Single vendor / independent project (agoraproto.org)", "group": null, "history": [ { "date": "2026-09-05", "note": "seeded from Exa Agent research run" }, { "date": "2026-09-06", "note": "verified against api.agoraproto.org openapi.json and .well-known manifests, and agoraproto.org homepage; moved step from coordinate to pay given its payments/escrow/marketplace scope; confirmed distinct project from agora-protocol (Oxford academic) via the project's own disambiguation notice" } ], "id": "agora-commerce-protocol", "implementation": "prototype", "last_verified": "2026-09-06", "name": "Agora (agent marketplace protocol)", "native_status": "Testnet-only; production_status explicitly \"testnet-only\" in its own manifest", "origin": { "date": null, "org": "agoraproto.org (unaffiliated single project)" }, "part_of": null, "parties": [ "agent-agent", "agent-payment" ], "phase": "candidate", "probe": { "method": "GET", "on_absent": "404 means the origin does not publish an Agora-style AI-services manifest; this is a single-project convention, not yet a broadly adopted well-known name", "parse": "JSON manifest with schema_version, type:\"marketplace\", and production_status field; on agoraproto.org itself this currently reads \"testnet-only\"", "path": "https://api.agoraproto.org/.well-known/ai-services.json" }, "question": "How can an AI agent discover, hire, and pay another AI agent for a paid job, with escrowed on-chain settlement?", "scope": "commerce", "spec_url": "https://api.agoraproto.org/v1/openapi.json", "step": "pay", "summary_md": "This record covers the agent-to-agent hiring marketplace at agoraproto.org, previously conflated in this dataset with the unrelated academic \"Agora Protocol\" research paper (now split out as `agora-protocol`). It moved to the **pay** step in this verification pass: fetching its live OpenAPI spec and its own `/.well-known/ai-services.json` manifest shows the protocol is fundamentally a paid-marketplace and payment-settlement spec, not a general agent-coordination protocol — its endpoint surface is dominated by `/v1/jobs`, `/v1/listings`, `/v1/requests`/bids, `/v1/payments/quote`, `/v1/payments/execute`, and an `/v1/x402/*` family implementing the HTTP-402 payment-required pattern [2].\n\nWhat it is: a marketplace where an AI agent needing a capability it lacks (translation, compliance audit, fact-checking, code review, etc.) can discover, hire, and pay another AI agent for a bounded, escrowed job, settling on-chain in USDC on Base Sepolia (a testnet) [1][3]. Each agent carries a W3C DID identity; jobs move through offer/accept/reject/result/approve/dispute states with a code-as-judge dispute-resolution mechanism; reputation and trust levels (probation, new, verified, trusted) are tracked and tied to settled on-chain jobs [1]. Discovery works through two `.well-known` files: `/.well-known/ai-services.json` (a machine-readable marketplace manifest naming the project, its chain, and its production status) and `/.well-known/agora.json` (webhook signing keys and supported webhook event types) [3].\n\nWhat it does not do: it explicitly is not the Oxford/Camel AI academic Agora negotiation protocol, despite the shared name — its own manifest states this directly [1]. It is not a general-purpose agent-to-agent messaging protocol; it is scoped to paid marketplace transactions.\n\nCurrent state (as of manifest date 2026-05-25, checked live 2026-09-05): explicitly \"testnet-only\" production status. The manifest discloses, in unusual and welcome detail, that its deployed V1 escrow contract (`AgoraEscrow.sol` at a named Base Sepolia address) has four documented weaknesses from a 2026-05-27 external audit (owner can unilaterally refund disputed jobs; dispute path is refund-only; no deadline check on result submission; fees can change post-funding), that a V2 contract addressing these exists in the repository but is undeployed and unaudited, and that the manifest itself warns \"Do NOT use this deployment for mainnet money\" [3]. Governance is a single, apparently small, independent project (no vendor consortium or standards body named) — track is recorded as single-vendor. What is unresolved: no evidence of any other implementer, adopter, or independent security review beyond the project's own disclosed audit; adoption is unmeasured.\n\nCorrection (2026-09-06 relink): the manifest is served on the API host (`api.agoraproto.org`), not the apex domain (`agoraproto.org`); the discovery and probe paths in this record now point at `https://api.agoraproto.org/.well-known/ai-services.json` accordingly.", "track": "single-vendor", "version": { "date": "2026-05-25", "label": "API v1, contract v1 (V2 contract written but undeployed)" } }, { "acronym": "s402", "adoption": { "by": null, "level": "unmeasured", "probe_run": null }, "aliases": [], "analog": "A chain-specific profile of x402, the way a vendor extension profiles a base HTTP standard", "collisions": [], "discovery": { "mechanism": "HTTP 402 response carrying the x402 v2 PaymentRequired envelope, with an s402-specific extensions.s402 field distinguishing an s402-profile 402 from a plain x402 one", "path": "none — no /.well-known/s402.json was found; discovery is per-request via the 402 envelope, matching x402's model" }, "dispute": null, "evidence": [ { "claim": "s402's specification.md, versioned as Wire Format Specification v1 (Draft, March 2026), defines s402 as encoding, field, and validation rules for six payment schemes (exact, upto, prepaid, stream, escrow, unlock) carried inside the x402 v2 PaymentRequired envelope, using the same payment-required, x-payment, and payment-response headers as x402 for wire compatibility.", "date": "2026-03", "label": "VERIFIED", "url": "https://raw.githubusercontent.com/s402-protocol/core/main/docs/specification.md" }, { "claim": "The s402-protocol/core repository README describes s402 as 'a profile of x402: the Sui binding, and the rules about what an agent may pay,' states it is audited/tested against a specific x402-foundation/x402 commit as of 2026-09-04, and that the Sui reference implementation ships separately as @sweefi/sui, whose Prepaid scheme is modelled (not measured in production) to cut effective per-call gas cost via Programmable Transaction Blocks.", "date": "2026-09-04", "label": "VERIFIED", "url": "https://raw.githubusercontent.com/s402-protocol/core/main/README.md" }, { "claim": "The repository's own GitHub metadata describes it as 'Sui-native HTTP 402 protocol. Wire-compatible with x402. Atomic settlement via PTBs,' created 2026-02-15, last pushed 2026-09-04, with 0 GitHub stars at time of check.", "date": "2026-09-06", "label": "VERIFIED", "url": "https://github.com/s402-protocol/core" } ], "form": "http-header", "governance": "Single open-source project (s402-protocol on GitHub); no standards body, no foundation; explicitly a 'profile' of x402 rather than a competing standards effort", "group": "HTTP 402 family", "history": [ { "date": "2026-09-05", "note": "seeded from Exa Agent research run" }, { "date": "2026-09-06", "note": "verified against s402-protocol/core (README.md, docs/specification.md) and GitHub repo metadata; corrected discovery mechanism from a nonexistent /.well-known/s402.json to the x402-envelope extensions.s402 signal" } ], "id": "s402", "implementation": "prototype", "last_verified": "2026-09-06", "name": "s402", "native_status": "Draft wire-format specification, actively developed (commits as recent as 2026-09-04)", "origin": { "date": "2026-02", "org": "s402-protocol (open-source project; Sui reference implementation ships separately as @sweefi/sui)" }, "part_of": null, "parties": [ "agent-site", "agent-payment" ], "phase": "draft", "probe": { "method": "GET", "on_absent": "A 402 without extensions.s402 in the decoded PaymentRequired object is a plain x402 (or other x402-compatible) response, not s402; per the spec, such a response is still payable by an s402-aware client, so absence of the s402 extension does not mean the endpoint rejects s402 clients, only that it isn't advertising s402-specific schemes.", "parse": "HTTP 402 with a payment-required header decoding (base64+JSON) to an x402 v2 PaymentRequired object whose extensions field contains an s402 key", "path": "{origin}/{paid-path}" }, "question": "How can an agent pay a Sui-native resource using six payment schemes (including prepaid batching and escrow), while staying wire-compatible with plain x402 clients?", "scope": "payments", "spec_url": "https://raw.githubusercontent.com/s402-protocol/core/main/docs/specification.md", "step": "pay", "summary_md": "s402 is a Sui-chain profile of x402: it reuses x402 v2's `PaymentRequired` HTTP envelope and header names (`payment-required`, `x-payment`, `payment-response`) wholesale, and adds a Sui-specific binding plus a policy layer covering six payment schemes — exact, upto, prepaid, stream, escrow, and unlock — the last four of which go beyond what plain x402 or Stripe's MPP currently define [1]. The project's own README is explicit about the relationship: \"s402 does not fight x402 or Stripe MPP head-on... it absorbs them as payment-in formats... and supersets them on primitives their business models cannot ship\" [2].\n\nIt solves Sui-native settlement for agent payments, including a \"Prepaid\" scheme that the project models as settling 1,000 API calls in 2 on-chain transactions via Sui's Programmable Transaction Blocks (PTBs), versus 1,000 transactions for one-shot \"Exact\" payments — but the README is careful to flag this as a modelled estimate under stated assumptions, not a measurement from production traffic [2]. It does not define its own transport or discovery mechanism distinct from x402: an s402-profile 402 response is detected only by the presence of an `extensions.s402` key inside the same x402 v2 envelope, and a 402 lacking that key is still payable by an s402-aware client [1].\n\nAs of this verification, s402 is a single-repository open-source project (`s402-protocol/core`) with no separate standards body or foundation, actively developed (commits through 2026-09-04, aligned against a specific x402-foundation/x402 commit as of that date) but showing zero GitHub stars and no evidence of external adopters located during this check [2][3]. The protocol layer is explicitly chain-agnostic in design (an \"S7 invariant\" keeps chain-specific logic out of the core), with the actual Sui settlement code shipping separately as `@sweefi/sui` — an npm package from what appears to be a company or team called \"sweefi,\" whose relationship to s402-protocol was not independently confirmed beyond both projects' own cross-references [2]. What is unresolved: whether s402 has any production deployment beyond its own demos, and who or what \"sweefi\" is as an organization.", "track": "community", "version": { "date": "2026-03", "label": "Wire Format Specification v1, Draft, dated March 2026 (repository has continued past this to align with x402 v2)" } }, { "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" } }, { "acronym": "AAT", "adoption": { "by": null, "level": "unmeasured", "probe_run": null }, "aliases": [ "draft-sharif-agent-audit-trail" ], "analog": "a standardized syslog/audit-log format, but hash-chained like a blockchain for tamper evidence", "collisions": [], "discovery": { "mechanism": "none", "path": null }, "dispute": { "claims": [ "Author markets EU AI Act / SOC 2 / ISO alignment; none of those frameworks has adopted or referenced this specific draft as far as could be verified here.", "No known implementation exists yet (implementation=none-found); this is a proposal, not a running system." ], "summary": "This is an individual Internet-Draft, not a Working Group item -- the IETF datatracker explicitly states such drafts are 'not endorsed by the IETF' and have 'no formal standing' in the standards process, and 'Intended status: Standards Track' is only the author's aspiration. No implementation, adopter or third-party citation of AAT was found in the sources checked; it is included here because it is the most complete public account/audit-log spec text found for this step, not because it has traction." }, "evidence": [ { "claim": "IETF Datatracker lists draft-sharif-agent-audit-trail as an active Internet-Draft (individual submission, not IETF-endorsed, no formal standing), authored by Raza Sharif of CyberSecAI Ltd, currently at revision -03 (last updated 2026-09-05, expires 2027-03-09), with prior revisions -00 through -02 dated back to at least March 2026.", "date": "2026-09-05", "label": "VERIFIED", "url": "https://datatracker.ietf.org/doc/draft-sharif-agent-audit-trail/" }, { "claim": "The draft text (revision -03) specifies a JSON-based Agent Audit Trail (AAT) with mandatory fields for agent identity, action classification, outcome and trust-level reporting, SHA-256 hash-chained records per RFC 8785, optional ECDSA signatures, JSONL/Syslog/CSV export, and explicitly maps to the EU AI Act (Regulation 2024/1689) high-risk logging mandate (effective August 2026), SOC 2, ISO/IEC 42001, ISO/IEC 24970, prEN 18229-1 and PCI DSS v4.0.1.", "date": "2026-09-05", "label": "VERIFIED", "url": "https://www.ietf.org/archive/id/draft-sharif-agent-audit-trail-03.txt" } ], "form": "document-format", "governance": "IETF individual Internet-Draft; not adopted by any IETF working group, 'not endorsed by the IETF' and has 'no formal standing' in the IETF process (datatracker's own disclaimer)", "group": null, "history": [ { "date": "2026-09-06", "note": "new record: found via search for 'agent audit log standard'; verified against datatracker.ietf.org and the archived draft text (revision -03, 2026-09-05); no implementation found" } ], "id": "agent-audit-trail", "implementation": "none-found", "last_verified": "2026-09-06", "name": "Agent Audit Trail", "native_status": "Active Internet-Draft (individual submission), Intended status: Standards Track; not a Working Group document", "origin": { "date": "2026-03", "org": "Raza Sharif / CyberSecAI Ltd (individual submitter)" }, "part_of": null, "parties": [ "agent-site" ], "phase": "draft", "probe": { "method": "GET", "on_absent": "There is no way to detect AAT usage from outside a system -- it describes an internal/exported logging format, not a discoverable service. Absence just means a given agent's logs were not inspected, not that AAT is unused.", "parse": "The spec defines a JSON record format, not a network endpoint: each record MUST carry record_id (UUIDv4), timestamp (RFC 3339), agent_id (URI), agent_version (semver), session_id (UUIDv4), action_type (tool_call/tool_response/decision/delegation/escalation/error/lifecycle), action_detail (object), outcome (success/failure/timeout/denied/escalated), trust_level (L0-L4), parent_record_id and prev_hash (SHA-256 of the previous record's RFC 8785 canonical JSON, forming a hash chain), and record_phase (pre_execution/post_execution/concurrent). The RECOMMENDED export format is JSONL. A conforming log is one where every line validates against these mandatory fields and the hash chain verifies.", "path": "{log_export_endpoint}" }, "question": "Is there a standard, tamper-evident log format any autonomous AI agent can write its actions to, so a regulator, auditor or victim can later reconstruct exactly what it did and why?", "scope": "general", "spec_url": "https://datatracker.ietf.org/doc/draft-sharif-agent-audit-trail/", "step": "account", "summary_md": "Agent Audit Trail (AAT) is an individual IETF Internet-Draft proposing a standard JSON logging format for autonomous AI agent systems: each record must carry an agent identity (URI), a session id, an action type (tool_call, decision, delegation, escalation, error, lifecycle, etc.), an outcome (success, failure, timeout, denied, escalated), and a trust level (L0 no verification through L4 full mutual authentication with revocation checking) [1][2]. Records are linked into a tamper-evident hash chain -- each record stores the SHA-256 hash (per RFC 8785 canonical JSON) of the immediately preceding record -- with optional ECDSA signatures for non-repudiation, and a record_phase field (pre_execution/post_execution/concurrent) that distinguishes a log written before an action is allowed to run from one written after it completes [2]. This is a direct fit for this site's 'account' step: it is explicitly a logs/audit-trail format for reconstructing and judging what an agent did.\n\n**What it solves.** It gives autonomous-agent operators a single, exportable record format (JSONL is the recommended primary export, with Syslog and CSV also supported) intended to satisfy several overlapping compliance regimes at once: the EU AI Act's Article on automatic event recording for high-risk AI systems (effective August 2026), SOC 2 Trust Services Criteria, ISO/IEC 42001 and 24970, prEN 18229-1, and PCI DSS v4.0.1 [2]. Later revisions add a 'Decision Reproducibility' section distinguishing record reproducibility (available for any model) from full decision reproducibility (only for open-weight models run at temperature zero in an attested environment), and, in the current -03 revision, an 'Attestation Closure' requirement that the digests recorded cover the entire inference stack (model weights, tokenizer, chat template, inference-engine build, decoding configuration, numeric environment) to close forgery gaps [2].\n\n**What it does not do.** AAT does not define a discovery mechanism, a transport, or a place logs must be published -- it is a record format for whatever storage/export pipeline an operator already has. It does not define agent identity or authentication itself (trust_level is self-reported by the logging system, referencing an external identity mechanism such as the also-draft 'MCPS'/Agent Passport concept).\n\n**Current state.** As of 2026-09-05 this is revision -03 of an individual (not Working-Group) draft, authored solely by Raza Sharif of CyberSecAI Ltd, with 'Intended status: Standards Track' -- an author aspiration, not a Working Group adoption. The IETF datatracker's own boilerplate states individual drafts are not endorsed by the IETF and have no formal standing [1].\n\n**Who implements it.** No implementation, pilot, or third-party adopter was found in the sources checked; implementation is marked none-found and adoption unmeasured.\n\n**Disputed / unknown.** Whether this draft will be adopted by any IETF working group, referenced by an actual EU AI Act compliance guidance document, or implemented by any agent framework, is unknown. It is listed here as the most complete public spec text found for the 'account' step, explicitly flagged as early-stage and unimplemented rather than as an established standard.", "track": "ietf", "version": { "date": "2026-09-05", "label": "draft-sharif-agent-audit-trail-03" } }, { "acronym": "SLIM", "adoption": { "by": null, "level": "unmeasured", "probe_run": null }, "aliases": [ "AGNTCY SLIM" ], "analog": "none", "collisions": [], "discovery": { "mechanism": "none", "path": "none" }, "dispute": null, "evidence": [ { "claim": "SLIM (Secure Low-Latency Interactive Messaging) is described by its own README as a next-generation communication framework providing the secure, scalable transport layer for AI agent protocols like A2A and MCP, with a Data Plane, Session Layer, and Control Plane architecture; the repository is Apache-2.0 licensed and was created 2025-02-05 under the agntcy GitHub org.", "date": "2026-09-05", "label": "VERIFIED", "url": "https://raw.githubusercontent.com/agntcy/slim/main/README.md" }, { "claim": "Cisco donated the AGNTCY project, which SLIM belongs to, to the Linux Foundation; formative members named include Cisco, Dell Technologies, Google Cloud, Oracle, and Red Hat, and the project covers discovery, identity, messaging, and observability for multi-vendor AI agents, with SLIM as its messaging-transport protocol.", "date": "2026-09-05", "label": "VERIFIED", "url": "https://www.techzine.eu/blogs/infrastructure/133408/cisco-donates-agntcy-to-linux-foundation-internet-of-agents-on-its-way/" }, { "claim": "A SLIM specification has also been filed at the IETF as an individual draft, draft-mpsb-agntcy-slim-00, \"Secure Low-Latency Interactive Messaging (SLIM).\"", "date": "2026-09-05", "label": "REPORTED", "url": "https://www.ietf.org/archive/id/draft-mpsb-agntcy-slim-00.html" } ], "form": "endpoint", "governance": "Linux Foundation (AGNTCY project); originally donated by Cisco", "group": null, "history": [ { "date": "2026-09-06", "note": "new record created during coordinate-step verification; verified against github.com/agntcy/slim README, Linux Foundation/AGNTCY donation coverage, and the IETF individual draft draft-mpsb-agntcy-slim-00" } ], "id": "slim", "implementation": "shipping", "last_verified": "2026-09-06", "name": "Secure Low-Latency Interactive Messaging", "native_status": "\"Next-generation communication framework that provides the secure, scalable transport layer for AI agent protocols like A2A and MCP\"", "origin": { "date": "2025-02", "org": "Cisco (AGNTCY project)" }, "part_of": null, "parties": [ "agent-agent" ], "phase": "working-group", "probe": { "method": "none", "on_absent": "not applicable — SLIM has no well-known discovery surface as of this verification; see summary_md", "parse": "not applicable: there is no HTTP response to parse; presence would instead be inferred from a target's published SLIM node configuration or its listed use of the slim-a2a-python / slim-mcp-python bindings", "path": "none — SLIM is a session/routing protocol operated by a data-plane node over its own wire format, not a document served at a fixed well-known HTTP path; no origin-fetchable probe was identified" }, "question": "How can agents send secure, low-latency, group-aware messages (point-to-point, pub/sub, fire-and-forget, streaming) as a transport underneath higher-level protocols like A2A and MCP?", "scope": "general", "spec_url": "https://github.com/agntcy/slim", "step": "coordinate", "summary_md": "SLIM (Secure Low-Latency Interactive Messaging) is a messaging/transport framework built for the AGNTCY project, intended to serve as the secure, scalable transport layer underneath higher-level agent protocols such as A2A and MCP [1]. It solves a gap those protocols leave open: neither A2A nor MCP specifies a low-latency, group-aware, end-to-end-encrypted messaging transport; SLIM supports request-response, publish-subscribe, fire-and-forget, and streaming interaction patterns, and builds in authentication, authorization, and end-to-end (MLS) encryption at the transport layer [2]. Architecturally it splits into a Data Plane (pure hierarchical-name-based packet routing, content-blind), a Session Layer (reliable delivery, end-to-end MLS encryption, group membership), and a Control Plane (configuration, monitoring, orchestration) — letting lightweight routing nodes run only the data plane while applications carry the full stack via language bindings (Python, Go, .NET, Java, Kotlin) [1].\n\nSLIM does not define agent discovery, identity, or task semantics itself — those are the roles of A2A/MCP and AGNTCY's separate directory/identity components; SLIM's own README frames itself purely as the transport underneath those protocols [1].\n\nCurrent state: the `agntcy/slim` repository was created 2025-02-05, is Apache-2.0 licensed, and is actively maintained (CI, code coverage, and OpenSSF Scorecard badges all present and green as of this check) [1]. AGNTCY itself — the umbrella project SLIM belongs to — was donated by Cisco to the Linux Foundation, with Dell Technologies, Google Cloud, Oracle, and Red Hat joining as formative members, to standardize open multi-agent-system infrastructure including discovery, identity, messaging (SLIM), and observability [2]. A SLIM specification has also been filed as an individual IETF Internet-Draft, draft-mpsb-agntcy-slim-00, though it is not yet a working-group document — this record treats the Linux Foundation/AGNTCY project as SLIM's primary governance home given that the code, documentation, and formative-member structure all live there, and marks track as linux-foundation rather than ietf accordingly. Implementations exist and ship as bindings across five languages plus integrations for A2A and MCP transport (slim-a2a-python, slim-mcp-python) and OpenTelemetry [1]. What is unresolved: no independently measured adoption count was found; this is a genuinely new record added during this verification pass per the coordinator's occupant-diff instruction, and its exact relationship to the IETF draft (same authors? formally submitted by the AGNTCY project?) was not further disambiguated in this pass.", "track": "linux-foundation", "version": { "date": null, "label": "IETF individual draft draft-mpsb-agntcy-slim-00; active GitHub development" } }, { "acronym": "RFC 9727", "adoption": { "by": null, "level": "unmeasured", "probe_run": null }, "aliases": [ "api-catalog" ], "analog": "sitemap.xml, but for APIs instead of pages", "collisions": [ "Not to be confused with the ARD ecosystem's ai-catalog.json well-known file (see ard), a different, agent-specific well-known artifact with no normative relationship to this RFC" ], "discovery": { "mechanism": "well-known URI plus an 'api-catalog' HTTP Link header / HTML link relation", "path": "/.well-known/api-catalog" }, "dispute": null, "evidence": [ { "claim": "RFC 9727 (June 2025, Standards Track, sole author Kevin Smith/Vodafone) defines the api-catalog well-known URI and link relation; a publisher MUST resolve GET /.well-known/api-catalog to an API catalog document in the Linkset format (application/linkset+json per RFC 9264), and MAY additionally offer other formats via content negotiation or a different hosting location signposted by the api-catalog link relation.", "date": "2025-06", "label": "VERIFIED", "url": "https://www.rfc-editor.org/rfc/rfc9727.html" }, { "claim": "IANA's Well-Known URIs registry (fetched 2026-09-06) lists \"api-catalog\" as a permanent registration, reference RFC9727, change controller IETF, registered 2024-12-23 -- independent confirmation that this well-known path is formally registered and not merely proposed in the RFC text.", "date": "2026-09-06", "label": "VERIFIED", "url": "https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml" } ], "form": "well-known-file", "governance": "IETF; published as a Standards Track RFC with the IETF as change controller", "group": null, "history": [ { "date": "2026-09-06", "note": "new record created from the occupant-diff candidate list; verified against RFC 9727 text via rfc-editor.org" }, { "date": "2026-09-06", "note": "fix round 1: added second evidence entry (IANA Well-Known URIs registry, fetched directly) confirming permanent registration" } ], "id": "api-catalog-rfc9727", "implementation": "unknown", "last_verified": "2026-09-06", "name": "api-catalog: A Well-Known URI and Link Relation to Help Discovery of APIs", "native_status": "Proposed Standard (errata exist)", "origin": { "date": "2025-06", "org": "Vodafone (Kevin Smith)" }, "part_of": null, "parties": [ "agent-site" ], "phase": "stable", "probe": { "method": "GET", "on_absent": "Publisher does not expose an RFC 9727 API catalog at the well-known location; check for an 'api-catalog' Link header or on the site's root response instead, since the RFC allows the catalog to live at any URI the publisher chooses", "parse": "200 response with Content-Type application/linkset+json, body containing a top-level \"linkset\" array whose entries carry \"item\" (or other) link relations to API endpoints; a HEAD request instead returns a Link header with rel=api-catalog", "path": "https://{origin}/.well-known/api-catalog" }, "question": "Given a publisher's domain, where is the machine-readable list of the APIs it exposes?", "scope": "general", "spec_url": "https://www.rfc-editor.org/rfc/rfc9727.html", "step": "discover", "summary_md": "RFC 9727 defines the \"api-catalog\" well-known URI and a matching \"api-catalog\" link relation, intended to facilitate automated discovery of a Publisher's APIs [1]. It is a Standards Track IETF RFC, published June 2025, with the IETF itself as change controller and a single named author, Kevin Smith of Vodafone [1]. It predates the current wave of agent-discovery specifications (ARD, DNS-AID, AID, ADP, ARDP, ADS) by roughly a year, and is not agent-specific: it is a general web-API discovery mechanism that this map's occupant-diff process flagged as relevant because it addresses the same \"where are this domain's machine-callable capabilities\" question the agentic-web specs are now re-solving with different formats.\n\nIt solves API discovery for a domain's own APIs: a publisher hosts a document at `/.well-known/api-catalog` (or elsewhere, pointed to by the link relation) listing hyperlinks to its API endpoints, in the mandatory Linkset format (`application/linkset+json`, itself defined by RFC 9264) [1]. A GET request must return the catalog document; a HEAD request must return a `Link` header carrying the relation [1]. The catalog can nest -- one api-catalog document can point to others via further `api-catalog`-relation links -- which the RFC recommends for publishers with APIs spread across multiple domains or too many APIs for one flat list [1]. Publishers already using a different catalog format (APIs.json, RESTdesc, HAL, or a schema.org WebAPI extension) may keep it and additionally expose a minimal Linkset-format catalog to satisfy this RFC, using content negotiation to serve either [1].\n\nIt does not mandate any particular path for the API endpoints themselves, does not require the catalog to be hosted on the same domain it describes (a publisher can point to a third party's catalog for APIs it does not control), and does not define authentication, versioning policy, or any agent-specific semantics -- it is a pure discovery/link-relation mechanism aimed at human developers and their tooling, not agents specifically [1]. Security guidance is largely operational: use TLS, avoid leaking internal/private APIs into a public catalog, and rate-limit the endpoint [1].\n\nCurrent state: RFC 9727 is a published Proposed Standard with known errata on file at the RFC Errata system, and carries no revision history beyond the original June 2025 text and its errata [1]. No independent adoption count was located during this verification pass -- the RFC's own text does not claim any deployments, and no third-party survey was found in the sources read.\n\nWhat is disputed or unknown: whether this general-purpose, agent-agnostic mechanism will be adopted, ignored, or superseded by the newer agent-specific well-known conventions (ARD's ard.json, ADP's agent.json) that solve an overlapping but not identical problem -- API discovery generically versus agentic-resource discovery specifically -- and whether any publisher serves both `/.well-known/api-catalog` and one of the newer agent-specific manifests at the same origin.", "track": "ietf", "version": { "date": "2025-06", "label": "RFC 9727" } }, { "acronym": "RSL", "adoption": { "by": null, "level": "unmeasured", "probe_run": null }, "aliases": [], "analog": "Creative Commons license badge, but machine-enforceable and priced", "collisions": [], "discovery": { "mechanism": "robots.txt reference, HTML , RSS/HTTP header, or a standalone rsl.xml file", "path": "/rsl.xml" }, "dispute": null, "evidence": [ { "claim": "The RSL 1.0 specification, Document RSL-SPEC-1.0, Category 'Industry Specification', Status 'Recommendation', was published 2025-12-10 at the canonical URI/namespace https://rslstandard.org/rsl, with editors from RSL Collective, Condé Nast, Ziff Davis, Schema.org, Yahoo, Automattic, O'Reilly Media, and Fastly, and an issue tracker at github.com/rslstandard/rsl.", "date": "2025-12-10", "label": "VERIFIED", "url": "https://rslstandard.org/rsl" }, { "claim": "The rslstandard/rsl GitHub repository's README independently describes RSL as an open XML-based standard maintained by the RSL Technical Steering Committee, corroborating the spec page's own claims about scope and governance from a second, separately-hosted source, and states the specification's status as 'draft' at the repository level.", "date": null, "label": "VERIFIED", "url": "https://github.com/rslstandard/rsl" } ], "form": "document-format", "governance": "RSL Collective, a vendor consortium; issue tracker at github.com/rslstandard/rsl", "group": null, "history": [ { "date": "2026-09-06", "note": "created and verified against rslstandard.org/rsl (occupant-diff candidate)" } ], "id": "rsl", "implementation": "shipping", "last_verified": "2026-09-06", "name": "Really Simple Licensing", "native_status": "Recommendation (RSL's own maturity label, not a W3C/IETF Recommendation) — Document RSL-SPEC-1.0, Category 'Industry Specification'", "origin": { "date": "2025-09", "org": "RSL Collective (with Condé Nast, Ziff Davis, Yahoo, Automattic, O'Reilly Media, Fastly, and Schema.org's RV Guha as editors)" }, "part_of": null, "parties": [ "agent-site", "agent-payment" ], "phase": "stable", "probe": { "method": "GET", "on_absent": "No RSL license file is referenced from any of robots.txt, HTML, RSS, or HTTP headers; the site has not published RSL terms", "parse": "Look for an RSL reference line in robots.txt (pointing to an rsl.xml license file), or an HTML element with an RSL relation, or a Content-License/Link HTTP header; then GET the referenced XML document and parse the root element for , , or children", "path": "{origin}/robots.txt" }, "question": "What machine-readable license, price, and authorization terms govern how AI systems and crawlers may access or reuse a publisher's content?", "scope": "general", "spec_url": "https://rslstandard.org/rsl", "step": "permit", "summary_md": "Really Simple Licensing (RSL) is an XML vocabulary and set of discovery/authorization mechanisms, published as RSL 1.0 (Document RSL-SPEC-1.0) on 2025-12-10 by the RSL Collective together with named editors from Condé Nast, Ziff Davis, Yahoo, Automattic, O'Reilly Media, Fastly, and Schema.org's RV Guha [1]. It answers the permit question at a finer grain than robots.txt or a bare AI-use preference: it lets a publisher declare not just whether AI systems and crawlers may access or process content, but under what license, for what purposes (indexing, search summaries, AI training, grounding), and at what price.\n\nThe spec bundles four pieces: the core RSL XML vocabulary for expressing usage, licensing, payment, and legal rules; the Open License Protocol (OLP), an OAuth 2.0 extension for acquiring and validating an RSL license at request time; the Crawler Authorization Protocol (CAP), an HTTP authorization scheme for crawlers holding a license; and the Encrypted Media Standard (EMS), a format for encrypting paywalled assets so unlicensed reuse is technically, not just contractually, blocked [1]. Discovery works through robots.txt references, HTML elements, RSS entries, or HTTP files, pointing to an RSL XML license document; an example in the spec shows a publisher prohibiting all AI use (`ai-all`) while still allowing search indexing [1].\n\nIt does not itself provide agent identity or content delivery; those integrate via OLP/CAP with whatever identity and hosting stack a publisher already runs. It is explicitly an industry specification governed by a vendor consortium (the RSL Collective), not a submission to IETF or W3C — its own document header labels it Category 'Industry Specification', Status 'Recommendation' in RSL's own maturity scale, which should not be read as a W3C/IETF Recommendation.\n\nAs of this verification (2026-09-06), RSL 1.0 is current, superseding a 0.9 version referenced from the spec page, with an active GitHub issue tracker and a published errata page — signs of a maintained, living specification rather than a one-off announcement [1]. Given the roster of major media-industry editors (Condé Nast, Ziff Davis, Yahoo, O'Reilly), implementation is recorded as shipping on the publisher side, though this pass did not run a probe to count adoption, so the adoption level is unmeasured rather than claimed or measured.\n\nWhat is unresolved: how many publishers have actually deployed an rsl.xml file versus simply being named as spec editors; whether any AI vendor has implemented the OLP client side to actually acquire and pay for a licensed RSL grant; and how RSL's paid-licensing model will coexist with the free, binary-only permission signals of AIPREF and Cloudflare's Content Signals Policy, which address the same robots.txt real estate with a simpler yes/no vocabulary.", "track": "vendor-consortium", "version": { "date": "2025-12-10", "label": "RSL 1.0" } }, { "acronym": "", "adoption": { "by": null, "level": "unmeasured", "probe_run": null }, "aliases": [], "analog": "robots.txt, but for in-page actions rather than URL fetches", "collisions": [], "discovery": { "mechanism": "well-known file, overridable per-page by an HTML element", "path": "/.well-known/agent-permissions.json" }, "dispute": null, "evidence": [ { "claim": "The las-wg/agent-permissions.json GitHub repository publishes a complete JSON Schema (metadata, strict default, resource_rules with an enumerated verb list including read_content/click_element/submit_form/execute_script/upload_file, action_guidelines with RFC 2119 directives, and an api block referencing OpenAPI/MCP/A2A endpoints), discoverable at /.well-known/agent-permissions.json or via a tag.", "date": "2026-07-17", "label": "VERIFIED", "url": "https://github.com/las-wg/agent-permissions.json" }, { "claim": "An arXiv paper by the Lightweight Agent Standards Working Group, 'Permission Manifests for Web Agents,' independently describes the same manifest structure, discovery paths, and positions it against MCP/A2A and OpenAPI as complementary rather than competing.", "date": "2026-01", "label": "VERIFIED", "url": "https://arxiv.org/html/2601.02371v2" } ], "form": "well-known-file", "governance": "Lightweight Agent Standards Working Group (LAS-WG), an open community project hosted on GitHub at las-wg/agent-permissions.json; no formal standards-body affiliation found", "group": null, "history": [ { "date": "2026-09-06", "note": "created and verified against github.com/las-wg/agent-permissions.json and arxiv.org/html/2601.02371v2 (occupant-diff candidate)" } ], "id": "agent-permissions-json", "implementation": "unknown", "last_verified": "2026-09-06", "name": "agent-permissions.json", "native_status": "v1.0.0, complete JSON Schema published; described by the working group's own arXiv paper as a proposal, not an adopted standard", "origin": { "date": "2026-07", "org": "Lightweight Agent Standards Working Group (LAS-WG)" }, "part_of": null, "parties": [ "agent-site" ], "phase": "candidate", "probe": { "method": "GET", "on_absent": "No agent-permissions.json at the well-known path; also check the page's HTML for a override before concluding the site has not published page-action permissions", "parse": "Valid JSON with top-level 'metadata' (schema_version, last_updated) and 'strict' boolean fields present, per the LAS-WG JSON Schema", "path": "{origin}/.well-known/agent-permissions.json" }, "question": "Which page-level interactions (clicking, form submission, file upload, media control, script execution) may an agent perform while driving a web page's UI, as opposed to just fetching it?", "scope": "general", "spec_url": "https://github.com/las-wg/agent-permissions.json", "step": "permit", "summary_md": "agent-permissions.json is a JSON manifest format, published at v1.0.0 by the Lightweight Agent Standards Working Group (LAS-WG), that lets a website declare which in-page interactions an AI agent driving its UI may or may not perform [1]. It targets a permit-layer gap that robots.txt and AIPREF/Content-Signals leave open: those govern whether a URL may be fetched and what a fetched page's content may be used for, but say nothing about what an agent already on the page is allowed to click, type into, submit, upload, or execute once it is rendering and interacting with the DOM directly, as browser-using agents increasingly do [2].\n\nThe schema, fully published in the repository, defines a top-level `strict` boolean setting the default posture (forbid-by-default vs. allow-by-default), an array of `resource_rules` scoping specific verbs (from a fixed enum including read_content, click_element, submit_form, execute_script, upload_file, and others) to CSS selectors with optional rate-limit/time-window/human-in-the-loop modifiers, a set of `action_guidelines` expressed as RFC 2119 MUST/SHOULD directives for behaviours too fuzzy to capture as selector rules, and an `api` block that points an agent toward an OpenAPI, MCP, or A2A endpoint as a preferred alternative to driving the UI at all [1][2]. It is discoverable at the fixed path `/.well-known/agent-permissions.json` or overridden per-page via an HTML `` tag.\n\nIt does not govern whether a URL may be crawled in the first place (robots.txt's job), does not define content-use-after-fetch permissions (AIPREF/Content Signals' job), and does not define authentication or payment. Governance is informal: LAS-WG presents itself as an open working group with a GitHub org and a companion arXiv paper, not a submission to IETF, W3C, or any chartered standards body, and no version history beyond 1.0.0 (published 2026-07-17) was found in this pass.\n\nAs of this verification (2026-09-06), the spec text and JSON Schema are complete and internally consistent across both the GitHub repository and the independently-hosted arXiv paper, which is enough for two independent primary sources; however, this pass found no production website actually serving a live agent-permissions.json file, and no browser-agent product (e.g. a computer-use or browsing agent framework) documented as consuming it, so implementation is recorded as unknown rather than shipping or none-found. What is unresolved: whether LAS-WG has any institutional backing beyond its own GitHub organization; whether any of the browser-driving agent vendors (OpenAI Operator-style agents, Anthropic computer use, browser extensions) have committed to reading this file; and how it will interact with the pre-existing, differently-scoped `agents.json` API-discovery convention it explicitly distinguishes itself from in its own comparison table.", "track": "community", "version": { "date": "2026-07-17", "label": "1.0.0" } }, { "acronym": "", "adoption": { "by": "auth-md.com, which lists Resend, Cloudflare, Firecrawl, Ora.ai, here.now, mailbox.bot, agents-txt.com, WorkOS, and Alpic as 'already supported' adopters", "level": "claimed", "probe_run": null }, "aliases": [], "analog": "Self-service sign-up form", "collisions": [ "Not to be confused with the unrelated ACT-AUTH.md convention published in the actcore/act-spec repository, which addresses similar ground independently" ], "discovery": { "mechanism": "A markdown convention file at the site root, cross-referenced with RFC 9728 Protected Resource Metadata for the actual OAuth exchange", "path": "/auth.md" }, "dispute": null, "evidence": [ { "claim": "auth-md.com's own specification page defines three registration flows (identity_assertion + ID-JAG, service_auth, anonymous), a discovery sequence built on RFC 9728 Protected Resource Metadata and RFC 8414 Authorization Server Metadata, and states the protocol was launched at MCP Night 4 / AI Engineer World's Fair 2026.", "date": "2026-06", "label": "VERIFIED", "url": "https://auth-md.com/specification" }, { "claim": "The auth-md.com homepage names Resend, Cloudflare, Firecrawl, Ora.ai, here.now, mailbox.bot, agents-txt.com, WorkOS, and Alpic as parties already publishing an auth.md file, each linked to that company's own /auth.md URL.", "date": "2026-06", "label": "REPORTED", "url": "https://auth-md.com/" } ], "form": "document-format", "governance": "Single vendor (auth-md.com, associated with WorkOS and founder Fabricio Telles); adopted by several named third parties (Resend, Cloudflare, Firecrawl, Alpic, here.now, mailbox.bot) who each publish their own auth.md file", "group": null, "history": [ { "date": "2026-09-06", "note": "created and verified against auth-md.com/specification and auth-md.com (occupant-diff candidate)" } ], "id": "auth-md", "implementation": "multi-implementation", "last_verified": "2026-09-06", "name": "auth.md", "native_status": "Published protocol specification at auth-md.com/specification; not submitted to IETF, W3C, or any standards body", "origin": { "date": "2026-06", "org": "WorkOS (auth-md.com), publicly launched at MCP Night 4 / AI Engineer World's Fair 2026" }, "part_of": null, "parties": [ "agent-site" ], "phase": "draft", "probe": { "method": "GET", "on_absent": "No auth.md file at the site root; the service has not published an agent self-registration convention", "parse": "A markdown document describing one or more of the three named flows (identity_assertion, service_auth, anonymous) and referencing /.well-known/oauth-protected-resource and /.well-known/oauth-authorization-server per RFC 9728/8414", "path": "{origin}/auth.md" }, "question": "How does an AI agent register a new account for its user on a service, without a human filling out a sign-up form or an OAuth redirect flow existing to authorize it?", "scope": "general", "spec_url": "https://auth-md.com/specification", "step": "permit", "summary_md": "auth.md is a single-vendor protocol, launched by WorkOS-affiliated auth-md.com at MCP Night 4 during the AI Engineer World's Fair 2026, that lets an AI agent register a new user account on a service directly, without a human filling out a sign-up form or an existing OAuth client registration [1]. It targets a specific gap in the permit space: existing OAuth flows assume a client and a resource server already have a trust relationship (a registered client_id); auth.md instead lets a never-before-seen agent discover how to create that relationship in the first place.\n\nThe published specification defines three registration flows: an 'identity_assertion' flow where the agent's own identity provider vouches for the user via an ID-JAG (an emerging IETF identity-assertion mechanism) and registration completes with no human present; a 'service_auth' flow; and an 'anonymous' flow using an OTP the human reads back to the agent to bind the new account to the right person [1]. auth.md is explicitly built as a thin composition layer on top of two existing IETF specs rather than a replacement for OAuth: discovery starts from a 401 response whose `WWW-Authenticate` header points to RFC 9728 Protected Resource Metadata at `/.well-known/oauth-protected-resource`, which in turn points to RFC 8414 Authorization Server Metadata [1].\n\nIt does not define payment (the vendor's own materials pair it with x402 for that), and it does not define content-use permissions — its scope is strictly account creation. It is not on any standards track; auth-md.com is a commercial site operated in connection with WorkOS and credits an individual founder, Fabricio Telles.\n\nAs of this verification (2026-09-06), the specification text is published and internally coherent, and the vendor's own homepage names nine companies as already serving their own auth.md file (Resend, Cloudflare, Firecrawl, Ora.ai, here.now, mailbox.bot, agents-txt.com, WorkOS, and Alpic), each linked to that company's specific URL [2]. Because this adoption count is self-reported by auth-md.com rather than independently measured by this wiki's own probe, the adoption level is recorded as claimed (by auth-md.com), not measured; implementation is recorded as multi-implementation on the strength of multiple named, independent adopting companies, though this pass did not fetch each named company's individual /auth.md file to confirm live service.\n\nWhat is unresolved: whether ID-JAG, the identity-assertion mechanism the strongest flow depends on, is itself standardized enough to interoperate across identity providers (it is described here as 'an emerging IETF draft'); how widely auth.md is adopted beyond the launch partners named on its own site; and how it will be distinguished in practice from the unrelated, independently-developed ACT-AUTH.md convention found in the actcore/act-spec repository, which addresses similar agent-credential ground under the same filename pattern.", "track": "single-vendor", "version": { "date": "2026-06", "label": "Launched 2026-06, current spec undated beyond launch" } }, { "acronym": "", "adoption": { "by": null, "level": "unmeasured", "probe_run": null }, "aliases": [ "RFC 9728", "RFC 8414", "PRM", "AS Metadata" ], "analog": "A site's published API documentation entry point, made machine-readable", "collisions": [], "discovery": { "mechanism": "well-known files at the resource server and the authorization server, chained by a WWW-Authenticate challenge", "path": "/.well-known/oauth-protected-resource" }, "dispute": null, "evidence": [ { "claim": "RFC 9728, 'OAuth 2.0 Protected Resource Metadata,' is an Internet Standards Track document representing IETF consensus, defining a metadata format an OAuth 2.0 client or authorization server uses to learn how to interact with a protected resource.", "date": "2025", "label": "VERIFIED", "url": "https://www.rfc-editor.org/rfc/rfc9728.html" }, { "claim": "RFC 8414, 'OAuth 2.0 Authorization Server Metadata,' published June 2018, is an Internet Standards Track document defining the companion metadata format for an authorization server's own endpoints and capabilities.", "date": "2018-06", "label": "VERIFIED", "url": "https://www.rfc-editor.org/rfc/rfc8414.html" }, { "claim": "The auth.md specification (a distinct, single-vendor agent-registration protocol) documents both RFCs being chained together in a live agent-discovery flow: a 401's WWW-Authenticate header points to RFC 9728 Protected Resource Metadata, which points to RFC 8414 Authorization Server Metadata.", "date": "2026-06", "label": "REPORTED", "url": "https://auth-md.com/specification" } ], "form": "well-known-file", "governance": "IETF OAuth Working Group; both are Internet Standards Track RFCs with IETF/IESG consensus", "group": null, "history": [ { "date": "2026-09-06", "note": "created and verified against rfc-editor.org/rfc/rfc9728.html and rfc-editor.org/rfc/rfc8414.html (occupant-diff candidate)" } ], "id": "oauth-metadata-for-agents", "implementation": "multi-implementation", "last_verified": "2026-09-06", "name": "OAuth Protected Resource and Authorization Server Metadata (as used for agent authorization)", "native_status": "Internet Standard (RFC 8414, published June 2018) and Internet Standard (RFC 9728, published 2025); both are products of IETF consensus, not works in progress", "origin": { "date": "2018-06", "org": "IETF OAuth Working Group" }, "part_of": null, "parties": [ "agent-site" ], "phase": "stable", "probe": { "method": "GET", "on_absent": "Resource server does not publish RFC 9728 Protected Resource Metadata; an agent must fall back to a 401 response's WWW-Authenticate header (if present) or vendor-specific documentation to find the authorization server", "parse": "A JSON document per RFC 9728 with a 'resource' field and an 'authorization_servers' array; follow the first authorization_servers entry to {authorization_server}/.well-known/oauth-authorization-server per RFC 8414 to fetch endpoint and capability metadata", "path": "{resource_server}/.well-known/oauth-protected-resource" }, "question": "How does an agent (or an MCP client acting for it) discover which authorization server protects a resource, and what that authorization server's endpoints and capabilities are, before requesting access?", "scope": "general", "spec_url": "https://www.rfc-editor.org/rfc/rfc9728.html", "step": "permit", "summary_md": "This record covers the pairing of RFC 8414 (OAuth 2.0 Authorization Server Metadata, published June 2018) and RFC 9728 (OAuth 2.0 Protected Resource Metadata, published 2025), as they are increasingly cited together as the discovery backbone for AI agent authorization, including by the MCP authorization specification and by newer conventions such as auth.md [1][2][3]. Both are mature, Internet Standards Track IETF RFCs, not agent-specific drafts — this record exists because their combination has become a de facto permit-discovery mechanism for the agentic web, not because either RFC was written with agents specifically in mind.\n\nRFC 8414 defines a JSON metadata document, conventionally at `/.well-known/oauth-authorization-server`, listing an authorization server's endpoints (authorization, token, etc.) and supported capabilities (grant types, scopes, PKCE support, and so on) so a client can configure itself without hardcoded assumptions [2]. RFC 9728, the newer companion, defines the resource-server side: a JSON document, conventionally at `/.well-known/oauth-protected-resource`, naming which authorization server(s) protect a given resource and what scopes it supports, closing the gap where a client encountering an unfamiliar API had no standard way to learn which authorization server to talk to [1]. Chained together — typically triggered by a 401 response whose `WWW-Authenticate` header names the Protected Resource Metadata URL — an agent can go from 'I got denied access to this API' to 'here is the authorization server and its capabilities' with two GET requests and no prior configuration [3].\n\nNeither RFC defines agent identity, delegation semantics, or content-use permissions; they are pure discovery/metadata mechanisms that any OAuth 2.0 client, human-driven or agentic, can use. This is why several of the newer, more agent-specific drafts in this dataset (auth.md, and indirectly DAAP and AAP, which build on standard OAuth server metadata rather than defining their own) lean on these two RFCs as their discovery layer rather than reinventing one.\n\nAs of this verification (2026-09-06), both documents are final, numbered RFCs on the Standards Track, so phase is stable and there is no version-in-flux to track. Implementation is recorded as multi-implementation on the strength of RFC 8414's seven-plus years of adoption across the OAuth ecosystem (essentially every major identity provider implements it) and RFC 9728's growing adoption for resource servers, including its explicit use in the MCP authorization specification. What is unresolved: this record does not independently measure what fraction of AI-agent-facing APIs specifically (as opposed to OAuth generally) publish RFC 9728 metadata; that would require a dedicated probe run against a domain sample of agent-facing services.", "track": "ietf", "version": { "date": "2025", "label": "RFC 8414 (2018-06) and RFC 9728 (2025)" } }, { "acronym": "", "adoption": { "by": null, "level": "observed", "probe_run": null }, "aliases": [], "analog": "The original robots.txt User-agent convention, extended per-vendor for AI", "collisions": [], "discovery": { "mechanism": "User-agent group directives inside robots.txt, one group per named crawler token", "path": "/robots.txt" }, "dispute": null, "evidence": [ { "claim": "OpenAI's own bot documentation (developers.openai.com/api/docs/bots) names OAI-SearchBot, OAI-AdsBot, and GPTBot with distinct user-agent strings and published IP ranges, and recommends site owners control each via robots.txt.", "date": "2026", "label": "VERIFIED", "url": "https://developers.openai.com/api/docs/bots" }, { "claim": "Anthropic's support article names three distinct robots — ClaudeBot (training), Claude-User (user-triggered access), and Claude-SearchBot (search quality) — and documents what disabling each one via robots.txt does.", "date": "2026", "label": "VERIFIED", "url": "https://support.claude.com/en/articles/8896518" }, { "claim": "Google's documentation states that Google-Extended is a standalone robots.txt product token controlling only Gemini model training/grounding and Vertex AI, and explicitly states it has no effect on Google Search or other Google products, confirming it is distinct from the Googlebot token.", "date": "2026", "label": "VERIFIED", "url": "https://developers.google.com/search/docs/crawling-indexing/google-common-crawlers" }, { "claim": "Perplexity's crawler documentation names PerplexityBot (crawling/training) and Perplexity-User (live user-query-triggered fetches, explicitly not used for crawling or training) as separate tokens with separate published IP ranges.", "date": "2026", "label": "VERIFIED", "url": "https://docs.perplexity.ai/guides/bots" } ], "form": "well-known-file", "governance": "No single governing body; each vendor unilaterally defines and documents its own token(s); RFC 9309 (IETF, Standards Track) governs the underlying robots.txt syntax all of them use", "group": null, "history": [ { "date": "2026-09-06", "note": "created and verified against developers.openai.com/api/docs/bots, support.claude.com/en/articles/8896518, developers.google.com/search/docs/crawling-indexing/google-common-crawlers, docs.perplexity.ai/guides/bots (occupant-diff candidate)" } ], "id": "ai-crawler-tokens-robots", "implementation": "multi-implementation", "last_verified": "2026-09-06", "name": "AI Crawler User-Agent Tokens in robots.txt", "native_status": "A convention, not a formal spec; each vendor's documentation is normative only for that vendor's own crawler", "origin": { "date": "2023", "org": "Multiple vendors (OpenAI, Anthropic, Google, Perplexity, and others), each publishing independently, built on the RFC 9309 Robots Exclusion Protocol" }, "part_of": null, "parties": [ "agent-site" ], "phase": "living", "probe": { "method": "GET", "on_absent": "No group for a given token means that crawler applies its default (documented per-vendor, typically full access) rather than an explicit restriction", "parse": "Look for User-agent groups matching known tokens: GPTBot, OAI-SearchBot, OAI-AdsBot (OpenAI); ClaudeBot, Claude-User, Claude-SearchBot (Anthropic); Googlebot, Google-Extended (Google); PerplexityBot, Perplexity-User (Perplexity); then read the allow/disallow rules in that group", "path": "{origin}/robots.txt" }, "question": "Which named AI crawler or agent user-agent tokens may a website allow or disallow in robots.txt, and what does each token actually control (search indexing, AI training, or live user-triggered fetches)?", "scope": "general", "spec_url": "https://www.rfc-editor.org/rfc/rfc9309.html", "step": "permit", "summary_md": "This record covers the most widely deployed permit mechanism on the web today: a family of vendor-specific user-agent tokens that AI companies define for use inside a site's existing robots.txt file, built on the IETF's RFC 9309 Robots Exclusion Protocol syntax. It is not a single spec but a convention each vendor documents and maintains independently, unified only by shared syntax (User-agent groups with allow/disallow rules) [OpenAI, Anthropic, Google, Perplexity docs below].\n\nFour major vendors were checked directly for this record. OpenAI documents GPTBot (training data collection), OAI-SearchBot (search indexing), and OAI-AdsBot (ad-related validation), each with its own user-agent string and published IP range for verification [1]. Anthropic documents ClaudeBot (training-data collection), Claude-User (fetches triggered by a live user question to Claude), and Claude-SearchBot (search-quality crawling), explaining separately what disabling each one via robots.txt does to a site's treatment [2]. Google documents the long-standing Googlebot token alongside the AI-specific Google-Extended token, and is explicit that Google-Extended controls only training data for Gemini models and Vertex AI grounding, with 'no effect on Google Search or other products' — confirming, directly from Google's own text, the prior finding that Google-Extended does not control Search or AI Overviews [3]. Perplexity documents PerplexityBot (crawling for its models) and Perplexity-User, which it states explicitly 'is not used for web crawling or to collect content for training AI foundation models' but instead fetches pages live in response to a user's question [4].\n\nThe pattern across all four vendors is the same: a 'bulk crawling / training' token and a separate 'live, user-triggered fetch' token, plus sometimes a third 'search index' token, each independently blockable. This granularity is exactly the gap the IETF AIPREF drafts and Cloudflare's Content Signals Policy are trying to standardize into a single, vendor-neutral vocabulary — today, a publisher who wants to block AI training but keep search visibility must maintain a separate robots.txt group per vendor, using each vendor's own token names, rather than one general-purpose signal.\n\nAs of this verification (2026-09-06), all four vendor documentation pages were live and internally consistent with each other's pattern. No unified registry of every AI crawler token across every vendor (beyond each vendor's own page) was checked in this pass; adoption is recorded as observed, since the tokens themselves are demonstrably deployed by name-brand vendors and honoured by a large fraction of the web's robots.txt files, but no systematic probe run counted that fraction for this record. What is unresolved: whether the IETF AIPREF or Cloudflare Content Signals conventions will eventually consolidate these per-vendor tokens into one general vocabulary, or whether new AI companies will simply keep adding their own named tokens to this already-fragmented list.", "track": "vendor-consortium", "version": { "date": null, "label": "Ongoing; tokens and their scopes are updated by each vendor independently" } }, { "acronym": "MCP Apps", "adoption": { "by": null, "level": "observed", "probe_run": null }, "aliases": [ "ext-apps", "Model Context Protocol UI Extension" ], "analog": "An iframe-embedded widget returned by a web API, rendered inline by the calling app", "collisions": [ "MCP-UI (a separately-branded client SDK that implements this spec)" ], "discovery": { "mechanism": "A tool's definition declares a ui:// resource; the host fetches it via the standard MCP resources/read call after a tool call, rather than via a separate well-known path", "path": "ui:// (declared per-tool, not a fixed site-wide path)" }, "dispute": null, "evidence": [ { "claim": "Canonical repo github.com/modelcontextprotocol/ext-apps (Apache-2.0 license, 2.8k stars, 666 commits, latest commit 2026-08-12): 'MCP Apps extend the Model Context Protocol by letting tools declare UI resources' via a 4-step flow (tool definition, tool call, host renders in a sandboxed iframe, bidirectional communication via notifications/tool calls). Spec file at specification/2026-01-26/apps.mdx. Supported clients listed in the repo's badges/table include ChatGPT, Claude, and VS Code, each linking to first-party docs for building MCP Apps in that client.", "date": "2026-09-05", "label": "VERIFIED", "url": "https://github.com/modelcontextprotocol/ext-apps" }, { "claim": "MCP-UI (github.com/MCP-UI-Org/mcp-ui) describes itself as 'an SDK implementing the MCP Apps standard for UI over MCP,' offering a client (@mcp-ui/client) that can render via the MCP Apps AppRenderer or via a legacy UIResourceRenderer for pre-standard MCP-UI hosts — evidence that MCP Apps formalized and superseded an earlier, informally-specified MCP-UI proposal from mid-2025.", "date": "2026-09-05", "label": "VERIFIED", "url": "https://github.com/MCP-UI-Org/mcp-ui" } ], "form": "endpoint", "governance": "modelcontextprotocol GitHub org (ext-apps sub-project); same umbrella as core MCP, which is now stewarded by the Agentic AI Foundation / Linux Foundation per this site's existing 'mcp' record", "group": null, "history": [ { "date": "2026-09-06", "note": "new record: verified against github.com/modelcontextprotocol/ext-apps, its dated spec file, and github.com/MCP-UI-Org/mcp-ui; found via search for other agent-rendered-UI specs during A2UI/AG-UI verification" } ], "id": "mcp-apps", "implementation": "multi-implementation", "last_verified": "2026-09-06", "name": "MCP Apps", "native_status": "Active extension to MCP; own repo describes it as extending 'the Model Context Protocol by letting tools declare UI resources'", "origin": { "date": "2026-01-26", "org": "Model Context Protocol project (Anthropic-originated, now under the same governance umbrella as core MCP)" }, "part_of": null, "parties": [ "agent-human" ], "phase": "candidate", "probe": { "method": "POST", "on_absent": "Server exposes ordinary MCP tools with text/structured-data results only; no interactive UI capability", "parse": "Tool definition metadata includes a ui:// resource reference (or _meta.ui.resourceUri); a follow-up resources/read on that URI returns a resource with mimeType text/html (optionally ;profile=mcp-app)", "path": "{mcp-endpoint} — call tools/list then tools/call on a known MCP server, per JSON-RPC" }, "question": "How does an MCP tool deliver an interactive UI (chart, form, dashboard) that renders inline in a chat client?", "scope": "general", "spec_url": "https://github.com/modelcontextprotocol/ext-apps/blob/main/specification/2026-01-26/apps.mdx", "step": "present", "summary_md": "MCP Apps is an extension to the Model Context Protocol (MCP) that lets an MCP server's tools declare an interactive UI — a chart, form, dashboard, or design canvas — that a compliant chat client renders inline, in the conversation, rather than as plain text or structured JSON. A tool definition declares a `ui://` resource containing bundled HTML/JavaScript; when the LLM calls the tool, the host fetches that resource over the ordinary MCP `resources/read` call and displays it in a sandboxed iframe; a bidirectional channel then lets the host push tool data into the UI via notifications and lets the UI call other MCP tools through the host [1]. It solves the specific gap that 'MCP tools return text and structured data... but not... an interactive UI' [1], and it explicitly targets the same problem A2UI and AG-UI's generative-UI feature address, but scoped to MCP-native tool calls rather than a general-purpose agent-to-frontend event stream.\n\nIt does not define a new transport (it rides on ordinary MCP JSON-RPC), does not specify how a host discovers that a server supports it beyond ordinary MCP capability negotiation and per-tool `ui://` metadata, and does not address payment, identity, or non-MCP agent frameworks.\n\nCurrent state (as of 2026-09-05): the canonical repository is github.com/modelcontextprotocol/ext-apps, Apache-2.0 licensed, with a dated spec file at `specification/2026-01-26/apps.mdx` and a companion blog post on blog.modelcontextprotocol.io dated 2026-01-26 announcing it. The repo shows sustained activity (666 commits, latest merge 2026-08-12, 2.8k stars) and ships an official npm package (`@modelcontextprotocol/ext-apps`) plus a React binding and a server-helpers package. The repo's own README lists ChatGPT, Claude, and VS Code as supported clients, each with first-party integration docs, which is stronger implementation evidence than a single reference build [1]. A separate, earlier community project, MCP-UI (github.com/idosal/mcp-ui, now under the MCP-UI-Org), predates MCP Apps and originally proposed its own `ui://`/`ui-app://` resource convention starting around April 2025; it has since repositioned itself explicitly as 'an SDK implementing the MCP Apps standard,' with a legacy rendering path kept only for pre-standard MCP-UI hosts [2]. The ext-apps repo itself credits MCP-UI's client as 'a fully-featured MCP Apps framework used by a few hosts,' alongside the possibility that a client rolls its own implementation.\n\nWhat is disputed or unknown: this is a new record on agenticweb.wiki, not previously tracked, so there is no prior baseline to compare against. Its governance track is marked 'community' here because the ext-apps repo, while living under the modelcontextprotocol GitHub org, is an 'ext-' (extension) project and it is not yet confirmed whether it has been formally folded into the same Agentic AI Foundation/Linux Foundation governance this site's core `mcp` record cites — that should be checked against MCP's own governance documents on a future pass. No independent, counted adoption figure exists; the evidence here is qualitative (named supported clients, repo activity), not a probe-based census.", "track": "community", "version": { "date": "2026-01-26", "label": "npm package @modelcontextprotocol/ext-apps, spec dated 2026-01-26" } }, { "acronym": "ARS", "adoption": { "by": null, "level": "unmeasured", "probe_run": null }, "aliases": [ "Vercel Agent Readability Spec" ], "analog": "a Lighthouse/PageSpeed-style audit checklist, but scored against agent readability rather than performance", "collisions": [ "Agent-Friendly Documentation Spec (a separate, earlier spec by a different maintainer covering similar ground — see dispute)" ], "discovery": { "mechanism": "none — not a discoverable manifest; it is a checklist a site owner applies to their own pages, verified externally by tools like agent-ready.dev or is-agentic.com", "path": "none" }, "dispute": { "claims": [ "Vercel presents the checklist as authoritative guidance for 'AI-optimized websites'", "dacharycarey.com (maintainer of the Agent-Friendly Documentation Spec) argues platform-written specs like this one should be evaluated skeptically since Vercel both writes the spec and sells the hosting it recommends" ], "summary": "Vercel published this spec without an external standards process or a clear version/date, prompting at least one independent commentator to note it overlaps with, and was not coordinated with, a pre-existing 'Agent-Friendly Documentation Spec' maintained by someone else." }, "evidence": [ { "claim": "Full checklist text: site-level files (llms.txt, robots.txt, sitemap.xml/md, AGENTS.md), page-level HTML requirements (canonical link, meta tags, JSON-LD, heading structure, signal-to-noise ratio), server configuration (markdown mirrors, `Accept: text/markdown` content negotiation, `Link` header canonical), content quality (fenced code blocks, OpenAPI schema links), and the scoring formula", "date": "2026-03", "label": "VERIFIED", "url": "https://vercel.com/kb/guide/agent-readability-spec" }, { "claim": "Independent commentary identifies the author as Timothy Jordan, notes the page carries no publication date and was 'last updated March 23' (2026), and frames it as a competing effort alongside a pre-existing 'Agent-Friendly Documentation Spec' maintained separately", "date": "2026-03-28", "label": "REPORTED", "url": "https://dacharycarey.com/2026/03/28/how-to-evaluate-platform-written-spec/" }, { "claim": "A third-party checker, agent-ready.dev, scores sites specifically 'against the Vercel Agent Readability Spec and llmstxt.org standard', indicating at least one independent implementation of the scoring logic", "date": "2026", "label": "REPORTED", "url": "https://agent-ready.dev/" } ], "form": "document-format", "governance": "Vercel; published in Vercel's own Knowledge Base with no external standards process", "group": null, "history": [ { "date": "2026-09-06", "note": "new record added during read-step verification; verified against vercel.com/kb/guide/agent-readability-spec and independent commentary" } ], "id": "vercel-agent-readability", "implementation": "shipping", "last_verified": "2026-09-06", "name": "Agent Readability Spec", "native_status": "A specification and scoring checklist, not a protocol; framed as best practices to implement voluntarily", "origin": { "date": "2026-03", "org": "Vercel (Timothy Jordan)" }, "part_of": null, "parties": [ "agent-site" ], "phase": "draft", "probe": { "method": "GET", "on_absent": "A site failing most checks is not in violation of anything; the spec is a voluntary readiness checklist, not an enforced requirement", "parse": "No single field proves conformance; the spec defines ~20 discrete site- and page-level checks (llms.txt served, robots.txt allows AI bots, AGENTS.md present, canonical link, JSON-LD, markdown mirrors, Accept: text/markdown negotiation, etc.) each independently verifiable by curl, and a numeric score = round(passed/total * 100)", "path": "{origin}/ (plus /llms.txt, /robots.txt, /sitemap.xml, /sitemap.md, /AGENTS.md as sub-checks; see the spec's own per-requirement curl commands)" }, "question": "How readable is this site's content for AI agents, and what specifically should be fixed?", "scope": "general", "spec_url": "https://vercel.com/kb/guide/agent-readability-spec", "step": "read", "summary_md": "Vercel's Agent Readability Spec is a checklist and 0-100 scoring system for how well a website's content can be discovered, fetched, and understood by AI agents [1]. It groups roughly twenty independently verifiable checks into three areas: discovery (an `llms.txt` file, a permissive `robots.txt`, XML and markdown sitemaps), structure (canonical links, meta tags, Schema.org/JSON-LD, heading hierarchy, text-to-HTML ratio), and context (an `AGENTS.md` skill file, markdown mirrors of HTML pages, `Accept: text/markdown` content negotiation, fenced and language-tagged code blocks, OpenAPI/Swagger schema links) [1].\n\nIt solves the problem of turning \"be agent-friendly\" into a concrete, curl-verifiable punch list: each requirement in the spec ships with an example and a shell command to check it, and site owners get a single percentage score (`passed / total × 100`) they can track over time [1]. Notably, it documents — by name, as Vercel's own recommended practice — serving a markdown alternate for every HTML page and returning it when a client sends `Accept: text/markdown`, with a `Link` header pointing back to the canonical HTML URL [1]. This is the same content-negotiation pattern also described in llms.txt v2's discovery mechanism (see the `llms-txt` record) and is the clearest documented instance of the general \"markdown twin\" practice found during this verification pass.\n\nIt does not solve trust or accuracy: nothing in the spec checks whether the content is correct, and a perfect score says only that a page is structurally easy to fetch and parse, not that an agent's answer using it will be right. It is also not a protocol or a machine-readable manifest — there is no fixed path an agent fetches to learn a site's score; the checklist is meant to be run by (or on behalf of) the site owner, and scoring is reproduced by third-party tools rather than looked up from a canonical registry.\n\nCurrent state, as of this verification (September 2026): the page itself carries no publication date or version number. An independent commentator dated it to \"last updated March 23\" (2026) and noted its author is Timothy Jordan [2]. At least one third-party checker, agent-ready.dev, implements scoring explicitly described as checking a site \"against the Vercel Agent Readability Spec and llmstxt.org standard,\" which is the clearest evidence of independent implementation found [3]; Vercel's own knowledge-base article is the only primary specification text.\n\nWhat is disputed or unknown: the spec was published unilaterally by a hosting vendor, with no external review process, and overlaps substantially with an earlier, separately maintained 'Agent-Friendly Documentation Spec' — a secondary source flagged this as worth scrutinizing given Vercel's commercial interest in the hosting practices the spec implicitly favors (server-rendered pages, content negotiation infrastructure) [2]. No independent adoption count or measurement of how many sites meet a given score threshold was found.", "track": "single-vendor", "version": { "date": "2026-03", "label": "current (last updated 2026-03-23 per a secondary source; no version number or publication date is given on the page itself)" } }, { "acronym": "", "adoption": { "by": null, "level": "unmeasured", "probe_run": null }, "aliases": [ "Wildcard agents.json" ], "analog": "an OpenAPI/Swagger spec, extended with the multi-call recipes a human developer would otherwise write by hand", "collisions": [ "agents.md (unrelated coding-agent instructions file)", "agent.json / agentfile.json (various unrelated agent-config conventions used by other frameworks)" ], "discovery": { "mechanism": "Proposed well-known path, though the spec itself notes providers can maintain files without adopting the path; a discretionary third-party registry also exists", "path": "/.well-known/agents.json (proposed; not mandatory, per the spec's own FAQ)" }, "dispute": null, "evidence": [ { "claim": "agents.json is an OpenAPI-based specification (current version 0.1.0) adding `flows` (multi-call contracts) and `links` (how calls chain together) on top of an existing OpenAPI document; it proposes but does not mandate `/.well-known/agents.json`; and the maintainers explicitly distinguish it from MCP (stateless vs. MCP's stateful connections) and from llms.txt (\"llms.txt ... doesn't address the challenges of taking structured actions\")", "date": "2026", "label": "VERIFIED", "url": "https://raw.githubusercontent.com/wild-card-ai/agents-json/master/README.md" }, { "claim": "The wild-card-ai/agents-json GitHub repository was created 2025-01-30 and last pushed 2026-08-25", "date": "2026-08-25", "label": "VERIFIED", "url": "https://github.com/wild-card-ai/agents-json" }, { "claim": "The spec was publicly announced via a March 2025 'Show HN' post positioning it as an OpenAPI specification for LLMs", "date": "2025-03", "label": "REPORTED", "url": "https://news.ycombinator.com/item?id=43243893" } ], "form": "well-known-file", "governance": "Wildcard AI; single company controls the spec and the reference \"Wildcard Bridge\" runtime and maintains a discretionary registry of published files", "group": null, "history": [ { "date": "2026-09-06", "note": "new record added during read-step verification; reclassified to the act step and verified against the wild-card-ai/agents-json README and repository metadata" } ], "id": "agents-json", "implementation": "prototype", "last_verified": "2026-09-06", "name": "agents.json", "native_status": "\"An open specification\", version 0.1.0 as published by Wildcard", "origin": { "date": "2025-03", "org": "Wildcard AI (wild-card-ai)" }, "part_of": null, "parties": [ "agent-site" ], "phase": "draft", "probe": { "method": "GET", "on_absent": "No agents.json at the well-known path; the provider may still have one published in Wildcard's registry or elsewhere, since the path is a proposal, not a requirement", "parse": "200 response with a JSON body extending an OpenAPI document with `flows` and `links` fields", "path": "{origin}/.well-known/agents.json" }, "question": "How does an agent learn which multi-step API call sequences (\"flows\") a service supports, on top of its raw OpenAPI surface?", "scope": "general", "spec_url": "https://github.com/wild-card-ai/agents-json", "step": "act", "summary_md": "**Moved from the Read step to Act.** agents.json is Wildcard AI's specification for describing multi-step API call sequences (\"flows\") for LLM agents, built as an extension of OpenAPI rather than a competitor to it [1]. It belongs under \"Act\" (do something for me), not \"Read\": its own FAQ explicitly contrasts it with llms.txt — \"llms.txt ... doesn't address the challenges of taking structured actions ... agents.json enables them to execute multi-step workflows reliably\" [1]. It was included in this batch as a read-step candidate but is a discovery-plus-invocation spec for API actions, so it is reported here with a corrected step rather than filed under Read.\n\nWhat it is: a JSON document, structurally an annotated OpenAPI spec, adding two concepts — `flows` (a named sequence of one or more API calls that accomplishes an outcome) and `links` (how the output of one call feeds the input of the next) — so an agent doesn't have to infer multi-call sequences (e.g., \"search Gmail threads, list messages in a thread, reply with base64 RFC 822 content\") from raw endpoint descriptions alone [1]. It proposes, but does not require, publishing the file at `/.well-known/agents.json`, and maintains a discretionary registry of published files at wild-card.ai/registry [1] (not independently verified in this pass). The reference runtime, \"Wildcard Bridge\", is a Python package that loads an agents.json file and executes the described flows with Basic/ApiKey/Bearer auth [1].\n\nWhat it does not do: it is explicitly stateless — orchestration and context are the calling agent's responsibility, not the spec's — and it does not define a serving protocol beyond \"an agent fetches this JSON document\" [1]. It is single-vendor: Wildcard AI controls the spec text, the only public runtime implementation, and the registry.\n\nCurrent state: version 0.1.0, first shown publicly in a March 2025 Hacker News post [3], with the GitHub repository still receiving commits as of August 2026 [2]. No changelog entry or version bump beyond 0.1.0 was found during this pass, and no independent (non-Wildcard) implementation of the spec or the registry was located.\n\nWhat is disputed or unknown: adoption beyond Wildcard's own quickstart examples (Resend, Stripe, Rootly, Twitter+Giphy, and a Resend+Hubspot+Google Sheets demo) is unmeasured; there is no evidence of provider-side publication of agents.json files outside Wildcard's own demos, and the well-known path is explicitly optional per the spec's own FAQ, so counting adoption by well-known-path presence alone would understate or misstate real usage.", "track": "single-vendor", "version": { "date": "2025-03", "label": "0.1.0" } }, { "acronym": "", "adoption": { "by": null, "level": "unmeasured", "probe_run": null }, "aliases": [], "analog": "robots.txt, but declaring which agent protocols a site supports rather than which crawlers may visit", "collisions": [ "Multiple unrelated, mutually incompatible specifications share the \"agents.txt\" name (see dispute): agents-txt.com's v1.0 protocol-declaration format, kaylacar/agents-txt's IETF-draft capability-declaration proposal, agentstxt.dev (a separate proposal whose IETF draft expired 2026-04-10), and the ad hoc allow/rate-limit format described in the arXiv paper 'Towards an Agent-First Web'" ], "discovery": { "mechanism": "Fixed filename at the site root", "path": "/agents.txt (well-known root path per all identified proposals; one proposal also allows /.well-known/agents.txt)" }, "dispute": { "claims": [ "agents-txt.com presents its v1.0 spec as authoritative and interoperable with A2A and RFC 9727", "kaylacar/agents-txt claims IANA filing and an active IETF Internet-Draft", "A Mastercard reference page independently reports the agentstxt.dev IETF draft as expired (2026-04-10) and describes 11+ competing proposals with no ratified standard", "An arXiv paper proposes yet another agents.txt grammar without referencing the others" ], "summary": "\"agents.txt\" names at least four non-converging, mutually incompatible proposals (agents-txt.com's v1.0, kaylacar/agents-txt's IETF-draft capability format, agentstxt.dev's expired-draft format, and an academic paper's own INI-style grammar), none of which has become a ratified or dominant standard." }, "evidence": [ { "claim": "agents-txt.com publishes a v1.0 'agents.txt Standard' spec: a text file at the site root declaring supported protocols (e.g. x402, mpp), with explicit sections relating it to A2A's AgentCard discovery and to RFC 9727's API Catalog", "date": "2026", "label": "VERIFIED", "url": "https://agents-txt.com/spec" }, { "claim": "A separate GitHub proposal, kaylacar/agents-txt, describes itself as an open standard proposal for AI-agent capability declaration via a well-known URI, with IANA numbers #72/#73 'filed, under review' and an IETF Internet-Draft on Datatracker; the repository was created 2026-02-22 and last updated 2026-07-18", "date": "2026-07-18", "label": "VERIFIED", "url": "https://github.com/kaylacar/agents-txt" }, { "claim": "A Mastercard merchant-developer reference page lists agents.txt (at agentstxt.dev, a third distinct effort) as an 'Emerging Standard (Draft)' whose IETF draft expired 2026-04-10, describing 'a fragmented landscape with 11+ competing proposals (agent-manifest.txt, agents-brief.txt, etc.)' and 'no ratified standard' (may require login: HTTP 401 on one check and 200 on another, 2026-09-06)", "date": "2026", "label": "REPORTED", "url": "https://developer.mastercard.com/merchant-cloud/documentation/tutorials-and-guides/agentic-commerce-guide/24/" }, { "claim": "An arXiv paper, 'Towards an Agent-First Web', independently proposes its own agents.txt grammar (INI-style allow/rate-limit/content-format blocks per agent class) served at /.well-known/agents.txt, distinct from the other three", "date": "2026", "label": "VERIFIED", "url": "https://arxiv.org/html/2606.19116v1" } ], "form": "well-known-file", "governance": "None; at least three non-converging proposals (agents-txt.com, kaylacar/agents-txt, agentstxt.dev) each self-describe as \"the\" agents.txt standard, with no shared maintainer or reconciliation process found", "group": null, "history": [ { "date": "2026-09-06", "note": "new record added during read-step verification; reclassified to the discover step after finding the name covers multiple non-converging, competing specifications" } ], "id": "agents-txt", "implementation": "prototype", "last_verified": "2026-09-06", "name": "agents.txt", "native_status": "\"An open standard proposal for declaring what AI agents can do on a website\" (kaylacar/agents-txt); a Mastercard developer-documentation page independently characterizes the space as \"IETF draft expired ... fragmented landscape with 11+ competing proposals ... no ratified standard\"", "origin": { "date": "2026-02-22", "org": "Contested; earliest identified public GitHub proposal is kaylacar/agents-txt" }, "part_of": null, "parties": [ "agent-site" ], "phase": "idea", "probe": { "method": "GET", "on_absent": "No agents.txt at the site root under any of the competing conventions; given the fragmentation, absence is a weak signal either way", "parse": "200 response with a text/plain body listing supported protocols (e.g. `Protocols: x402, mpp`) or per-agent directives, per whichever competing grammar the site chose to implement", "path": "{origin}/agents.txt" }, "question": "Which agent-facing protocols (payments, auth, MCP, skills, A2A) does this site speak, and where?", "scope": "general", "spec_url": "https://agents-txt.com/spec", "step": "discover", "summary_md": "**Moved from the Read step to Discover.** agents.txt is not one specification but a name shared by at least four non-converging proposals for a site-root text file that declares which agent-facing protocols (payments, auth, MCP endpoints, Skills, A2A) a site supports and where to find them [1][2][3][4]. It is filed here under \"Discover\" (what is here, and where?) rather than \"Read\", since every version found declares protocol/capability presence and location, not page content, and one variant (agents-txt.com) explicitly frames itself as complementary to A2A's AgentCard discovery and RFC 9727's API Catalog [1].\n\nWhat it is (per the most detailed version found, agents-txt.com's v1.0): a plain-text file at the site root listing supported protocols, e.g. `Protocols: x402, mpp`, with directives for pointing agents at an A2A AgentCard, an MCP endpoint, or other machine-readable capability declarations [1]. A second, independently maintained proposal (kaylacar/agents-txt) describes a similar but not identical capability-declaration format and claims IANA filing (#72/#73, \"under review\") and an active IETF Internet-Draft [2]. A third effort, agentstxt.dev, is reported by a Mastercard developer-documentation page to have had its IETF draft expire on 2026-04-10, with that same source describing \"a fragmented landscape with 11+ competing proposals ... no ratified standard\" [3]. A fourth, academic proposal in the arXiv paper \"Towards an Agent-First Web\" defines yet another agents.txt grammar (INI-style `[agent-class]` blocks with `allow`/`rate-limit`/`content-format` fields) without referencing any of the other three [4].\n\nIt solves, in principle, the problem of an agent needing to discover a site's supported protocols in one request rather than probing each well-known path individually — a genuine gap, since A2A, MCP, x402, and other protocols each define their own discovery convention but nothing ties them together at a single site level.\n\nIt does not currently solve that problem in practice, because there is no single agents.txt to fetch: an agent cannot know, without trying multiple grammars, which of at least four incompatible conventions (if any) a given site implements. None of the identified efforts has IETF ratification, and the one with the most third-party visibility (agentstxt.dev) had its own draft lapse.\n\nCurrent state, as of this verification (September 2026): earliest dated public artifact found is the kaylacar/agents-txt GitHub repository, created 2026-02-22 and last updated 2026-07-18 [2]; agents-txt.com presents a v1.0 spec text with no stated publication date [1]; the Mastercard reference page's fragmentation characterization is dated to 2026 without a specific day [3]. No implementation count, adopter list, or resolution among the competing proposals was found.\n\nWhat is disputed: everything about precedence, authorship, and which (if any) proposal will consolidate the space. This record should be treated as thin pending a resolution or a dominant implementation emerging.", "track": "community", "version": { "date": null, "label": "agents-txt.com: v1.0; competing proposals carry no shared version" } }, { "acronym": "", "adoption": { "by": null, "level": "unmeasured", "probe_run": null }, "aliases": [], "analog": "robots.txt, extended from crawl permission to AI-specific permissions (training, indexing, caching) with licensing and attribution terms", "collisions": [ "At least four unrelated, mutually incompatible specifications share the \"ai.txt\" name (see dispute): the IETF Internet-Draft draft-car-ai-txt-wellknown (training/scraping/indexing/caching policy), kaylacar/ai-txt (a separate IANA-filed proposal for the same policy domain), the arXiv 'ai.txt: A Domain-Specific Language' paper (Disallow: Return / Disallow: Train directives), and aitxt.ing ('a universal standard for describing any resource to AI assistants', a content-description format unrelated to policy)" ], "discovery": { "mechanism": "Fixed filename at the site root, following the /.well-known/ convention on some proposals", "path": "/ai.txt or /.well-known/ai.txt (varies by proposal)" }, "dispute": { "claims": [ "The IETF draft-car-ai-txt-wellknown Internet-Draft presents itself as the well-known-URI registration proposal for AI usage policy", "kaylacar/ai-txt independently claims its own IANA filing and IETF draft for the same purpose", "The arXiv DSL paper proposes a third, syntactically different grammar for the same policy domain without reconciling with either draft", "aitxt.ing uses the identical filename for a content-description standard unrelated to permissions, which will collide in practice with any site trying to adopt a policy-declaration ai.txt" ], "summary": "\"ai.txt\" is used by at least four unrelated efforts: two independent IETF-style Internet-Drafts covering the same training/scraping/indexing/caching policy domain (draft-car-ai-txt-wellknown and kaylacar/ai-txt), an academic DSL paper covering similar ground with different syntax, and a commercial product (aitxt.ing) that repurposes the name for an unrelated content-description use case." }, "evidence": [ { "claim": "IETF Internet-Draft draft-car-ai-txt-wellknown-00 defines '/ai.txt' as a well-known URI declaring site-wide Training/Scraping/Indexing/Caching defaults (allow/deny/conditional), per-path Training-Allow/Training-Deny overrides, licensing and fee fields, and per-agent blocks (e.g. distinct rules for ClaudeBot vs. GPTBot)", "date": "2026", "label": "VERIFIED", "url": "https://www.ietf.org/archive/id/draft-car-ai-txt-wellknown-00.html" }, { "claim": "A separate GitHub repository, kaylacar/ai-txt, independently proposes 'an open standard proposal for declaring a website's AI policy: training, licensing, attribution, per-agent rules', claiming IANA filing #76/#77 'under review' and an IETF Internet-Draft on Datatracker; created 2026-02-22, last updated 2026-07-18", "date": "2026-07-18", "label": "VERIFIED", "url": "https://github.com/kaylacar/ai-txt" }, { "claim": "An arXiv paper, 'ai.txt: A Domain-Specific Language for Guiding AI Interactions with the Internet', independently defines its own ai.txt DSL with Disallow: Return and Disallow: Train directives, explicitly positioned as an extension of robots.txt's model of declared-not-enforced regulation", "date": "2025", "label": "VERIFIED", "url": "https://arxiv.org/html/2505.07834v1" }, { "claim": "aitxt.ing markets itself as 'a universal standard for describing any resource to AI assistants using plain text, preventing hallucination' — a content-description product, not a policy-permission format, despite sharing the ai.txt name", "date": "2026", "label": "THIN", "url": "https://aitxt.ing/" } ], "form": "well-known-file", "governance": "None; at least three independent proposals for the same policy-declaration purpose (an IETF Internet-Draft by 'car', kaylacar/ai-txt, and an arXiv DSL paper) plus a fourth, differently-scoped product (aitxt.ing) all use the same filename with no shared authority", "group": null, "history": [ { "date": "2026-09-06", "note": "new record added during read-step verification; reclassified to the permit step after finding the name covers multiple unrelated policy proposals plus one unrelated content-description product" } ], "id": "ai-txt", "implementation": "prototype", "last_verified": "2026-09-06", "name": "ai.txt", "native_status": "IETF Internet-Draft (draft-car-ai-txt-wellknown-00) presented as a formal well-known-URI registration proposal; kaylacar/ai-txt separately claims IANA filing (#76/#77, 'under review')", "origin": { "date": "2026-02-22", "org": "Contested; earliest identified dated artifact is the kaylacar/ai-txt GitHub proposal" }, "part_of": null, "parties": [ "agent-site" ], "phase": "idea", "probe": { "method": "GET", "on_absent": "No ai.txt under any identified convention; given active fragmentation and low visibility, absence does not indicate a deliberate policy choice", "parse": "200 response with a text body containing top-level Training/Scraping/Indexing/Caching directives (allow/deny/conditional) and optional per-Agent blocks, per the IETF draft's grammar; other proposals use different field names for the same purpose, or an unrelated content-description grammar (aitxt.ing)", "path": "{origin}/ai.txt" }, "question": "May AI systems train on, scrape, index, or cache this site's content, and under what per-agent or per-path conditions?", "scope": "general", "spec_url": "https://www.ietf.org/archive/id/draft-car-ai-txt-wellknown-00.html", "step": "permit", "summary_md": "**Moved from the Read step to Permit.** ai.txt is not read-step content — every substantive proposal found (excluding the differently-scoped aitxt.ing) is a permissions declaration: whether AI systems may train on, scrape, index, or cache a site's content, comparable to robots.txt extended with AI-specific and licensing semantics [1][2][3]. It is filed here under \"Permit\" (what may the agent do here?) rather than \"Read\", and is reported with this corrected step.\n\nWhat it is, per the most detailed version found (IETF Internet-Draft draft-car-ai-txt-wellknown-00): a text file at `/ai.txt` declaring site-wide defaults for four fields — Training, Scraping, Indexing, Caching — each `allow`/`deny`/(`conditional` for Training only), with path-scoped `Training-Allow`/`Training-Deny` overrides, a `Training-License` and `Training-Fee` for conditional training, and per-agent blocks that can override the defaults for a named bot (e.g. allowing ClaudeBot to train while denying GPTBot) [1]. A second, independently authored proposal, kaylacar/ai-txt, targets the same policy domain (training, licensing, attribution, per-agent rules) and separately claims its own IANA filing and IETF draft [2]. A third, an arXiv-published domain-specific language, defines yet a different syntax (`Disallow: Return`, `Disallow: Train`) for largely the same purpose, explicitly modeled on robots.txt's declared-but-unenforced approach [3].\n\nIt solves, in principle, a real gap: robots.txt has no notion of \"may train on\" versus \"may crawl for search indexing\" versus \"may serve in a live AI answer\", and site owners increasingly want to distinguish these. Per-agent, per-path granularity and an attached licensing/fee mechanism go further than robots.txt's binary allow/disallow.\n\nIt does not currently solve that gap in a way any agent could rely on, because — as with agents.txt — there is no single ai.txt an agent can fetch and trust: at least two IETF-style drafts and one academic DSL independently claim the same well-known filename for the same purpose, with no evidence any converged or even cited one another. A fourth party, aitxt.ing, uses the identical filename for an unrelated content-description product (\"preventing hallucination\" by describing resources to AI assistants), which would collide outright with any site that adopted a policy-declaration ai.txt at the same path [4].\n\nCurrent state, as of this verification (September 2026): the earliest dated artifact identified is the kaylacar/ai-txt repository, created 2026-02-22 [2]; the arXiv DSL paper is dated 2025 [3]; the IETF draft-car draft carries no clear publication date in the fetched text. Enforcement is, by every proposal's own admission, declarative only — like robots.txt, nothing prevents a non-compliant crawler from ignoring the file.\n\nWhat is disputed or unknown: which (if any) proposal has priority, whether any has actual publisher adoption, and how the aitxt.ing name collision would be resolved in practice. This record should be treated as thin and revisited once (or if) one proposal gains distinguishable traction.", "track": "community", "version": { "date": null, "label": "draft-car-ai-txt-wellknown-00" } }, { "acronym": "LMOS", "adoption": { "by": null, "level": "observed", "probe_run": null }, "aliases": [ "Eclipse LMOS", "LMOS Protocol" ], "analog": "UPnP / Matter device discovery, adapted to agents", "collisions": [], "discovery": { "mechanism": "Three-layer protocol: Application layer defines a JSON-LD Agent/Tool Description Format (built on W3C Web of Things Thing Descriptions) plus DNS-SD/mDNS for local discovery and agent registries for global discovery; Identity layer uses W3C Decentralized Identifiers (DIDs) to sign description documents", "path": null }, "dispute": null, "evidence": [ { "claim": "LMOS is an open-source, vendor-neutral platform for multi-agent systems built on Kubernetes, aiming at an 'Internet of Agents' where agents/tools from different organizations can be published, discovered and interconnected; it is a project of the Eclipse Foundation.", "date": "2026-09-06", "label": "VERIFIED", "url": "https://eclipse.dev/lmos/" }, { "claim": "The LMOS Protocol defines a three-layer architecture (Application/discovery+description, Transport, Identity+Security using W3C DIDs), is built on the W3C Web of Things architecture, and is explicitly stated by the project to be 'work in progress and contains empty sections' and 'not a W3C Standard nor on the W3C Standards Track.'", "date": "2026-09-06", "label": "VERIFIED", "url": "https://eclipse.dev/lmos/docs/lmos_protocol/introduction/" }, { "claim": "The eclipse-lmos GitHub organization maintains 15 repositories (LMOS Operator, Runtime, Router, Arc framework, etc.) with recent commit activity (within days of this check), licensed Apache 2.0.", "date": "2026-09-06", "label": "VERIFIED", "url": "https://github.com/eclipse-lmos" } ], "form": "document-format", "governance": "Eclipse Foundation open-source project (Eclipse Public License-compatible governance); code Apache License 2.0; top committer affiliated with Deutsche Telekom (openHAB/Kai Kreuzer lineage); not yet on the W3C standards track", "group": null, "history": [ { "date": "2026-09-06", "note": "added from arXiv 2504.16736 survey comparison, verified against eclipse.dev/lmos/, eclipse.dev/lmos/docs/lmos_protocol/introduction/, github.com/eclipse-lmos" } ], "id": "lmos", "implementation": "shipping", "last_verified": "2026-09-06", "name": "LMOS (Language Model Operating System)", "native_status": "LMOS Protocol spec is explicitly \"work in progress and contains empty sections\"; \"It is not a W3C Standard nor is it on the W3C Standards Track\" (project's own words), though the project states it plans to start the formal W3C process once mature", "origin": { "date": "2024", "org": "Eclipse Foundation (Eclipse LMOS project; primary corporate backer Deutsche Telekom)" }, "part_of": null, "parties": [ "agent-agent", "agent-site" ], "phase": "draft", "probe": { "method": "GET", "on_absent": "No response, or a WoT Thing Description without the LMOS namespace: this origin either doesn't participate in LMOS or (more likely for most origins) simply predates/ignores the still-draft protocol; the LMOS spec itself does not yet fix a single discovery path, so absence here is weak evidence.", "parse": "A JSON-LD document whose @context or @type references the LMOS namespace (https://eclipse.dev/lmos/protocol/v1) confirms an LMOS-described Thing; this well-known path is the W3C WoT discovery convention LMOS explicitly builds on, not yet a path LMOS itself mandates.", "path": "{origin}/.well-known/wot-thing-description" }, "question": "How does an agent or tool from one organization describe itself and get discovered by agents from another organization, across network boundaries?", "scope": "general", "spec_url": "https://eclipse.dev/lmos/docs/lmos_protocol/introduction/", "step": "discover", "summary_md": "LMOS (Language Model Operating System) is an Eclipse Foundation open-source project that defines both a protocol and a cloud-native platform for building an \"Internet of Agents\" (IoA) — an internet-scale multi-agent system where agents and tools from different organizations can be published, discovered, and interconnected regardless of the technology they are built on [1]. The LMOS Protocol itself is the discovery-and-description layer: it standardizes how an agent or tool describes its capabilities in JSON-LD (borrowing the W3C Web of Things Thing Description model), how that description propagates (DNS-SD/mDNS locally, agent registries globally), and how agents authenticate each other using W3C Decentralized Identifiers [2].\n\nIt solves cross-organization agent/tool discovery and description in a transport-agnostic way — the same agent description can be served over HTTP, MQTT, WebSocket or AMQP without changing application logic, echoing how Matter/Thread lets smart-home devices from different vendors interoperate and how ActivityPub lets different social platforms federate [2]. It explicitly does not attempt to be a single fixed transport or wire format: transport selection and negotiation is left to a separate Transport Protocol Layer, and identity/security is a separate layer supporting both DIDs and conventional OAuth2/Bearer schemes [2].\n\nAs of this check (September 2026), the LMOS Protocol specification is, in the project's own words, \"work in progress and contains empty sections\" and is explicitly \"not a W3C Standard nor... on the W3C Standards Track,\" though the project states an intent to pursue formal W3C standardization once the spec matures [2]. This is a meaningfully earlier stage than the platform around it: the surrounding Eclipse LMOS platform (LMOS Operator, Runtime, Router, and the Arc Kotlin DSL framework for building agents) is actively developed, with commits across its 15 repositories within days of this check [3].\n\nGovernance sits with the Eclipse Foundation as an open-source project, with Apache License 2.0 code and Deutsche Telekom's engineering lineage visible in the top-committer history (the project descends from the same team behind openHAB) [3]. Implementations exist — the LMOS Runtime, Operator, and Router are real, shipping Kotlin/Java components integrating with LangChain4j, LlamaIndex, and LangChain — but they are platform components rather than independent third-party implementations of the LMOS Protocol specifically, since the protocol's own spec is still incomplete. What is unresolved: how much of the described three-layer protocol is actually implemented end-to-end today versus aspirational, given the spec's own \"empty sections\" caveat, and whether any organization outside the Eclipse LMOS core contributor group has implemented LMOS-protocol-compliant discovery against a production deployment.", "track": "single-vendor", "version": { "date": null, "label": "LMOS Protocol v1 (draft, namespace https://eclipse.dev/lmos/protocol/v1)" } }, { "acronym": "ACP", "adoption": { "by": null, "level": "unmeasured", "probe_run": null }, "aliases": [ "AConP", "ACP (AGNTCY)" ], "analog": "a REST API gateway for invoking a remote service", "collisions": [ "Agent Client Protocol (Zed)", "Agent Communication Protocol (IBM)", "Agentic Commerce Protocol (OpenAI/Stripe)" ], "discovery": { "mechanism": "An agent's ACP capabilities are described in an 'ACP descriptor' retrievable via the ACP interface itself or embedded in that agent's record in an AGNTCY agent directory (now superseded in AGNTCY's active tooling by the 'dir' project); no site-wide well-known path is defined", "path": "/agents/search" }, "dispute": null, "evidence": [ { "claim": "The agntcy/acp-spec GitHub repository ('Agent Connect Protocol Specification', Apache-2.0, 168 stars) was archived by the owner on 2026-04-11 and is now read-only; its last commit was 2025-05-23 (PR #46, adding basic type support for input/output/config).", "date": "2026-09-06", "label": "VERIFIED", "url": "https://github.com/agntcy/acp-spec" }, { "claim": "The rendered OpenAPI spec at spec.acp.agntcy.org (v0.2.3, OpenAPI 3.1.1) defines the Agents, Threads, Thread Runs, and Stateless Runs operation groups (POST /agents/search, GET/POST /threads, POST /runs, etc.) for invoking and configuring remote agents.", "date": "2026-09-06", "label": "VERIFIED", "url": "https://spec.acp.agntcy.org/" }, { "claim": "The AGNTCY GitHub organization currently lists 49 public repositories with activity within hours to days of this check, with its identity/discovery focus now centered on the 'dir' (Distributed Announce and Discovery of Multi-Agentic-Systems) and 'oasf' (Open Agentic Schema Framework) projects rather than acp-spec.", "date": "2026-09-06", "label": "VERIFIED", "url": "https://github.com/orgs/agntcy/repositories" } ], "form": "endpoint", "governance": "AGNTCY project (Cisco donated AGNTCY to the Linux Foundation); the acp-spec GitHub repository was archived by its owner (the agntcy GitHub organization) on 2026-04-11 and is now read-only, while the broader AGNTCY project (49 repositories, most recently updated within hours of this check) remains active under Linux Foundation governance, with its discovery/identity work now centered on the 'dir' (Distributed Announce and Discovery) and OASF (Open Agentic Schema Framework) projects rather than acp-spec", "group": "Protocols called ACP", "history": [ { "date": "2026-09-06", "note": "added from arXiv 2504.16736 survey comparison, verified against github.com/agntcy/acp-spec, spec.acp.agntcy.org, github.com/orgs/agntcy/repositories" }, { "date": "2026-09-06", "note": "governance corrected to reflect Cisco donating AGNTCY to the Linux Foundation, per sibling records ads/oasf/slim; verified against existing agenticweb.wiki records" } ], "id": "agent-connect-protocol", "implementation": "deprecated", "last_verified": "2026-09-06", "name": "Agent Connect Protocol (AGNTCY)", "native_status": "OpenAPI 3.1.1 specification, version 0.2.3; source repository archived (read-only) by the owner on 2026-04-11; the rendered interactive spec at spec.acp.agntcy.org still resolves and is unchanged since its last update in May 2025", "origin": { "date": "2025-02", "org": "Cisco / LangChain, published under the AGNTCY Collective" }, "part_of": null, "parties": [ "agent-agent" ], "phase": "deprecated", "probe": { "method": "POST", "on_absent": "A 404 or non-JSON response means no ACP server at this origin. Because the specification's own source repository was archived by its owner in April 2026 with no announced successor, absence is the expected and increasingly common result over time.", "parse": "A 200 response returning a JSON array of agent objects (each with agent_id and metadata.ref) confirms an ACP-speaking server per the v0.2.3 OpenAPI schema.", "path": "{origin}/agents/search" }, "question": "How does one agent (or an orchestrator) invoke and configure a remote agent it did not build, over a plain HTTP API?", "scope": "general", "spec_url": "https://github.com/agntcy/acp-spec", "step": "act", "summary_md": "The Agent Connect Protocol (ACP), published by the AGNTCY Collective (co-founded by Cisco and LangChain), defines a standard REST/OpenAPI interface for invoking and configuring a remote agent over an API — covering agent discovery/search, stateless Runs, stateful Thread Runs with checkpointed state history, and streaming output [1][2]. It targets the same problem the Agent Client Protocol (Zed) and IBM's now-retired Agent Communication Protocol both address — a standard invocation surface for interchangeable agents — but is a third, independently governed specification that also happens to be commonly abbreviated \"ACP,\" a collision the AGNTCY project shares with at least two other unrelated \"ACP\" specifications tracked on this map [1].\n\nACP does not itself define agent-to-agent negotiation or a payments layer; its scope is narrowly the client/orchestrator-to-agent invocation surface, with agent metadata for richer discovery deferred to a separate 'agent directory' concept. It also does not define transport beyond HTTP/REST — there is no WebSocket or message-queue binding in the specification.\n\nAs of this check (September 2026), the specification's source repository (agntcy/acp-spec) was archived by its owner on 2026-04-11 and is now read-only, with its last substantive commit dated 2025-05-23 [1]. The rendered interactive OpenAPI documentation at spec.acp.agntcy.org still resolves and is served unchanged since that date, so existing implementations can still consult it, but no further spec development is occurring under this repository [2]. The broader AGNTCY Collective remains highly active — 49 public repositories with commits as recent as hours before this check — but its current discovery and identity work is concentrated in newer projects ('dir', a distributed agent directory, and 'oasf', the Open Agentic Schema Framework) rather than in acp-spec, suggesting AGNTCY's own architecture has moved on from this component without a formal deprecation notice or migration guide comparable to IBM's ACP-to-A2A banner [3].\n\nGovernance was, and nominally remains, the AGNTCY Collective's open, multi-vendor structure (Apache 2.0 license, public GitHub PR process, 'Copyright AGNTCY Contributors'). What is unresolved: whether any production deployments still run ACP servers independently of the newer 'dir'-based tooling, and whether AGNTCY intends to formally retire or fold ACP's invocation surface into a successor — no such announcement was found during this verification pass, only the archival action itself.", "track": "linux-foundation", "version": { "date": "2025-05-23", "label": "v0.2.3 (OpenAPI 3.1.1)" } }, { "acronym": "AP", "adoption": { "by": "project README (lists Auto-GPT, Auto-GPT-Forge, and smol developer as adopters, with e2b and Auto-GPT as 'engaged' in protocol development)", "level": "claimed", "probe_run": null }, "aliases": [ "AI Engineer Foundation Agent Protocol" ], "analog": "a REST job-queue API for arbitrary autonomous-agent backends", "collisions": [ "Agent Connect Protocol (AGNTCY)", "Agent Communication Protocol (IBM)", "Agent Client Protocol (Zed)" ], "discovery": { "mechanism": "None published; a client is expected to know an agent's base URL out of band (no well-known path or registry defined by the spec itself)", "path": null }, "dispute": { "claims": [ "agi-inc/agent-protocol README and repository 'About' field designate https://agentprotocol.ai/ as 'the docs'", "As fetched 2026-09-06, agentprotocol.ai serves a third-party comparison guide with no evident connection to AI Engineer Foundation, AGI Inc., or the agent-protocol repository" ], "summary": "The repository's own README and GitHub 'About' field link https://agentprotocol.ai/ as the project's documentation home, but as fetched during this verification pass the domain serves unrelated third-party content — a vendor-neutral protocol-comparison guide covering MCP, A2A, and Agent Protocol — with no visible affiliation to AI Engineer Foundation, AGI Inc., or the GitHub repository that links it. The canonical specification currently survives only as the openapi.yml file inside the GitHub repository itself." }, "evidence": [ { "claim": "The GitHub repository formerly at AI-Engineer-Foundation/agent-protocol now redirects to agi-inc/agent-protocol ('Maintained by AGI, Inc.'), MIT licensed, 1.5k stars, 186 forks; its README defines the protocol as an OpenAPI REST spec with POST /ap/v1/agent/tasks and POST /ap/v1/agent/tasks/{task_id}/steps as its two essential routes, and lists Auto-GPT, Auto-GPT-Forge, and smol developer as adopting projects.", "date": "2026-09-06", "label": "VERIFIED", "url": "https://github.com/AI-Engineer-Foundation/agent-protocol" }, { "claim": "The repository's own 'Docs' link, https://agentprotocol.ai/, currently serves an unrelated third-party site ('AgentProtocol.ai') describing itself as 'an independent, vendor-neutral guide' comparing MCP, A2A, and Agent Protocol — it shows no visible affiliation with AI Engineer Foundation, AGI Inc., or the agi-inc/agent-protocol repository, and does not host the project's own documentation.", "date": "2026-09-06", "label": "VERIFIED", "url": "https://agentprotocol.ai/" } ], "form": "endpoint", "governance": "Originated as an AI Engineer Foundation (AIEF) community project (GitHub org formerly AI-Engineer-Foundation); the repository now lives under 'agi-inc' and states it is 'Maintained by AGI, Inc.', a commercial entity; the docs domain linked from the repository, agentprotocol.ai, currently serves unrelated third-party content rather than AIEF/AGI Inc. project documentation", "group": null, "history": [ { "date": "2026-09-06", "note": "added from arXiv 2504.16736 survey comparison, verified against github.com/AI-Engineer-Foundation/agent-protocol (redirects to agi-inc/agent-protocol), agentprotocol.ai" } ], "id": "agent-protocol-aief", "implementation": "multi-implementation", "last_verified": "2026-09-06", "name": "Agent Protocol", "native_status": "\"Common interface for interacting with AI agents. The protocol is tech stack agnostic\" (repository description); defined as an OpenAPI REST spec with two core routes, POST /ap/v1/agent/tasks and POST /ap/v1/agent/tasks/{task_id}/steps", "origin": { "date": null, "org": "AI Engineer Foundation (AIEF), originally alongside the Auto-GPT/e2b community" }, "part_of": null, "parties": [ "agent-site" ], "phase": "draft", "probe": { "method": "POST", "on_absent": "A 404 or schema mismatch means this origin does not implement Agent Protocol. Given the project's docs domain has since been repurposed to unrelated content and no commit activity was found in the past year, absence should now be treated as the default expectation rather than a surprise.", "parse": "A 200/201 response returning a Task object containing a task_id field confirms an Agent-Protocol-compliant server per the OpenAPI schema.", "path": "{origin}/ap/v1/agent/tasks" }, "question": "How does a client or dev-tool start a task on an autonomous agent, step it, and fetch results, regardless of which framework built the agent?", "scope": "general", "spec_url": "https://github.com/AI-Engineer-Foundation/agent-protocol", "step": "act", "summary_md": "Agent Protocol is a framework-agnostic, OpenAPI v3 REST specification originally proposed by the AI Engineer Foundation (AIEF) community, alongside the early Auto-GPT/e2b ecosystem, to give any autonomous agent a single, predictable interface: create a task (POST /ap/v1/agent/tasks), execute it step by step (POST /ap/v1/agent/tasks/{task_id}/steps), and list or download artifacts, regardless of the framework the agent was built with [1]. It solves the comparison and integration problem for early agent frameworks — before Agent Protocol, every agent exposed a bespoke interface, making benchmarking and devtool-building across agents difficult; the spec's own stated goal is 'great developer experience' for agent builders wanting to avoid writing boilerplate API code [1].\n\nIt does not define agent-to-agent communication (the README lists this as future roadmap, unrealized), does not define authorization on behalf of end users, and does not define discovery — clients are expected to know an agent's base URL out of band [1].\n\nAs of this check (September 2026), the project's governance and web presence show significant drift from its AIEF origins. The GitHub repository formerly hosted under the AI-Engineer-Foundation organization now redirects to agi-inc/agent-protocol and states it is \"Maintained by AGI, Inc.,\" a commercial entity, rather than the original community foundation [1]. More notably, the repository's own linked documentation domain, agentprotocol.ai, no longer hosts the project's docs at all: as fetched during this verification pass, it serves an unrelated third-party site describing itself as an 'independent, vendor-neutral guide' to MCP, A2A, and Agent Protocol, with no visible connection to AI Engineer Foundation, AGI Inc., or the GitHub repository that links to it as its official documentation [2]. This is flagged as a dispute rather than treated as settled, since it was not possible in this pass to determine whether the domain lapsed and was independently re-registered, or was deliberately repurposed by a current stakeholder.\n\nImplementation history shows genuine multi-party adoption during the 2023–2024 Auto-GPT era — Auto-GPT, Auto-GPT-Forge, and smol developer all merged Agent-Protocol-compliant PRs, with e2b and Auto-GPT credited as 'engaged' co-developers of the spec — but no evidence of continued active development or adoption was found in the past year of repository activity [1]. What is unresolved: whether Agent Protocol should be considered a live, maintained standard at all today, or a historically important but now largely dormant spec whose primary surviving artifact is the OpenAPI file in a repository under new, commercial ownership.", "track": "single-vendor", "version": { "date": null, "label": "unversioned OpenAPI spec (schemas/openapi.yml)" } }, { "acronym": "AITP", "adoption": { "by": "NEAR AI (agents built on the NEAR AI Hub are claimed to 'support all AITP features')", "level": "claimed", "probe_run": null }, "aliases": [ "Agent Interaction & Transaction Protocol" ], "analog": "HTTP+HTML for agent-to-agent interaction, per the project's own framing", "collisions": [], "discovery": { "mechanism": "None defined by AITP itself; agents are addressed directly once discovered out of band (e.g. via the NEAR AI Hub's own agent registry, which is outside the AITP spec)", "path": null }, "dispute": null, "evidence": [ { "claim": "AITP's homepage states Version: 0.1.0, Status: Draft, and describes the protocol as two parts — a core Threads protocol (inspired by and largely compatible with the OpenAI Assistant/Threads API) and an extensible Capabilities layer for structured interactions like multimodal input, generative UI, payments, and human-in-the-loop attestations.", "date": "2026-09-06", "label": "VERIFIED", "url": "https://aitp.dev/" }, { "claim": "The nearai/aitp GitHub repository (MIT license, 25 stars, 4 forks) confirms the same version/status and hosts the capability schemas directory; its README frames AITP as complementary to (not a replacement for) multi-agent orchestration frameworks, service-metadata protocols like MCP, and browser-use agents.", "date": "2026-09-06", "label": "VERIFIED", "url": "https://github.com/nearai/aitp" } ], "form": "endpoint", "governance": "NEAR AI-led open-source specification, MIT licensed (github.com/nearai/aitp); developed in parallel with NEAR AI's own agent hub and community input via Telegram/GitHub issues and PRs; no independent standards body", "group": null, "history": [ { "date": "2026-09-06", "note": "added from arXiv 2504.16736 survey comparison, verified against aitp.dev, github.com/nearai/aitp" } ], "id": "aitp", "implementation": "prototype", "last_verified": "2026-09-06", "name": "AITP (Agent Interaction & Transaction Protocol)", "native_status": "Version: 0.1.0. Status: Draft. \"AITP is a spec in progress and we are open to comments, feedback, and contributions\" (project's own words)", "origin": { "date": "2025", "org": "NEAR AI (NEAR Foundation)" }, "part_of": null, "parties": [ "agent-agent", "agent-human" ], "phase": "draft", "probe": { "method": "POST", "on_absent": "A 404 or a Threads-API-shaped response with no Capability exchange means this origin either doesn't speak AITP or only speaks the underlying OpenAI-compatible Threads transport without AITP's capability layer.", "parse": "A response containing a Thread object 'largely compatible with the OpenAI Assistant/Threads API' is necessary but not sufficient; confirming AITP specifically requires observing a Capability-exchange message (per the capabilities schema) rather than plain-text-only thread content.", "path": "{origin}/threads" }, "question": "How do two agents representing different, mutually untrusted people or businesses (e.g. a personal assistant and an airline's booking agent) talk to each other, exchange forms and payment requests, and not just plain text?", "scope": "general", "spec_url": "https://aitp.dev/", "step": "coordinate", "summary_md": "AITP (Agent Interaction & Transaction Protocol), published by NEAR AI, is a draft specification for AI agents to communicate securely across trust boundaries — the project's canonical example is a personal AI assistant booking a flight by talking directly to an airline's own booking agent, exchanging structured flight options, passenger details, and payment information over a shared protocol rather than the assistant scraping the airline's website [1]. It consists of two parts: a core Threads protocol for the conversation itself, described as 'inspired by and largely compatible with' OpenAI's Assistant/Threads API, and an extensible Capabilities layer — standardized message types agents can negotiate to support structured interactions such as multimodal input, generative UI (forms, buttons), payment requests, and human-in-the-loop attestations [1][2].\n\nAITP explicitly positions itself as complementary to, not competing with, three adjacent categories: same-owner multi-agent orchestration frameworks (CrewAI, Autogen, LangGraph), service-metadata protocols that let agents call existing APIs (MCP, Bitte, llms.txt), and browser-use agents that navigate existing websites (ChatGPT Operator) — the project frames the last of these as merely 'transitional, useful until AITP adoption grows' [2]. It does not define its own transport-layer security scheme beyond what a chosen Transport (e.g. HTTPS) provides, and does not define agent discovery: personal assistants and service agents are expected to already know how to reach each other, typically via the NEAR AI Hub's own agent registry, which sits outside the AITP spec itself [1].\n\nAs of this check (September 2026), AITP remains at version 0.1.0 and Draft status; the project states plainly that the spec is being written simultaneously with its own reference implementation (NEAR AI Hub agents) and is actively soliciting feedback before a 1.0 release [1][2]. The only implementations identified are NEAR AI's own — agents built on app.near.ai/agents are claimed by NEAR AI to support all AITP features — with no independent, non-NEAR production adopter confirmed during this verification pass, so adoption here is recorded as claimed rather than measured. What remains unresolved: how AITP's Capabilities layer (particularly payments, which relies on unspecified external settlement rails) will interoperate with the payment-specific protocols already on this map, and whether any framework or platform outside the NEAR ecosystem has committed to implementing AITP ahead of a stable 1.0.", "track": "single-vendor", "version": { "date": null, "label": "0.1.0 (Draft)" } }, { "acronym": "Coral", "adoption": { "by": null, "level": "unmeasured", "probe_run": null }, "aliases": [ "CoralOS", "Coral" ], "analog": "Kubernetes, but for AI agents, plus an app-store marketplace layer", "collisions": [], "discovery": { "mechanism": "Agents are discovered via the centralized Coral Marketplace (publish/discover/monetize with built-in attestation); a local Coral Server also exposes a session-creation API for orchestrating a given agent graph; MCP is used as the underlying inter-agent transport for 'coralized' agents", "path": null }, "dispute": null, "evidence": [ { "claim": "CoralOS (formerly 'Coral Protocol'; docs.coralprotocol.org now redirects to docs.coralos.ai) describes itself as 'Kubernetes for AI agents' — a platform comprising Coralized Agents, a Coral Marketplace for discovery/monetization, Coral Server for orchestration, Coral Console for monitoring, and a Coralizer that turns any MCP server into a marketplace-listed agent.", "date": "2026-09-06", "label": "VERIFIED", "url": "https://docs.coralos.ai/about" }, { "claim": "The documented local API includes POST /api/v1/local/session ('Create session'), which accepts an agentGraphRequest of agents (each with an id, provider, and an x402Budgets array for per-resource micropayment budgets) and returns a namespace and sessionId.", "date": "2026-09-06", "label": "VERIFIED", "url": "https://docs.coralos.ai/api-reference/local/create-session" } ], "form": "endpoint", "governance": "Single company/startup-led open-source project (GitHub org Coral-Protocol); rebranded 'CoralOS' as of this check (docs moved from docs.coralprotocol.org to docs.coralos.ai); not a multi-stakeholder standards body", "group": null, "history": [ { "date": "2026-09-06", "note": "added from arXiv 2504.16736 survey comparison, verified against docs.coralos.ai/about, docs.coralos.ai/api-reference/local/create-session" } ], "id": "coral-protocol", "implementation": "shipping", "last_verified": "2026-09-06", "name": "Coral Protocol (CoralOS)", "native_status": "\"Kubernetes for AI agents: a platform for everything between your agents and production — registry, runtimes, security, and orchestration\" (current docs homepage); described elsewhere as a 'decentralized protocol powering AI agent collaboration, trust, and payments'", "origin": { "date": "2025", "org": "Coral Protocol (GitHub org Coral-Protocol)" }, "part_of": null, "parties": [ "agent-agent" ], "phase": "living", "probe": { "method": "POST", "on_absent": "A 404, connection refusal, or 401/403 (this endpoint requires bearer auth) most commonly just means no local Coral Server is running at this address — Coral Server is typically run locally by the developer rather than exposed as a public origin, so a failed probe against an arbitrary public site proves little either way.", "parse": "A 200 response containing a JSON object with namespace and sessionId fields confirms a running Coral (local) server per its documented API reference; the request body's x402Budgets field on agent entries also confirms native x402 micropayment-budget support.", "path": "{origin}/api/v1/local/session" }, "question": "How do independently-built agents from a public marketplace get orchestrated together into one multi-agent system, with privacy isolation and built-in payment budgets, on top of MCP?", "scope": "general", "spec_url": "https://docs.coralos.ai/welcome", "step": "coordinate", "summary_md": "Coral Protocol, rebranded 'CoralOS' as of this check, is a single-vendor, open-source platform for orchestrating a graph of independently built AI agents — pulled from a public marketplace or built in-house — with per-session privacy isolation, a graph-based (rather than single-planner-hierarchical) coordination model, and built-in payment budgeting [1]. It positions itself explicitly as infrastructure rather than a thin wire protocol: its own tagline is \"Kubernetes for AI agents,\" and its documented components (Coral Server for orchestration, a Coral Marketplace for discovery/monetization with attestation, a Coral Console for monitoring, and a 'Coralizer' that wraps any existing MCP server into a marketplace-listed agent) describe a full runtime platform built on top of MCP as the underlying inter-agent transport, not a standalone spec document [1].\n\nIt solves multi-agent orchestration at the point where a hierarchical single-planner design becomes a bottleneck: Coral's graph-based architecture lets agents communicate directly and monitor each other's progress rather than funneling every decision through a central controller, a design choice the project backs with a cited academic benchmark result (Anemoi, arXiv:2508.17068) showing accuracy gains from this structure on the GAIA benchmark [1]. It does not define a public, network-visible wire protocol comparable to A2A's Agent Card + JSON-RPC surface; its documented API (e.g. POST /api/v1/local/session) is a local orchestration control-plane endpoint requiring bearer authentication, run by the developer rather than exposed as a discoverable public origin [2].\n\nAs of this check (September 2026), Coral is an actively developed, versionless platform rather than a dated spec release — its docs site itself changed domain during the period covered by this map (from docs.coralprotocol.org to docs.coralos.ai), and its session API already includes native support for x402 micropayment budgets per agent, tying it into the broader agentic-payments ecosystem this map also tracks [1][2]. Implementations are real and shipping: Coral Server and the Coralizer are both public GitHub repositories under the Coral-Protocol organization. What is unresolved: how open Coral's governance actually is beyond \"open-source code, single company roadmap\" — no independent steering body or multi-vendor governance document was found, and no adoption count beyond the project's own marketing language was available to verify during this pass.", "track": "single-vendor", "version": { "date": null, "label": "unversioned, continuously updated platform (Coral Server, Coralizer, Marketplace)" } }, { "acronym": "WAP", "adoption": { "by": null, "level": "observed", "probe_run": null }, "aliases": [ "WAP" ], "analog": "macro record-and-replay, packaged as an MCP tool", "collisions": [ "Wireless Application Protocol (unrelated, legacy mobile-web WAP)" ], "discovery": { "mechanism": "None — WAP is not a network-discoverable, site-facing protocol. It is a local pipeline: a Chrome extension records a user's browser session, a Python SDK converts the recording into an 'exact-replay' or 'smart-replay' action list, and that action list can be converted into a local MCP server for reuse by any MCP-speaking agent.", "path": null }, "dispute": null, "evidence": [ { "claim": "The OTA-Tech-AI/web-agent-protocol GitHub repository (MIT license, 507 stars, 88 forks) describes WAP as a record (Chrome extension) → convert (exact/smart replay lists) → replay pipeline for browser automation, including a path to convert recorded actions into an MCP server; its last commit ('Update README.md') is dated 2025-06-03, over a year before this check.", "date": "2026-09-06", "label": "VERIFIED", "url": "https://github.com/OTA-Tech-AI/web-agent-protocol" }, { "claim": "OTA Tech AI's own homepage (otatech.ai, 'OTA Technologies Inc.') lists Web-Agent-Protocol (WAP) alongside its OTA-v1 Browser Agent Model as company products, confirming WAP is a single-company project rather than an independently governed spec.", "date": "2026-09-06", "label": "VERIFIED", "url": "https://www.otatech.ai/" } ], "form": "document-format", "governance": "Single company (OTA Tech AI); MIT-licensed public GitHub repository; no independent standards process or multi-party governance found", "group": null, "history": [ { "date": "2026-09-06", "note": "added from arXiv 2504.16736 survey comparison, verified against github.com/OTA-Tech-AI/web-agent-protocol" }, { "date": "2026-09-06", "note": "added second evidence entry (otatech.ai) to satisfy the two-source verification requirement" } ], "id": "web-agent-protocol", "implementation": "prototype", "last_verified": "2026-09-06", "name": "Web Agent Protocol (WAP)", "native_status": "\"A standardized framework designed to enable seamless interaction between users, web agents, and browsers by recording and replaying browser actions\" (repository's own description)", "origin": { "date": "2025-05", "org": "OTA Tech AI" }, "part_of": null, "parties": [ "agent-site" ], "phase": "draft", "probe": { "method": "n/a", "on_absent": "n/a — presence is determined by whether the operator has locally installed the OTA-WAP Chrome extension and Python SDK and generated a recording, not by any network-visible signal at a target site.", "parse": "n/a", "path": "n/a — there is no remote origin to probe. WAP has no server-side or site-side presence to detect; every website it 'supports' is simply whatever page the operator's own Chrome extension happened to record, and replay runs entirely on the operator's own machine." }, "question": "How does a recorded human browsing session get replayed reliably by an agent later, or turned into a reusable tool another agent can call?", "scope": "general", "spec_url": "https://github.com/OTA-Tech-AI/web-agent-protocol", "step": "act", "summary_md": "Web Agent Protocol (WAP), published by OTA Tech AI, is a record-and-replay framework for browser automation: a Chrome extension captures a human's on-page interactions (clicks, form fills, navigation) into a structured event stream; a Python SDK converts that stream into either an 'exact-replay' list (reproduces every recorded action verbatim) or a 'smart-replay' list (condensed, goal-oriented steps generated via an LLM subgoal-generation step); and a separate WAP-Replay component executes either list back against a live browser, with an option to package a recorded task as a local MCP server so any MCP-speaking agent can reuse it as a tool [1].\n\nIt solves reliable browser-action reuse and agent-UI testing without requiring an agent to re-derive a working action sequence from scratch on every run — a common failure mode for pure browser-use agents that re-plan each step live. It does not define any network-visible, site-facing protocol: there is no well-known path, header, or endpoint a website exposes to signal WAP support, and no interoperability guarantee between WAP-recorded actions and any other agent framework's action format beyond the MCP-server conversion step. It is also not a standards-track specification in any formal sense — it is a single company's open-source tool with a README describing conventions, not a versioned spec document.\n\nAs of this check (September 2026), the project shows no recent development activity: its most recent commit is dated 2025-06-03, over a year before this verification pass, against 3 branches and a single tag [1]. Governance is entirely OTA Tech AI's own (a company also publishing the OTA-v1 model on Hugging Face); there is no independent standards body, working group, or multi-vendor input process. Adoption signals are limited to GitHub's own engagement metrics (507 stars, 88 forks, 61 watchers as observed during this pass) with no independent production deployment identified beyond the project's own demo materials. What is unresolved: whether WAP is still actively maintained at all given the year-plus commit gap, and whether its name collision with the unrelated, long-obsolete Wireless Application Protocol (also 'WAP,' a 1990s–2000s mobile-web standard) causes practical confusion — no evidence of such confusion was found, but the acronym overlap is exact.", "track": "single-vendor", "version": { "date": "2025-06-03", "label": "unversioned (main branch, 1 tag, last commit 2025-06-03)" } }, { "acronym": "NLIP", "adoption": { "by": "NLIP project / Enterprise Neurosystem (self-reported: PyPI nlip_sdk/nlip-server downloads ~300-420/month as of 2026-06; production use claimed by Enterprise Neurosystem member Kove; incubation partners CUNY and IBM)", "level": "claimed", "probe_run": null }, "aliases": [ "Natural Language Interaction Protocol", "ECMA-430" ], "analog": "none; closest classic-web analog is a generic RPC envelope (e.g. SOAP) but for natural-language, multi-modal agent messages", "collisions": [ "NLIP (unrelated: various unrelated \"NLIP\" acronym collisions in older NLP literature, e.g. \"Natural Language and Information Processing\"); also collides informally with NLI (Natural Language Interface) as a category name" ], "discovery": { "mechanism": "none; NLIP does not define a discovery mechanism of its own. An NLIP endpoint is reached by a URL/address exchanged out of band or via another discovery layer; the protocol only defines the message envelope and transport bindings once an endpoint is known", "path": "none" }, "dispute": { "claims": [ "Project site and contributor posts (nlip-project.org, LinkedIn Aug 2026): NLIP is a general-purpose interoperability hub across MCP/A2A/ANP/ACP/AGNTCY/AP2/UCP.", "Observed (this verification pass): no third-party (non-NLIP-project) adapter or bridge implementation between NLIP and MCP/A2A was found; the arXiv paper describes the relationship to MCP and A2A conceptually rather than showing a shipped bridge." ], "summary": "The project's own materials describe NLIP as both a settled Ecma standard (\"ECMA-430\", ratified 10 December 2025) and as an early-stage, low-adoption proof-of-concept (all reference SDKs are pre-1.0, PyPI download counts are in the low hundreds per month, and the GitHub org's most-starred repo has 14 stars). Public production deployments beyond the incubating Enterprise Neurosystem/IBM/CUNY circle are not independently documented as of 2026-09-07. The August 2026 LinkedIn framing of NLIP as \"the ODBC of agent protocols\" that sits above/adapts MCP, A2A, ANP, ACP, AGNTCY, AP2 and UCP is a forward-looking claim from project contributors, not yet demonstrated by third-party adapters." }, "evidence": [ { "claim": "ECMA-430 (Natural Language Interaction Protocol) is a Standard defining an application-level communication protocol between AI agents or between a human and an AI agent, published by Ecma International Technical Committee TC56, 1st edition, December 2025.", "date": "2025-12", "label": "VERIFIED", "url": "https://ecma-international.org/publications-and-standards/standards/ecma-430/" }, { "claim": "NLIP is developed by researchers and practitioners across companies and universities and standardized by Ecma International; it defines a lightweight semantic message envelope carried over transports including HTTP/HTTPS, WebSocket, and AMQP, and the paper covers its message model, transport bindings, security-by-design considerations, reference implementation, adoption signals, and relationship to MCP and A2A. Accepted by ACM AI Summit 2026, submitted 3 September 2026.", "date": "2026-09-03", "label": "VERIFIED", "url": "https://arxiv.org/abs/2609.04135" }, { "claim": "The NLIP project site lists the full standards suite ratified by Ecma: ECMA-430 (core protocol), ECMA-431 (HTTP/HTTPS binding), ECMA-432 (WebSocket binding), ECMA-433 (AMQP binding), ECMA-434 (security profiles), and ECMA TR/113 (explanatory technical report); the envelope is a JSON object whose first sub-message carries format/subformat/content, is transport-agnostic, multi-modal (text, image, structured, location, generic), and hot-extensible; governance is via Ecma TC-56 and the NLIP community; code is Apache 2.0.", "date": "2026-09-07", "label": "VERIFIED", "url": "https://nlip-project.org" }, { "claim": "NLIP was incubated by the Enterprise Neurosystem, led by Dinesh Verma (IBM Fellow), with development/implementation work at the University of Delaware sponsored by Enterprise Neurosystem supporter Kove; recognised as a family of standards by Ecma International; Enterprise Neurosystem states its community will use the protocol in production deployments going forward.", "date": "2026-01-05", "label": "VERIFIED", "url": "https://medium.com/the-enterprise-neurosystem-blog/exciting-news-for-the-natural-language-interaction-protocol-nlip-and-its-impact-on-implementing-b7e673ac4713" }, { "claim": "The nlip-project GitHub organisation (created 2024-09-20, 65 followers, 21 public repos as of this check) hosts the reference implementation split into nlip_sdk (message/submessage abstractions), nlip_client (httpx-based client transport), nlip_server (FastAPI-based server abstractions: NLIPApplication/NLIPSession), plus nlip_soln (example chatbot/integrator solutions), nlip_web (JS/FastAPI demo app), and nlip_swarm; PyPI packages nlip_sdk and nlip-server are published (v0.1.3 as of 2026-06-24, author Dinesh Verma) with reported last-month download counts around 300-420.", "date": "2026-09-07", "label": "VERIFIED", "url": "https://github.com/nlip-project/nlip_server" } ], "form": "document-format", "governance": "Ecma International Technical Committee TC56 (NLIP), with an ISO ballot in progress as of mid-2026 per contributor reports; incubated and supported by the Enterprise Neurosystem community", "group": null, "history": [ { "date": "2026-09-07", "note": "created and verified against Ecma International ECMA-430 standard page, the NLIP arXiv paper (2609.04135, Sept 2026), nlip-project.org, an Enterprise Neurosystem blog post on Ecma recognition, and the nlip-project GitHub org's reference implementation repos" } ], "id": "nlip", "implementation": "multi-implementation", "last_verified": "2026-09-07", "name": "Natural Language Interaction Protocol", "native_status": "Ecma International Standard, 1st edition, published 10 December 2025 (ECMA-430 core spec, plus companion ECMA-431/432/433 transport bindings, ECMA-434 security profiles, and ECMA TR/113 explanatory report); an ISO standardisation ballot was reported in progress by project contributors as of August 2026", "origin": { "date": "2025-12", "org": "Enterprise Neurosystem community (led by Dinesh Verma, IBM Fellow), with contributors from IBM, Purdue (Elisa Bertino), Indiana University (Luyi Xing), Red Hat, and others, standardized by Ecma International TC56" }, "part_of": null, "parties": [ "agent-agent", "agent-human" ], "phase": "stable", "probe": { "method": "POST", "on_absent": "A non-2xx response, a connection refusal, or a body that does not parse as an NLIP envelope means the origin does not run an NLIP endpoint at that address; NLIP has no well-known discovery path, so absence at a guessed path is not conclusive proof the origin lacks NLIP support", "parse": "A 200 response whose JSON body is (or contains) an NLIP message: an object with a first sub-message carrying format/subformat/content fields (e.g. {\"format\":\"text\",\"subformat\":\"english\",\"content\":\"...\"}), per the ECMA-430 envelope and the ECMA-431 HTTP/HTTPS binding", "path": "https://{endpoint}/nlip/" }, "question": "Can this agent or service exchange natural-language, multi-modal messages using a shared, vendor-neutral envelope instead of a bespoke API?", "scope": "general", "spec_url": "https://ecma-international.org/publications-and-standards/standards/ecma-430/", "step": "coordinate", "summary_md": "The Natural Language Interaction Protocol (NLIP) is an application-layer message envelope for exchanges between AI agents, and between a human and an AI agent, standardized by Ecma International as ECMA-430 (1st edition, published 10 December 2025) under Technical Committee TC56 [1][3]. It ships as a family of six documents: ECMA-430 defines the core multimodal message format (a JSON envelope whose first sub-message carries `format`, `subformat`, `content`, with optional sub-messages for images, policy tokens, or control directives); ECMA-431, -432 and -433 bind that envelope to HTTP/HTTPS, WebSocket, and AMQP transports respectively; ECMA-434 defines security profiles; and ECMA TR/113 is an explanatory technical report covering motivation and example exchanges [1][3].\n\nWhat it solves: today, every AI agent framework and vendor invents its own JSON dialect, auth scheme, and rate-limit convention, so connecting N agent platforms to M backends requires bespoke glue for every pair. NLIP proposes a single grammar and set of control frames so any NLIP-compliant agent can exchange multi-modal, natural-language messages (text, image, structured data, location, or other binary content) with any other, regardless of the underlying LLM, framework, or transport [3]. Contributors describe the ambition as comparable to what TCP/IP did for networks or HTTP did for documents: a common wiring layer, with adapters positioning NLIP as an interchange hub across other agent protocols such as MCP, A2A, ANP, ACP, and AGNTCY [3][5].\n\nWhat it does not do: NLIP explicitly excludes direct interoperability with existing proprietary systems (that requires an adapter) and excludes building end-user applications — it is protocol-and-specification only [3]. It does not define a discovery mechanism (no well-known path or DNS convention); an NLIP endpoint address must be learned out of band or via another protocol. It does not itself provide identity, payment, or content-permission semantics beyond carrying policy/authentication tokens inside the envelope.\n\nCurrent state: the specification suite reached Ecma International Standard status on 10 December 2025, and as of mid-2026 project contributors reported a positive ISO member-country ballot toward international standardization, though ISO ratification was not yet confirmed as complete at the time of this check [1][2]. The NLIP GitHub organisation (created September 2024, 65 followers, 21 public repositories) hosts a Python reference implementation split into `nlip_sdk` (message model), `nlip_client` (httpx-based client), and `nlip_server` (FastAPI-based server abstractions), plus example solutions (`nlip_soln`, `nlip_web`, `nlip_swarm`) [5]. The `nlip_sdk` and `nlip-server` PyPI packages are published (v0.1.3, June 2026) under Dinesh Verma's authorship, with reported monthly download counts in the low hundreds — evidence of a working, installable proof-of-concept rather than broad production adoption [5].\n\nWho implements it: the project was incubated by the Enterprise Neurosystem community, led by Dinesh Verma (IBM Fellow), with contributions from Purdue's Elisa Bertino, Indiana University's Luyi Xing, Red Hat's Sanjay Aiyagari, and others across IBM, CUNY, and the University of Delaware (implementation work there sponsored by Enterprise Neurosystem member Kove) [4][5]. Enterprise Neurosystem states its own community intends to use NLIP in production going forward, and Red Hat's Sanjay Aiyagari has proposed NLIP as a security layer for IoT devices at NDSS 2026, but no independently verified third-party production deployment outside this incubating circle was found in this pass.\n\nDisputed or unknown: whether NLIP will function as a genuine interoperability hub across MCP/A2A/other agent protocols, as claimed in an August 2026 LinkedIn post by project contributors (\"the ODBC of agent protocols\"), is a forward-looking claim not yet demonstrated by any shipped third-party bridge or adapter found in this research pass. Broader third-party (non-incubator) adoption numbers are not published anywhere found; this record's adoption level is therefore \"claimed\", not \"measured\".", "track": "industry-body", "version": { "date": "2025-12-10", "label": "ECMA-430, 1st edition" } }, { "acronym": "EMV Agentic Payments", "adoption": { "by": null, "level": "unmeasured", "probe_run": null }, "aliases": [ "EMVCo Agentic Payments Framework", "EMV Agentic Payments Framework for Specifications" ], "analog": "A shared authorisation-hold / standing-order ledger that every party in a card transaction can consult, rather than 3-D Secure's single point-in-time challenge", "collisions": [ "AP2 (Google's Agent Payments Protocol, also card/mandate-oriented)", "ACP (Agentic Commerce Protocol, OpenAI/Stripe)", "UCP (Universal Commerce Protocol, Google)", "Verifiable Intent (vi) — the cryptographic intent layer EMVCo names as complementary; see that article" ], "discovery": { "mechanism": "none published — the draft is a conceptual/organisational framework (roles, data fields, an ‘Intent Services’ concept) for a future specification; it defines no fixed well-known path, header, or endpoint an agent or origin could probe for today", "path": "none" }, "dispute": null, "evidence": [ { "claim": "On 1 September 2026 EMVCo – described as ‘the technical body that creates and manages EMV® Specifications and programmes’ – released a draft framework, EMV® Agentic Payments – Framework for Specifications v1.0, for public comment through 30 September 2026, focused on card-based agentic payment scenarios (recurring purchases, cumulative budgets, post-transaction activity) where consumer intent must be managed over time; it introduces the concept of ‘Intent Services’, a shared interoperable layer letting payment participants register, reference, retrieve and manage consumer-authorised intent before, during and after a transaction.", "date": "2026-09-01", "label": "VERIFIED", "url": "https://www.emvco.com/news/emvco-requests-feedback-on-framework-for-secure-interoperable-and-scalable-card-based-agentic-payments/" }, { "claim": "Clinton Allen, Chair of the EMVCo Agentic Payments Task Force, explains the framework centres on use-cases where a consumer delegates card-payment authority to an AI agent; it is meant to complement cryptographic assurance from existing solutions such as Verifiable Intent with a common coordination point; it may inform future enhancements to EMV 3-D Secure, EMV Payment Tokenisation, EMV Secure Remote Commerce and the EMV Digital Payment Credential, and EMVCo may pursue future work on Know Your Agent (KYA) and Agentic Transaction Indicators; EMVCo is collaborating with the FIDO Alliance, OpenID Foundation, OpenWallet Foundation and W3C to avoid ecosystem fragmentation.", "date": "2026-09-01", "label": "VERIFIED", "url": "https://www.emvco.com/knowledge-hub/how-emvco-is-working-to-enable-secure-interoperable-and-scalable-card-based-agentic-payments/" }, { "claim": "Independent trade press confirms the framework was developed by EMVCo's newly formed Agentic Payments Task Force (chaired by Clinton Allen), covers card-based payments where consumers authorise recurring purchases or spending limits for an AI agent, and introduces Intent Services as an interoperable layer for registering and tracking authorised purchasing intent across the transaction lifecycle, working alongside cryptographic technologies such as Verifiable Intent.", "date": "2026-09-04", "label": "VERIFIED", "url": "https://fintech.global/2026/09/04/emvco-drafts-framework-for-agentic-card-payments/" }, { "claim": "EMVCo's stated mission is 'to facilitate the worldwide interoperability of secure payment transactions by developing and publishing the EMV Specifications and their related testing processes'; EMVCo itself does not mandate or enforce implementation — that is left to payment networks, issuers, merchants and acquirers.", "date": null, "label": "VERIFIED", "url": "https://www.emvco.com/about-us/overview-of-emvco/" } ], "form": "document-format", "governance": "EMVCo, the technical body jointly owned by American Express, Discover, JCB, Mastercard, UnionPay and Visa, which creates and manages the EMV Specifications; this framework is being developed by EMVCo's dedicated Agentic Payments Task Force with input from EMVCo Associates and Subscribers, and in collaboration with the FIDO Alliance, the OpenID Foundation, the OpenWallet Foundation and W3C", "group": null, "history": [ { "date": "2026-09-07", "note": "created and verified against EMVCo's 2026-09-01 news release, the companion EMV Insights article by Clinton Allen, independent trade press (fintech.global, 2026-09-04), and the EMVCo overview page" } ], "id": "emv-agentic-payments", "implementation": "none-found", "last_verified": "2026-09-07", "name": "EMV Agentic Payments – Framework for Specifications", "native_status": "Draft v1.0, released for public review and comment; EMVCo describes it as ‘a foundation for further industry engagement and potential specification development’, not itself a finished specification", "origin": { "date": "2026-09-01", "org": "EMVCo (jointly owned by American Express, Discover, JCB, Mastercard, UnionPay and Visa), via its newly formed Agentic Payments Task Force chaired by Clinton Allen" }, "part_of": null, "parties": [ "agent-payment" ], "phase": "draft", "probe": { "method": "none", "on_absent": "No probe exists; EMVCo has not yet published a technical specification, so absence of any signal cannot be distinguished from the framework simply not having reached implementation yet", "parse": "not applicable — this is a draft framework document, not a deployed protocol; there is no wire format, endpoint, or file to fetch, matching how other pre-implementation pay-step drafts (e.g. vcap) are recorded", "path": "none" }, "question": "When a card network, issuer, merchant, or wallet sees an AI-agent-initiated card payment, how do they consistently find out what the consumer actually authorised — recurring purchase, spending cap, post-transaction change — rather than each building a bespoke, one-off signal?", "scope": "payments", "spec_url": "https://www.emvco.com/resources/emv-agentic-payments-framework-for-specifications-v1-0-draft-comment-period-ends-30-sept-2026/", "step": "pay", "summary_md": "EMV Agentic Payments – Framework for Specifications is a draft document, not yet a technical specification, published on 1 September 2026 by EMVCo – the technical body jointly owned by American Express, Discover, JCB, Mastercard, UnionPay and Visa that creates and manages the EMV Specifications used for card payments worldwide [4]. It was produced by EMVCo's newly formed Agentic Payments Task Force, chaired by Clinton Allen, and opened for public comment through 30 September 2026 [1][3].\n\nWhat it solves: it addresses a specific gap in card-based agentic commerce — how the parties in a card transaction (issuer, network, merchant, acquirer) consistently determine what a consumer actually authorised an AI agent to do, particularly for scenarios where authority persists over time rather than being exercised once, such as recurring purchases, cumulative spending budgets, and actions after the initial transaction (returns, disputes, modifications) [1][2]. Its central proposal is 'Intent Services': a shared, interoperable layer where participants can register, reference, retrieve and manage a consumer's authorised intent as a persistent state object, rather than each party inferring intent independently. EMVCo frames this as complementary to, not a replacement for, cryptographic intent-assurance mechanisms already in the market (it names 'Verifiable Intent' without further specifying whose) — Intent Services is positioned as a coordination point on top of that cryptographic layer [1][2].\n\nWhat it does not do: as of this verification, the document is a framework — it describes ecosystem roles and the categories of data fields Intent Services would need, not a wire protocol, message schema, API surface, or well-known discovery path. It defines no endpoint, header, or file that could be probed today. It explicitly scopes itself to card-based payments only, so it does not address bank-transfer, stablecoin, or other rails covered by protocols like x402 or ACP. It also does not yet define Know Your Agent (KYA) or 'Agentic Transaction Indicators' for flagging that a transaction was agent-initiated — EMVCo says it 'may consider' these in future publications, but they are not part of this draft [1][2].\n\nCurrent state: this is v1.0 DRAFT, released 2026-08-31/09-01, under public comment until 2026-09-30; EMVCo describes it as a foundation for further industry engagement and potential specification development, i.e. a pre-specification stage document. No implementation, pilot, or conformance programme exists yet, and none is claimed by EMVCo or any third party. EMVCo says it is collaborating with the FIDO Alliance, OpenID Foundation, OpenWallet Foundation and W3C to keep the framework interoperable with adjacent identity/credential work rather than fragmenting it [2].\n\nHow it relates to other pay-step records on this site: it overlaps in problem space with Google's AP2 (which also formalises consumer-authorised purchase intent as signed Mandates) and with UCP and OpenAI/Stripe's ACP (which define merchant-facing commerce/checkout flows an agent can invoke); EMVCo positions its work as complementary rather than competing — a card-network-side intent-coordination layer that other protocols' payment steps could plug into — but as of this draft there is no published mapping of how an AP2 Payment Mandate, a UCP Payment Token Exchange, or an ACP checkout would concretely interact with an EMVCo Intent Service. What is unresolved: whether Intent Services will be specified as an EMVCo-hosted API, a shared registry, or a set of data-field requirements that networks implement individually; how 'Verifiable Intent' (the cryptographic layer EMVCo says it complements) is itself specified and by whom; and whether this becomes a formal EMV Specification (with EMVCo's usual compliance/testing programme) or remains a lighter-weight framework.", "track": "industry-body", "version": { "date": "2026-08-31", "label": "EMV® Agentic Payments – Framework for Specifications, v1.0 DRAFT" } }, { "acronym": "ID-JAG", "adoption": { "by": null, "level": "observed", "probe_run": null }, "aliases": [ "Cross-App Access", "Cross App Access", "XAA", "Identity Assertion Authorization Grant" ], "analog": "Kerberos constrained delegation, extended to OAuth-federated SaaS: reuse the IdP's existing SSO trust instead of a new per-app consent prompt", "collisions": [], "discovery": { "mechanism": "No dedicated well-known file; advertised via OAuth 2.0 Authorization Server Metadata (RFC 8414) / OpenID Connect Discovery. The IdP Authorization Server lists grant_types_supported including urn:ietf:params:oauth:grant-type:token-exchange and identity_chaining_requested_token_types_supported including urn:ietf:params:oauth:token-type:id-jag; the Resource Authorization Server lists authorization_grant_profiles_supported including urn:ietf:params:oauth:grant-profile:id-jag and grant_types_supported including urn:ietf:params:oauth:grant-type:jwt-bearer", "path": "/.well-known/oauth-authorization-server or /.well-known/openid-configuration" }, "dispute": null, "evidence": [ { "claim": "draft-ietf-oauth-identity-assertion-authz-grant-04 (authors Aaron Parecki/Okta, Karl McGuinness/Independent, Brian Campbell/Ping Identity; last updated 2026-05-21) is an Active Internet-Draft and WG Document of the IETF OAuth Working Group, replacing the individual submission draft-parecki-oauth-identity-assertion-authz-grant (first published 2024-03). Its abstract states the mechanism lets an application use an identity assertion to obtain an access token for a third-party API via Token Exchange (RFC 8693) and the JWT Profile for OAuth 2.0 Authorization Grants (RFC 7523), and that this pattern is informally called Cross-App Access (XAA).", "date": "2026-05-21", "label": "VERIFIED", "url": "https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-assertion-authz-grant/" }, { "claim": "Section 7/8 of the same draft defines the discovery signals: a Resource Authorization Server advertises support via authorization_grant_profiles_supported containing urn:ietf:params:oauth:grant-profile:id-jag (and MUST also list urn:ietf:params:oauth:grant-type:jwt-bearer in grant_types_supported); a client advertises support via the same property plus urn:ietf:params:oauth:grant-type:token-exchange. Appendix A.4.2.1 shows a worked example of an AI Agent discovering an enterprise IdP's OpenID Connect configuration, including identity_chaining_requested_token_types_supported containing urn:ietf:params:oauth:token-type:id-jag, before performing the ID-JAG token-exchange flow on the agent's own behalf.", "date": "2026-05-21", "label": "VERIFIED", "url": "https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-assertion-authz-grant/" }, { "claim": "xaa.dev, an Okta Developer-authored sandbox, states that Cross App Access (XAA) implements the OAuth Identity Assertion Authorization Grant (ID-JAG) draft, and lets a visitor run a live 4-step XAA flow (Auth Code+PKCE sign-in, ID-JAG token exchange per RFC 8693, access-token issuance per RFC 7523, Bearer resource call per RFC 6750) against a pre-configured Identity Provider, Authorization Server, and Resource App with no account or setup required.", "date": "2026-09-07", "label": "VERIFIED", "url": "https://xaa.dev" }, { "claim": "Okta Developer published a paired guide series (Aug 21 and Aug 24, 2026) showing how an OIDC-federated application implements XAA as both a Requesting Application (exchange a refresh token for an ID-JAG, then the ID-JAG for an access token) and a Resource Application (validate the ID-JAG, resolve the user, issue a scoped access token), including registering apps in Okta and verifying the connection on xaa.dev; the requesting-app guide explicitly frames the flow as used by 'an agent (like one running in Claude)'.", "date": "2026-08-21", "label": "REPORTED", "url": "https://developer.okta.com/blog/2026/08/21/xaa-oidc-requesting" }, { "claim": "Auth0 (an Okta-owned identity platform, operated as a distinct product/brand) published guides (Aug 6 and Aug 20, 2026) describing XAA as the protocol underlying MCP's 'Enterprise-Managed Auth' extension, and walking through configuring Auth0 as an XAA Resource App to let AI agents such as Claude or Cursor reach a customer's MCP server under IT-admin-managed authorization rather than per-user consent.", "date": "2026-08-06", "label": "REPORTED", "url": "https://auth0.com/blog/xaa-protocol-auth0-ai-agents/" }, { "claim": "Descope announced (2026-09-01) Cross-App Access (XAA) support in its Agentic Identity Hub, stating it can both validate ID-JAG tokens issued by a customer's own identity provider and issue ID-JAG tokens for a customer's internal agents, positioning this as a third, independent implementation of the same draft alongside Okta and Auth0.", "date": "2026-09-01", "label": "REPORTED", "url": "https://martechseries.com/sales-marketing/id-mgmt/descope-unveils-cross-app-access-xaa-support-letting-enterprises-manage-ai-agent-access-with-their-existing-identity-providers/" } ], "form": "endpoint", "governance": "IETF OAuth (Web Authorization Protocol) Working Group; WG Document as of this verification, individual submission originated 2024-03", "group": null, "history": [ { "date": "2026-09-07", "note": "created and verified against datatracker.ietf.org/doc/draft-ietf-oauth-identity-assertion-authz-grant/ (rev -04, 2026-05-21), xaa.dev, and vendor implementation announcements from Okta, Auth0 and Descope" } ], "id": "identity-assertion-authz-grant", "implementation": "multi-implementation", "last_verified": "2026-09-07", "name": "Identity Assertion JWT Authorization Grant", "native_status": "Active Internet-Draft, WG Document (oauth WG); Intended status: Standards Track (per document front matter); IESG state: I-D Exists", "origin": { "date": "2024-03", "org": "Aaron Parecki (Okta); individual submission draft-parecki-oauth-identity-assertion-authz-grant, later co-authored with Karl McGuinness (Independent) and Brian Campbell (Ping Identity) and adopted by the IETF OAuth Working Group" }, "part_of": null, "parties": [ "agent-site" ], "phase": "working-group", "probe": { "method": "GET", "on_absent": "The Resource Authorization Server does not advertise support for ID-JAG/XAA; an app cannot obtain access to this API via identity-assertion cross-app access without out-of-band, vendor-specific configuration. Absence is not conclusive proof of non-support, since the spec allows a server to omit the discovery signal and instead disclose acceptance only via a protected, per-client mechanism", "parse": "RFC 8414 JSON metadata document; presence of \"urn:ietf:params:oauth:grant-profile:id-jag\" in authorization_grant_profiles_supported (and \"urn:ietf:params:oauth:grant-type:jwt-bearer\" in grant_types_supported, which this profile requires alongside it) indicates the Resource Authorization Server implements the Identity Assertion JWT Authorization Grant / Cross-App Access profile", "path": "https://{resource_authorization_server}/.well-known/oauth-authorization-server" }, "question": "How can an app or AI agent, already SSO-federated to a user's enterprise identity provider, obtain scoped access to a third-party API or MCP server without a fresh consent screen at that third party?", "scope": "general", "spec_url": "https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-assertion-authz-grant/", "step": "permit", "summary_md": "The Identity Assertion JWT Authorization Grant (ID-JAG) is an IETF OAuth Working Group Internet-Draft that lets an application already federated to a user's enterprise identity provider (IdP) via SSO obtain a scoped access token for a *different*, third-party resource server, without that resource server re-prompting the user for consent [1]. It is marketed by its lead editor's employer, Okta, under the informal name Cross-App Access (XAA); XAA and ID-JAG name the same specification, and 'Cross App Access' / 'XAA' are recorded here as aliases rather than a separate protocol [1][3].\n\nMechanically, a client exchanges an identity assertion (an OpenID Connect ID Token or SAML assertion, or a previously issued refresh token) at the user's IdP Authorization Server for an ID-JAG, using OAuth 2.0 Token Exchange (RFC 8693); it then redeems that ID-JAG at the target Resource Authorization Server for an ordinary OAuth access token, using the JWT Profile for OAuth 2.0 Authorization Grants (RFC 7523) [1][3]. The Resource Authorization Server still applies its own local policy and can narrow or reject the request; the IdP is not granting access on the resource server's behalf, only vouching for identity and carrying the delegation.\n\nIt solves the specific 'permit' problem of API/MCP-server access for enterprise-managed applications and AI agents: it lets IT admins centrally govern which agents can reach which downstream tools through the IdP they already trust, instead of every end user individually consenting per app [4]. It does not solve general internet-scale agent authorization the way AAuth, DAAP, and AAP (also in this dataset, also unadopted or expired individual OAuth-for-agents drafts) attempt to; ID-JAG assumes a pre-existing enterprise SSO/federation relationship between the two Authorization Servers and is not designed for an agent approaching an arbitrary, unfederated origin. It also relies on, rather than replaces, the RFC 8414/RFC 9728 Authorization Server and Protected Resource Metadata discovery layer already recorded in this dataset as oauth-metadata-for-agents; ID-JAG adds new metadata properties (authorization_grant_profiles_supported, identity_chaining_requested_token_types_supported) on top of that base rather than defining new well-known files.\n\nCurrent state (2026-09-07): the WG document is at revision -04, last updated 2026-05-21, succeeding the individual submission draft-parecki-oauth-identity-assertion-authz-grant first published 2024-03; it is an Active Internet-Draft, not yet an RFC, with Intended RFC status left blank on the Datatracker's status table despite the document text's own Standards Track heading [1]. Unlike AAuth and AAP, this draft is not expired and has active WG-track momentum.\n\nWho implements it: Okta and Auth0 (an Okta-owned brand) both ship production guides and configuration support for both the Requesting-App and Resource-App roles [4][5]; Descope announced its own, independently built ID-JAG issuance and validation support on 2026-09-01 [6]; Okta also operates xaa.dev, a public sandbox that runs a live reference flow against RFC 8693/7523/6750 [3]. No standalone client-side SDK package for ID-JAG specifically was found in this pass; implementers so far build it directly into their own IdP/Authorization-Server platforms or use their existing OAuth/OIDC libraries. What is unresolved: how many production API/MCP-server operators beyond these three identity-platform vendors and their direct customers have deployed ID-JAG; whether the spec will reach RFC status before its current expiry; and how ID-JAG's enterprise-SSO-scoped delegation model will be reconciled, if at all, with the broader, non-federated agent-authorization ambitions of AAuth, DAAP, and AAP.", "track": "ietf", "version": { "date": "2026-05-21", "label": "draft-ietf-oauth-identity-assertion-authz-grant-04 (replaces the individual draft-parecki-oauth-identity-assertion-authz-grant)" } }, { "acronym": "AIMS", "adoption": { "by": "The document's own authors and IdPro commentary describe it as broad list support (an \"A\" majority in the WIMSE WG adoption call closing 2026-08-24); the datatracker WIMSE WG document list, checked 2026-09-07, does not yet show a WG-adopted version (no draft-ietf-wimse-aiagent-auth exists)", "level": "claimed", "probe_run": null }, "aliases": [ "AIMS", "Agent Identity Management System", "AI Agent Authentication and Authorization" ], "analog": "none; closest classic-web analog is a service-account/workload-identity framework (e.g. cloud IAM roles) applied to a new class of caller", "collisions": [ "AIP (Agent Identity Protocol, a different, unrelated DID-based individual draft already tracked as its own record)" ], "discovery": { "mechanism": "none; this is a best-practices/architecture framework document, not a discoverable wire protocol with its own well-known path", "path": "none" }, "dispute": { "claims": [ "Adoption is confirmed and imminent (author/IdPro framing, 2026-07-29 and 2026-08-24 sources)", "Adoption is a starting point only, not a blessing of every line, and the document still has open security gaps the WG must resolve (WIMSE chair Justin Richer and multiple list commenters, per the 2026-08-24 report)", "As of 2026-09-07 no WG-adopted document exists yet in the datatracker, so formal adoption has not been finalized" ], "summary": "The draft is in a live WIMSE working-group adoption process: a formal call for adoption closed 2026-08-24 with broad list support for adopting it as a WG starting point, but as of 2026-09-07 the datatracker's WIMSE WG document list still shows no draft-ietf-wimse-aiagent-auth — only the individual draft-klrc-aiagent-auth-03 exists. Reviewers on the WIMSE list flagged unresolved gaps: no defined revocation path for a subverted-but-still-validly-credentialed agent, no per-hop scope narrowing or chain verification for multi-hop agent-to-agent delegation (at least one reviewer reported a confused-deputy escalation path), disagreement over modeling agent identity purely as workload identity, and concern that cryptographic signing material should not live inside AI workloads that often run with broad sandbox privileges." }, "evidence": [ { "claim": "draft-klrc-aiagent-auth-03, \"AI Agent Authentication and Authorization\", is an Active Internet-Draft (individual submission, not a WG document), last updated 2026-07-06, expires 2027-01-07, authored by Pieter Kasselman, Jeff Lombardo (AWS), Yaroslav Rosomakho (Zscaler), Brian Campbell (Ping Identity), Nick Steele (OpenAI) and Aaron Parecki. Its abstract states it proposes best practices for AI agent authentication and authorization by leveraging existing standards — the WIMSE architecture and the OAuth 2.0 family — rather than defining new protocols, to provide a framework, identify gaps, and guide future standardization.", "date": "2026-07-06", "label": "VERIFIED", "url": "https://datatracker.ietf.org/doc/draft-klrc-aiagent-auth/" }, { "claim": "The IETF WIMSE working group document list (Active Internet-Drafts, 6 hits, checked 2026-09-07) contains draft-ietf-wimse-wpt, draft-ietf-wimse-http-signature, draft-ietf-wimse-arch, draft-ietf-wimse-identifier, draft-ietf-wimse-mutual-tls and draft-ietf-wimse-workload-creds. No draft-ietf-wimse-aiagent-auth (or any WG-adopted version of the AIMS draft) appears in that list or in the WG's \"Related Internet-Drafts\" section, which instead lists several other, separate individual drafts on agent delegation (e.g. draft-asor-wimse-agent-delegation-chain, draft-reece-wimse-cross-org-delegation, draft-sweeney-wimse-credential-delegation).", "date": "2026-09-07", "label": "VERIFIED", "url": "https://datatracker.ietf.org/wg/wimse/documents/" }, { "claim": "WIMSE WG chair Justin Richer opened a formal call for adoption of draft-klrc-aiagent-auth (referred to by the authors as AIMS) as a WIMSE working-group document, with responses due 2026-08-24; co-author Pieter Kasselman recused himself from chairing the process. List response was broad support for adoption, with most respondents treating remaining technical gaps (revocation of subverted-but-credentialed agents, multi-hop delegation scope narrowing and chain verification, a reported confused-deputy escalation path, and whether cryptographic signing material belongs inside AI workloads) as post-adoption work rather than blockers.", "date": "2026-08-24", "label": "REPORTED", "url": "https://freenode.net/article/wimse-moves-to-adopt-ai-agent-auth-framework-draft" }, { "claim": "Co-author Jeff Lombardo's own account (IdPro blog) describes AIMS (Agent Identity Management System) as a layered framework composing existing standards — WIMSE identifiers (a superset of SPIFFE IDs) for identifiers, WIMSE Workload Identity Tokens / X.509 / SPIFFE JWT-SVIDs for credentials, mTLS / HTTP Message Signatures / WIMSE Proof Tokens for authentication, OAuth 2.0 flows (authorization code, client credentials, token exchange, ID-JAG identity chaining) for delegated authorization, and OpenID Shared Signals Framework / CAEP / RISC for observability and revocation — explicitly not defining any new wire protocol.", "date": "2026-07-29", "label": "REPORTED", "url": "https://idpro.org/how-we-stopped-reinventing-and-started-composing-standards-for-agentic-identity/" } ], "form": "document-format", "governance": "Individual IETF Internet-Draft under consideration by the IETF WIMSE working group (Applications and Real-Time Area); not yet a WG document as of 2026-09-07. Chairs of WIMSE: Justin Richer and Pieter Kasselman (a co-author of this draft, recused from chairing this specific adoption process).", "group": null, "history": [ { "date": "2026-09-07", "note": "created from IETF datatracker (draft-klrc-aiagent-auth-03), WIMSE WG document list, and reporting on the 2026-08-24 WIMSE adoption call" } ], "id": "aiagent-auth", "implementation": "unknown", "last_verified": "2026-09-07", "name": "AI Agent Authentication and Authorization (AIMS)", "native_status": "Active Internet-Draft (individual submission), Internet-Draft, no RFC stream and no intended RFC status assigned; expires 2027-01-07", "origin": { "date": "2026-03", "org": "Pieter Kasselman (independent; WIMSE WG co-chair), Jeff Lombardo (AWS), Yaroslav Rosomakho (Zscaler), Brian Campbell (Ping Identity), Nick Steele (OpenAI), Aaron Parecki" }, "part_of": null, "parties": [ "agent-site", "agent-agent" ], "phase": "draft", "probe": { "method": "GET", "on_absent": "The draft is a best-practices framework, not a deployable protocol with its own presence signal; absence of adoption means only the individual draft-klrc-aiagent-auth-03 text exists, with no WG document, no registered media type, and no fixed discovery path to probe for", "parse": "not applicable — this record has no probeable wire signal; readers should instead probe the underlying components it composes (SPIFFE Workload API, WIMSE credential/token endpoints, OAuth 2.0 discovery metadata), each tracked as its own record", "path": "none" }, "question": "Is there an IETF-endorsed way to authenticate and authorize an AI agent, and has the WIMSE working group actually taken this on?", "scope": "general", "spec_url": "https://datatracker.ietf.org/doc/draft-klrc-aiagent-auth/", "step": "identify", "summary_md": "AI Agent Authentication and Authorization — informally called AIMS (Agent Identity Management System) by its authors — is an IETF Internet-Draft that proposes best practices for authenticating and authorizing AI agents by composing existing standards, principally the WIMSE architecture and the OAuth 2.0 family, rather than by defining any new wire protocol [1]. Its core thesis, as described by co-author Jeff Lombardo, is that an AI agent should be modeled as a workload: it needs an identifier, credentials that cryptographically bind to that identifier, a way to authenticate to other systems, and a way to request delegated authorization, all of which the identity community has already built for services and microservices [4].\n\nIt solves the \"assembly gap\" rather than a standards gap: instead of inventing new token formats or credential lifecycles for agents, it maps WIMSE identifiers (a superset of SPIFFE IDs) to identifiers, WIMSE Workload Identity Tokens / X.509 / SPIFFE JWT-SVIDs to credentials, mTLS and HTTP Message Signatures and WIMSE Proof Tokens to authentication, and OAuth 2.0 flows — authorization code for delegated user flows, client credentials for autonomous agents, token exchange and ID-JAG identity chaining for multi-domain workflows — to authorization, with the OpenID Foundation's Shared Signals Framework, CAEP and RISC left as the mechanism for observability and revocation [4]. It explicitly does not define any new protocol, does not pick a single policy/compliance standard (deliberately left deployment-specific), and — as of the version reviewed — does not close several hard problems: it has no defined way to revoke a subverted agent that still holds a validly attested credential, no settled per-hop scope-narrowing or chain-verification mechanism for multi-hop agent-to-agent delegation (at least one WIMSE list reviewer reported a confused-deputy escalation path under the current grant patterns), and does not resolve where cryptographic signing material should live given that AI workloads often run with broad sandbox privileges [3].\n\nCurrent state, and the specific adoption question this record was created to check: the document is draft-klrc-aiagent-auth-03, an individual submission, last updated 2026-07-06, with no RFC stream and no intended RFC status set, expiring 2027-01-07 [1]. WIMSE WG chair Justin Richer opened a formal call for the working group to adopt it (co-author Pieter Kasselman, who also co-chairs WIMSE, recused himself from that process); the call closed 2026-08-24 with broad list support, most commenters treating the open technical gaps as post-adoption work rather than blockers [3]. However, checking the IETF datatracker's live WIMSE WG document list on 2026-09-07 — after that call closed — shows no draft-ietf-wimse-aiagent-auth or any other WG-adopted successor document; the WG's six active documents are unrelated WIMSE deliverables (architecture, workload proof tokens, HTTP signatures, identifiers, mutual TLS, workload credentials), and the WG's own \"related drafts\" list shows several other individual proposals on agent delegation instead. So: broad support for adoption exists on the list, but as of this check formal WG adoption has not yet been completed or reflected in the datatracker — this record should not claim WIMSE has adopted it.\n\nWho implements it: no implementation was located; this is a framework/best-practices document, not a protocol with conformance software, so \"implementation\" here would mean deployments that follow its composition guidance, and none was independently verified in this pass.\n\nDisputed or unknown: whether and when formal WG adoption completes; whether the final adopted scope keeps the AIMS name or the informal acronym; how the unresolved revocation and multi-hop delegation gaps get closed once (if) the WG owns the document; and how this composition-first approach will relate to competing agent-identity proposals also sitting in WIMSE's orbit (e.g. draft-asor-wimse-agent-delegation-chain, draft-reece-wimse-cross-org-delegation, draft-sweeney-wimse-credential-delegation), none of which this pass reviewed in depth.", "track": "ietf", "version": { "date": "2026-07-06", "label": "draft-klrc-aiagent-auth-03, individual submission, expires 2027-01-07" } }, { "acronym": "DAN", "adoption": { "by": null, "level": "unmeasured", "probe_run": null }, "aliases": [ "AIDISCA/AIINDEX", "draft-seethiraju-dawn-dan" ], "analog": "DNS-based Authentication of Named Entities (DANE) for TLS certificates, applied to agent discovery instead of TLS", "collisions": [ "DNS-AID (unrelated IETF dnsop draft, SVCB-based, Infoblox/Deutsche Telekom/Amazon/GoDaddy)", "AID (agentcommunity.org, TXT-based, unrelated authorship)", "ANS/Agent Name Service v2 (dual-certificate + SCITT transparency log, unrelated authorship)", "DAN also collides with the unrelated 'Do Anything Now' AI jailbreak prompt meme" ], "discovery": { "mechanism": "Two new DNS Resource Record types resolved directly (no well-known HTTP path). AIINDEX, published at a zone's _agents label, enumerates the AI agent publication names available in that zone. AIDISCA, published at each agent's own name, atomically carries protocol identifier, coarse-grained capabilities, service endpoint, and a DANE-style embedded certificate association — no separate TLSA lookup is needed.", "path": "_agents. (AIINDEX, TYPE65502); ._agents. (AIDISCA, TYPE65501)" }, "dispute": { "claims": [ "DAN: two new RR types AIDISCA/AIINDEX, DANE-style cert embedded in-record, Verisign individual submission", "DNS-AID: SVCB records at agent + _index._agents labels, IETF dnsop draft, Infoblox/Deutsche Telekom/Amazon/GoDaddy", "AID: single TXT record at _agent., agentcommunity.org, community-governed" ], "summary": "DAN is the third independent IETF-adjacent proposal to bind AI-agent discovery metadata to DNS, alongside DNS-AID (draft-mozleywilliams-dnsop-dnsaid, SVCB records, Infoblox/Deutsche Telekom/Amazon/GoDaddy) and AID (agentcommunity.org, TXT records). Unlike both, DAN does not reuse an existing RR type (SVCB or TXT): it defines two brand-new RR types (AIDISCA, AIINDEX) that must be published in RFC3597 generic form until IANA assigns mnemonics, and it embeds the certificate association directly inside AIDISCA rather than pointing to a separate DANE TLSA record. No evidence was found in this pass that Verisign's draft references, cites, or coordinates with the DNS-AID or AID authors, or vice versa; all three compete to answer the same 'discover' question with incompatible DNS shapes." }, "evidence": [ { "claim": "draft-seethiraju-dawn-dan-00 (5 June 2026, Verisign authors Seethiraju/Thakar/Shyamsunder/Osterweil, Intended status Standards Track, individual IETF submission with no working-group sponsorship, IESG state 'I-D Exists') defines the AIDISCA and AIINDEX DNS RR types, their RDATA formats, a client processing model, and IANA considerations for a new 'AI Agent Proto' registry and 'AI Agent DNS Extension Code' registry.", "date": "2026-06-05", "label": "VERIFIED", "url": "https://datatracker.ietf.org/doc/draft-seethiraju-dawn-dan/" }, { "claim": "The verisign/dan GitHub repository is an open-source proof-of-concept reference implementation providing dan-gen.py (generates AIDISCA/AIINDEX records in RFC3597 presentation format from MCP endpoint or A2A agent-card metadata plus a certificate file) and dan-discover.py (resolves and human-readably prints published AIDISCA/AIINDEX records); as of the last commit (18 Jul 2026) it has 0 stars/0 forks and demonstrates only example domains (namestudioapi.com, colinmcnamara.com), not confirmed production deployments.", "date": "2026-07-18", "label": "VERIFIED", "url": "https://github.com/verisign/dan" }, { "claim": "Verisign's own blog post (1 Sep 2026, co-authored by all four draft authors) announces the DAN Internet-Draft, frames it as extending DANE semantics to AI agent discovery, and states Verisign has published a royalty-free public IPR license to support standardization; it does not claim any third-party adoption.", "date": "2026-09-01", "label": "VERIFIED", "url": "https://blog.verisign.com/security/proposed-dns-record-types-ai-agent-discovery/" } ], "form": "dns-record", "governance": "IETF Independent Submission (individual draft; not sponsored by a chartered working group; 'dawn' in the draft filename is a keyword, not a working-group name)", "group": null, "history": [ { "date": "2026-09-07", "note": "created as a new discover-step record; verified against draft-seethiraju-dawn-dan-00 (datatracker.ietf.org), the verisign/dan proof-of-concept repository, and Verisign's 2026-09-01 blog announcement" } ], "id": "dan", "implementation": "prototype", "last_verified": "2026-09-07", "name": "DNS-Based Agent Naming", "native_status": "Active Internet-Draft (individual, -00), Intended status: Standards Track; IESG state 'I-D Exists'; expires 7 December 2026", "origin": { "date": "2026-06-05", "org": "Ramachandra Rao Seethiraju, Sameer Thakar, Karthik Shyamsunder, Eric Osterweil (Verisign) — IETF Independent Submission" }, "part_of": null, "parties": [ "agent-agent", "agent-registry" ], "phase": "draft", "probe": { "method": "DNS query", "on_absent": "No AIINDEX/AIDISCA records resolve at this zone; the domain does not publish DAN-discoverable agents. Because the two RR types are not yet IANA-assigned to stable mnemonics, records are typically published and queried in RFC3597 generic form (TYPE65501/TYPE65502); most public DNS resolvers, zone editors, and tooling do not recognize AIDISCA/AIINDEX by name yet.", "parse": "AIINDEX RDATA contains an AI Agent Domain Name List (each entry a domain name under the zone); AIDISCA RDATA contains AI Agent Proto (1=MCP, 2=A2A), Capabilities (comma-separated string), Service Endpoint (URL), and Certificate Association Data (DANE-style usage/selector/matching-type + hash), plus an optional Extensions field (e.g. an A2A Agent Card URL)", "path": "QNAME=_agents.{origin} QTYPE=TYPE65502 (AIINDEX) to enumerate published agents; then QNAME=._agents.{origin} QTYPE=TYPE65501 (AIDISCA) for each listed name" }, "question": "Given a domain, which AI agents does it publish, and how can I locate and cryptographically bind to their service endpoint using DNS alone?", "scope": "general", "spec_url": "https://datatracker.ietf.org/doc/draft-seethiraju-dawn-dan/", "step": "discover", "summary_md": "DNS-Based Agent Naming (DAN) is an IETF Internet-Draft from Verisign that proposes two brand-new DNS Resource Record types — AIDISCA and AIINDEX — so that an AI agent's discovery metadata can be published and resolved directly through DNS, the way DANE (RFC 6698) binds TLS certificates to domain names [1]. AIINDEX, published at a zone's `_agents` label, lists the AI agent publication names available under that zone; AIDISCA, published at each such agent name, atomically carries the protocol identifier (MCP or A2A), a coarse capabilities string, the service endpoint URL, and a DANE-style embedded certificate association, all in one record [1].\n\nIt solves the same problem DNS-AID and AID solve — given a domain, find and cryptographically bind to the agents it publishes — but takes a different technical path: rather than reusing SVCB (DNS-AID) or TXT (AID), it mints two entirely new RRtypes and folds the certificate binding into the discovery record itself instead of a separate TLSA lookup, on the theory that this minimizes DNS round-trips [3]. It does not define semantic search, ranking, policy evaluation, or agent selection — the draft states these are explicitly out of scope — and it does not yet have IANA-assigned RRtype mnemonics, so records must currently be published in RFC3597 generic form (TYPE65501/TYPE65502) using ordinary DNS zone tooling [1].\n\nCurrent state as of 2026-09-07: a single version, draft-seethiraju-dawn-dan-00, dated 5 June 2026, submitted as an individual (non-working-group) Internet-Draft with Intended status Standards Track; IESG state is 'I-D Exists' with no telechat scheduled and no responsible Area Director assigned, meaning it has not been adopted by any IETF working group [1]. Verisign published the draft alongside a supporting arXiv paper and, on 1 September 2026, a blog post announcing a royalty-free public IPR license intended to support eventual standardization [3].\n\nWho implements it: only Verisign itself, via the open-source `verisign/dan` proof-of-concept repository, which provides `dan-gen` (generates AIDISCA/AIINDEX records from MCP endpoint or A2A agent-card metadata) and `dan-discover` (resolves and prints them). The repo's examples use illustrative domains rather than confirmed production deployments, and the repository shows no external stars, forks, or contributors as of its last commit (18 July 2026) [2].\n\nDisputed or unknown: DAN, DNS-AID, and AID are three separately authored, technically incompatible DNS-based discovery mechanisms competing to answer the same question, and no evidence was found that any of the three coordinates with or references the others. Whether DAN will be adopted by an IETF working group, merge with a competing draft, or remain an individual submission is unresolved. No third-party adopter, registrar, or DNS host has been found announcing support for DAN specifically (contrast with DNS-AID, which Infoblox and GoDaddy have publicly named).", "track": "ietf", "version": { "date": "2026-06-05", "label": "draft-seethiraju-dawn-dan-00, 5 June 2026 (single published version; no -01 as of 2026-09-07)" } } ]