Cisco’s Outshift built an open, vendor-neutral stack for agents to discover, identify, message, and observe each other. Here is how the AGNTCY internet of agents actually works in 2026.
What is AGNTCY, in one paragraph?
AGNTCY is an open, vendor-neutral set of infrastructure components that lets AI agents built by different teams discover, identify, message, and observe one another — the plumbing for what its founders call the “internet of agents.” It was open-sourced in March 2025 by Outshift, Cisco’s incubation division, together with LangChain and Galileo as core maintainers, and contributed to the Linux Foundation on July 29, 2025.
The pitch is deliberately analogous to the early internet. Just as TCP/IP and DNS let independently built computers interconnect, AGNTCY aims to give independently built agents a common substrate for finding each other and collaborating across organizational and framework boundaries. As Vijoy Pandey, GM and SVP of Outshift by Cisco, framed it, “Building the foundational infrastructure for the internet of agents requires community ownership, not vendor control.”
Crucially, the AGNTCY internet of agents is not another agent framework competing with LangGraph, CrewAI, or AutoGen, and it is not trying to replace A2A or MCP. It standardizes the layers those tools tend to leave unsolved: how agents are described in a registry, how their identities are cryptographically verified, how they send secure group messages, and how you observe the whole mess in production.
AGNTCY (pronounced “agency”) is a Linux Foundation project providing open-source building blocks for multi-agent interoperability. Think of it as the discovery, identity, messaging, and observability fabric beneath your agents — not the agents themselves.
What are the components of the AGNTCY internet of agents?
The AGNTCY internet of agents is organized into five functional layers: Agent Discovery, Agent Identity, Agent Messaging, Observability, and Protocol Integration. Each maps to one or more open-source repositories under the agntcy GitHub organization, and each is designed to be adopted independently rather than as an all-or-nothing bundle.
Discovery rests on the Open Agentic Schema Framework (OASF) — an OCI-based, extensible data model that describes an agent’s attributes and capabilities and gives it a unique identifier. OASF can describe A2A agents and MCP servers, and is extensible to other formats. Paired with the Agent Directory (the dir project), any organization can run its own directory and keep it in sync with others, forming a federated inventory of available agents.
Messaging is handled by SLIM (Secure Low-latency Interactive Messaging), a Rust implementation that extends gRPC to add pub/sub on top of request/reply, streaming, and fire-and-forget patterns. SLIM’s headline features are security-led: Messaging Layer Security (MLS) for group encryption and quantum-safe cryptography, aimed squarely at regulated, multi-org deployments where transport security is non-negotiable.
You do not need the whole stack. Teams with a discovery problem start with OASF plus the Directory; teams with a security-and-transport problem start with SLIM. Each layer is a separate repo with its own SDK.
| Layer | Component / project | What it does | Relationship to A2A and MCP |
|---|---|---|---|
| Agent Discovery | OASF + Agent Directory (dir) | Describes agent capabilities in an extensible schema; federated registry for announcing and finding agents | Makes A2A agents and MCP servers discoverable via a common schema |
| Agent Identity | identity / identity-service | Cryptographically verifiable, decentralized identity for agents and tools across organizations | Adds verifiable identity that neither A2A nor MCP defines on its own |
| Agent Messaging | SLIM | Secure, MLS-backed, quantum-safe group messaging; pub/sub, streaming, request/reply over an extended gRPC | Can carry A2A traffic as a transport; complements rather than replaces it |
| Observability | Observe / eval tooling | End-to-end telemetry and evaluation for debugging multi-agent workflows | Instruments agents regardless of whether they speak A2A or MCP |
| Protocol Integration | ACP, A2A and MCP bridges | Connective tissue to existing protocols; OASF imports A2A and MCP descriptors | Explicitly interoperable, not a competing protocol |
How does AGNTCY relate to A2A and MCP?
AGNTCY is explicitly designed to complement A2A and MCP, not compete with them — it makes A2A agents and MCP servers discoverable through its directories and can transport A2A messages over SLIM. The simplest mental model: MCP is the vertical layer (an agent talking to tools, data, and context), A2A is the horizontal layer (agents delegating to and coordinating with other agents), and AGNTCY supplies the surrounding fabric — discovery, identity, secure transport, and observability — that both layers assume but neither fully provides.
The one place AGNTCY’s scope visibly overlapped with A2A was its own Agent Connect Protocol (ACP), a REST/OpenAPI-based spec for invoking and configuring remote agents over HTTP. ACP mapped agent interactions onto familiar verbs — POST to create a task, GET to check status — so any HTTP client could drive an agent without a bespoke SDK. That made it attractive to teams already running API gateways and OpenAPI tooling.
In 2026, the agent-to-agent invocation layer has been consolidating around A2A as the de facto standard, and AGNTCY’s acp-spec repository was archived (read-only as of April 11, 2026). This is convergence, not failure: it reflects a community decision that one agent-to-agent standard beats two, leaving AGNTCY to focus on the discovery, identity, messaging, and observability layers where it is differentiated.
“MCP is the vertical layer, A2A is the horizontal layer, and AGNTCY is the fabric both assume but neither fully provides.”
The clean way to reason about the 2026 agent stack
Who is behind AGNTCY, and is it really vendor-neutral?
Mar 2025
Open-sourced
By Outshift (Cisco) with LangChain and Galileo
Jul 29, 2025
Joined Linux Foundation
Cisco, Dell, Google Cloud, Oracle, Red Hat as formative members
65+
Supporting companies
Reported at the time of the foundation transfer
AGNTCY was created by Outshift by Cisco with LangChain and Galileo, then donated to the Linux Foundation in July 2025, with Cisco, Dell Technologies, Google Cloud, Oracle, and Red Hat joining as formative members. By the time of the foundation transfer, the project reported more than 65 supporting companies, a notable amount of industry coalescence for a standard barely a year old.
The governance move matters more than the logos. A single-vendor SDK can be re-licensed, paywalled, or quietly deprecated on a product roadmap; a Linux Foundation project has neutral stewardship, an open contribution model, and a charter that makes unilateral capture much harder. That is the difference between building on plumbing you can rely on versus plumbing that can be turned off.
The division of labor among the founders is instructive. Cisco’s Outshift brought the networking and security DNA evident in SLIM and the identity layer; LangChain contributed agent-framework and orchestration expertise; and Galileo, an observability and evaluation specialist, anchored the telemetry layer. The result reads less like one vendor’s product and more like a coalition assembling the parts each does best.
How would you actually build on AGNTCY?
In practice you adopt AGNTCY one layer at a time: publish your agent to a Directory using an OASF record, attach a verifiable identity, optionally route traffic over SLIM, and instrument everything with the observability tooling. The SDKs are spread across language ecosystems — OASF and the Directory in Go, SLIM in Rust, the identity service in TypeScript — with a Python app SDK pulling the pieces together for end-to-end reference apps like coffeeAgntcy.
A realistic onboarding sequence looks like the steps below. Start with discovery because it is the lowest-risk, highest-leverage piece: a clean OASF record makes your agent findable without committing you to any particular transport or framework. Layer in identity and SLIM only where your threat model and latency requirements justify them.
Because the components are decoupled, you can keep your existing A2A or MCP integrations untouched and bolt AGNTCY on around them. That is the entire design intent — additive infrastructure rather than a migration.
The agent-to-agent invocation space is still consolidating. Wire your runtime to A2A for invocation and treat AGNTCY’s strength as the surrounding layers — discovery, identity, SLIM transport, and observability — rather than betting on a still-settling RPC spec.
# A pragmatic AGNTCY adoption path
1. DESCRIBE Write an OASF record for your agent (capabilities, schema, ID)
2. PUBLISH Announce it to an Agent Directory (dir); federate to partners
3. IDENTIFY Issue a cryptographically verifiable identity (identity-service)
4. TRANSPORT Optionally route messages over SLIM (MLS + quantum-safe)
5. OBSERVE Wire telemetry/eval tooling for end-to-end debugging
6. INVOKE Keep A2A/MCP for agent-to-agent and tool callsWhich language SDK do I need?
It depends on the layer. OASF, the Directory, and identity onboarding ship Go SDKs; SLIM is implemented in Rust with client libraries; the identity service is TypeScript; and there is a Python app SDK for stitching components into reference applications. Check the per-repo READMEs under github.com/agntcy for current language coverage before you commit.Do I have to replace my current framework?
No. AGNTCY is intentionally framework-agnostic and additive. You keep LangGraph, CrewAI, or your own runtime and use AGNTCY for discovery, identity, secure transport, and observability around it. Nothing about adopting OASF forces a rewrite of your agent logic.Is the messaging layer production-ready for regulated workloads?
SLIM is built around MLS group encryption and quantum-safe cryptography, which is exactly what regulated, multi-organization deployments need. As with any young protocol, validate it against your own compliance requirements and run a contained pilot before making it the backbone of a critical workflow.Who should actually care about AGNTCY in 2026?
Adopt the layers, not the religion — AGNTCY is real infrastructure worth tracking
AGNTCY matters most to platform and infrastructure teams running multi-agent systems across organizational boundaries — and matters far less to a developer shipping a single agent inside one application. If your agents all live in one codebase and one trust boundary, the discovery and federated-identity layers solve problems you do not yet have.
The clearest fit is enterprises and vendors who need agents from different companies to find and trust each other: a procurement agent calling a supplier’s agent, a bank’s agent verifying a fintech partner’s agent, or any marketplace where agents are published by parties who never coordinated in advance. For those scenarios, OASF discovery, verifiable identity, and SLIM’s secure transport are directly load-bearing.
For everyone else, the right posture is to track AGNTCY, adopt OASF for describing your agents (cheap insurance for future interoperability), and lean on A2A and MCP for the day-to-day work. The verdict below sums up where I land after building on these standards.
Builder’s take
I build Cyntr, an agent-orchestration runtime, so I read every new interoperability standard through one lens: does it reduce the glue code I have to write and maintain? AGNTCY is the most complete attempt yet to standardize the boring-but-critical layers under multi-agent systems, and it is refreshingly honest about staying out of A2A’s and MCP’s lanes.
- Treat AGNTCY as plumbing, not a framework. Adopt OASF and the Directory first if you have a discovery problem; you do not need to swallow the whole stack to get value.
- SLIM is the part I would pilot earliest in regulated workloads. Quantum-safe, MLS-backed group messaging is genuinely hard to build yourself, and it is the layer most teams under-invest in until an audit forces the issue.
- Do not bet your transport on a protocol that is still settling. The Agent Connect Protocol repo was archived as the agent-to-agent layer converged on A2A, so wire your runtime to A2A for invocation and use AGNTCY for the layers A2A does not cover.
- Vendor-neutral governance is the real product here. Linux Foundation stewardship is why I would build against AGNTCY over a single-vendor SDK that can be deprecated on a roadmap whim.
Frequently asked questions
No. MCP connects an agent to tools and context, and A2A handles agent-to-agent coordination. AGNTCY is the surrounding infrastructure — discovery, identity, secure messaging, and observability — and is explicitly interoperable with both. It makes A2A agents and MCP servers discoverable rather than competing with them.
AGNTCY was open-sourced in March 2025 by Outshift, Cisco’s incubation division, with LangChain and Galileo as core maintainers. It was contributed to the Linux Foundation on July 29, 2025, with Cisco, Dell Technologies, Google Cloud, Oracle, and Red Hat as formative members and 65-plus supporting companies.
Agent Discovery (the Open Agentic Schema Framework plus a federated Agent Directory), Agent Identity (cryptographically verifiable, decentralized), Agent Messaging (the SLIM protocol, MLS-backed and quantum-safe), Observability (telemetry and evaluation), and Protocol Integration (bridges to A2A and MCP).
OASF, the Open Agentic Schema Framework, is an OCI-based, extensible data model that describes an agent’s capabilities and assigns it a unique identifier. It can describe A2A agents and MCP servers and is the foundation of AGNTCY’s discovery layer, used together with the Agent Directory project.
ACP was AGNTCY’s REST/OpenAPI-based spec for invoking remote agents over HTTP. As the industry consolidated on A2A as the standard agent-to-agent invocation layer in 2026, AGNTCY’s acp-spec repository was archived (read-only as of April 11, 2026). It is a convergence toward a single standard, not a project failure.
Adopt it if you run multi-agent systems across organizational or trust boundaries and need agents to discover and verify each other. Start with OASF and the Agent Directory, pilot SLIM where security demands it, and keep A2A and MCP for invocation and tools. A single agent inside one application does not need most of the stack yet.
Primary sources
- Building the Internet of Agents: Introducing AGNTCY.org — Outshift by Cisco
- Linux Foundation Welcomes the AGNTCY Project — The Linux Foundation
- AGNTCY Documentation — AGNTCY
- AGNTCY GitHub Organization — GitHub / AGNTCY
- A standard, open framework for building AI agents from Cisco, LangChain and Galileo — VentureBeat
- Cisco’s Outshift Incubator Sends Agentic AI Protocol To The Linux Foundation — The Next Platform
Last updated: May 31, 2026. Related: Agent Infrastructure.
