All posts
· 10 min read ·

AGNTCY and AAIF: two Linux Foundation projects, two different bets on the agent stack

Both AGNTCY and AAIF live under the Linux Foundation. Both cover discovery, identity, and observability. They aren't the same project — they're two structurally different bets on whether the agent stack standardizes from the substrate up or from the popular projects down.

The Linux Foundation now houses two distinct agent-infrastructure projects under directed-fund governance. AGNTCY ("Internet of Agents") joined the foundation on July 29, 2025, originally open-sourced by Cisco in March 2025 with formative members including Cisco, Dell, Google Cloud, Oracle, and Red Hat. AAIF (the Agentic AI Foundation) formed on December 9, 2025, anchored by MCP, goose, and AGENTS.md, with Platinum members AWS, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft, and OpenAI. Both are stewarded by the same Linux Foundation. Both cover discovery, identity, observability, and messaging concerns. Neither treats the other as a subset of itself.

The reading most coverage offers, that AGNTCY and AAIF are the same project under different names, is wrong. They are two foundations making two structurally different bets on what the agent stack should standardize, and the bets are different enough that a consumer who adopts one is not automatically adopting the other.

Where the two projects overlap, and where they don't

AGNTCY's stated scope is "the foundational infrastructure for the Internet of Agents," covering four named pillars: Agent Discovery (using the Open Agent Schema Framework, OASF), Agent Identity (cryptographically verifiable agent IDs), Agent Messaging (the SLIM transport, including quantum-safe and human-in-the-loop modes), and Agent Observability. AAIF's stated scope is narrower at the project level — it anchors specific donated projects (MCP, goose, AGENTS.md) and provides governance scaffolding for their evolution. The differences at the layer the writer of an agent actually consumes:

AGNTCY vs AAIF scope, by concern A coverage matrix with seven concerns down the left and three columns: AGNTCY, AAIF, both. Filled circles indicate which foundation owns each concern. Discovery and Identity each have a strong presence in both projects but under different specifications. Observability is shared but with different conventions. Messaging belongs to AGNTCY; tool protocol belongs to AAIF. LINUX FOUNDATION AGENT STACK · COVERAGE BY PROJECT

AGNTCY AAIF overlap

Discovery OASF schema vs MCP Registry

Identity AGNTCY agent IDs vs A2A signed cards

Messaging transport SLIM (AGNTCY) only

Tool protocol MCP (AAIF) only

Observability AGNTCY tooling + OpenTelemetry GenAI

Coding-agent conventions

The diagram makes the picture concrete. Discovery, identity, and observability appear in both foundations as nominally addressed — but with different specifications. Each foundation has at least one exclusive area (SLIM for AGNTCY, MCP and AGENTS.md for AAIF) and the "overlap" column is real but represents different specs solving the same concern, not shared deliverables.

Why two foundations, structurally

The two projects' origin stories explain the parallel governance. AGNTCY was open-sourced by Cisco (a networking-first vendor), and its architecture reflects that lineage: Discovery, Identity, and Messaging are the names a network engineer would give the same problems an operating-system engineer would call Service Discovery, PKI, and Transport. SLIM is a transport, not a protocol layered on HTTP. OASF is a schema, modeled on the Open Cybersecurity Schema Framework, which is itself a Linux Foundation project. The AGNTCY view of the agent stack is bottom-up: get the substrate right and the application layer follows.

AAIF was formed by anchoring three already-popular projects: MCP (Anthropic, the tool-protocol that the Claude ecosystem already depended on), goose (Block's local-first agent runtime), AGENTS.md (OpenAI's repo-context convention). Its identity and observability work follow from what those projects need; the foundation's top-priority deliverables are conformance, governance, and lifecycle policy for the projects already absorbed. The AAIF view of the agent stack is top-down: codify the popular projects first and standardize their interactions as the work demands it.

Both views are coherent. The Internet's TCP/IP stack and the Web's HTTP/HTML stack each started under similar tension between substrate-first and application-first standardization. The shape of that resolution took a decade.

What this means for builders

If you ship an agent that needs to interoperate at the public internet level, you face an immediate composition question. Pick the wrong combination and you end up shipping with two identity mechanisms, two observability layers, and two transport modes — each correct in isolation, all duplicative in deployment. The questions a serious builder answers before integrating:

  • Identity. Does the agent publish an A2A Signed Agent Card (AAIF lineage), an AGNTCY-style cryptographic identity (AGNTCY lineage), an ERC-8004 token ID, or all three? A consumer probing the agent will see whichever the card publishes.
  • Discovery. Does the agent appear in the AAIF MCP Registry, in AGNTCY's directory, in aggregator catalogs like Glama, or only in the operator's private registry? Each surface has different curation policy.
  • Transport. Is HTTP enough, or does the deployment need SLIM's multi-modal and quantum-safe modes? The latter is a network choice with cost implications that the former does not impose.
  • Observability. Will agent telemetry use OpenTelemetry's GenAI Semantic Conventions (the de-facto convergence layer), AGNTCY's own observability primitives, or both? Practitioners are already shipping both for the same agent.

The default outcome, for an agent built without these decisions made up front, is to inherit whichever subset the agent's framework or deployment platform happens to choose. The cost of that default shows up in the production phase, not at design time.

What a registry should publish across two foundations

The Agenstry-relevant observation is that a downstream consumer reading a card today cannot tell, from the card alone, which foundation's specifications the agent was designed against. The A2A Signed Agent Card format is AAIF-lineage; OASF's capability schema is AGNTCY-lineage; the two can describe the same agent from different sides without contradicting each other and also without composing automatically. A consumer reading "this is an agent" learns less than they think.

A registry that publishes the agent against both schemas, flagging which fields are populated against which, is doing the disambiguation work the consumer otherwise has to do at the integration boundary. That is the same shape of work the funnel publishes: turning a single self-declared claim into a multi-dimensional, source-attributed signal.

What we're watching

Three things, observable within the next two quarters:

  1. Whether AGNTCY and AAIF publish a joint-interoperability profile. A document naming which AGNTCY identity claims correspond to which A2A signed-card fields, and vice versa, would close the most immediately load-bearing gap a builder faces today. The two foundations both state interoperability as a goal; the profile is the test.
  2. Whether the OpenTelemetry GenAI conventions absorb AGNTCY's observability schema or vice versa. Two parallel observability schemas for the same span set is not a stable state. The first convergence statement will tell the field which of the two is the substrate.
  3. Whether an enterprise platform team publicly ships a deployment that uses both AGNTCY and AAIF projects in concert. Uber's gateway is the obvious candidate. The first publicly described joint deployment will be the case study every subsequent integrator reads.

Two Linux Foundation projects covering related infrastructure is not inherently a problem. It is, however, a problem the consumers of that infrastructure are now responsible for understanding. The foundations' overlap is a feature of how the agent stack was built; the disambiguation is a problem the registry layer is best positioned to solve.

Sources

← Back to blog Agenstry