Why agent interoperability is the problem that matters now
The multi-agent era has arrived, but it has arrived in fragments. A team building production AI systems today might run a Claude-managed agent for customer-facing tasks, a LangChain agent for internal knowledge retrieval, a CrewAI agent for orchestration, and a custom LlamaIndex pipeline for document processing. Each of those agents is, individually, a capable piece of software. The problem is that they cannot easily talk to one another.
There is no shared message format. There is no standard way for one agent to discover that another agent exists, let alone what it is capable of. There is no common authentication handshake to establish that the caller is who it claims to be. Each agent-to-agent integration today requires custom glue code — bespoke message serialisation, ad hoc HTTP endpoints, hand-rolled auth, and a brittle understanding between teams about what each side expects. That glue is expensive to build, expensive to maintain, and fragile when either agent is updated.
This is not a niche concern. As agentic systems mature from demos into production infrastructure, the surface area of agent-to-agent communication grows rapidly. An enterprise running dozens of specialised agents — one for contracts, one for compliance, one for code review, one for customer data — eventually needs those agents to coordinate. Without a shared protocol, every new integration is a new bespoke project. The engineering overhead compounds at exactly the moment when enterprises are trying to scale agentic deployments, not slow them down.
AGNTCY is an attempt to solve this at the protocol layer, rather than at the application layer. The founding coalition describes it as the most significant attempt yet at an industry-standard "agent protocol" — a claim that, given the names involved, deserves to be taken seriously.
What AGNTCY is and how it works
AGNTCY is an open-source agent interoperability standard, launched by a founding coalition of five organisations: Cisco, LangChain, LlamaIndex, Galileo, and Glean. The mix is notable: Cisco brings enterprise networking credibility and a hard-won understanding of interoperability standards; LangChain and LlamaIndex are the two most widely deployed agentic frameworks; Galileo brings evaluation and observability expertise; and Glean represents enterprise AI search and knowledge retrieval. No single vendor owns the spec. It is governed as a community standard.
At its core, AGNTCY defines three things. First, a message schema — a standardised format for the payloads exchanged between agents, covering request, response, and event types. Second, a discovery mechanism — a way for one agent to find and describe another, analogous to what DNS does for servers or what a service registry does in microservices architectures. Third, an authentication layer — a standard handshake that establishes the identity of a calling agent before a target agent processes its message.
The combination of these three elements means that an AGNTCY-compliant LangChain agent can, in principle, call an AGNTCY-compliant LlamaIndex agent without either side needing to know anything about the other's internal framework. The message arrives in a format the target understands; the target can be discovered via the standard registry mechanism; and the caller's identity has been verified before any computation begins.
The project is open-source and the specification is publicly available. Implementation libraries are being developed in parallel, targeting the major frameworks so that builders do not need to implement the raw spec from scratch. The founding sources for this launch are covered in detail by VentureBeat in their announcement piece on the Cisco, LangChain, and Galileo coalition.
AGNTCY is a nascent standard. The specification is still evolving, and the versioning conventions are not yet settled. Before building production dependencies on any specific protocol detail — message schema field names, discovery endpoint paths, auth token formats — check the current spec version and subscribe to the changelog. Building on a moving spec without version pins is a common source of silent breakage in distributed systems.
The comparison table below maps AGNTCY against the other interoperability approaches that builders currently use or encounter in the wild.
| Approach | Layer | Discovery | Auth standard | Cross-framework | Maturity |
|---|---|---|---|---|---|
| AGNTCY | Agent-to-agent protocol | Yes — built into spec | Yes — defined in spec | Yes — framework-agnostic | Nascent, coalition-backed |
| Model Context Protocol (MCP) | Model-to-tool protocol | No — per-server config | Per-server, ad hoc | Yes — model-agnostic | Stable, Anthropic-led |
| Custom REST/gRPC glue | Application layer, bespoke | Manual / service registry | Bespoke per integration | Yes, but fragile | Mature but unmaintainable at scale |
| LangGraph multi-agent | Orchestration within one framework | No — graph topology only | Shared runtime, no external auth | No — LangChain only | Stable, production use |
| CrewAI multi-agent | Orchestration within one framework | No — crew manifest only | Shared runtime, no external auth | No — CrewAI only | Stable, production use |
The key distinction: existing multi-agent frameworks handle coordination within a single framework's runtime. AGNTCY is designed to work across runtimes — the equivalent of defining how two microservices from different companies speak to each other, rather than how two functions within the same codebase call each other.
Ambient agents: the broader context
To understand why AGNTCY arrives now, it helps to understand where the agentic AI field is heading. The LangChain founder has articulated a concept called "ambient agents" — systems that do not wait for a user to issue a prompt, but instead run persistently in the background, monitoring event streams and acting autonomously when specific conditions are triggered.
An ambient agent might watch a company's ticketing system and route issues to the right specialist agent without human involvement. Another might monitor a codebase for security vulnerabilities and trigger a remediation agent when a CVE matches a dependency. A third might track a sales pipeline and fire off a context-enrichment agent whenever a deal reaches a certain stage.
These ambient systems are not hypothetical. Early versions are running in production at forward-leaning engineering organisations today. But they create an immediate problem: an ambient agent that monitors event streams and delegates to specialist agents is, by definition, calling agents it did not build. Without a common protocol, every ambient agent must ship with bespoke integration code for each downstream agent it might invoke. That makes ambient architectures brittle and expensive to extend.
AGNTCY is, in effect, the enabling protocol for ambient agent architectures. If every specialist agent publishes itself via the AGNTCY discovery mechanism and accepts AGNTCY-formatted messages, an ambient orchestrator can invoke any of them without needing prior knowledge of their internal implementation. This is the same architectural insight that made HTTP transformative for the web, and that made REST transformative for service-oriented architectures: a shared protocol removes the bilateral integration tax from every new connection.
Builders working on agentic retrieval systems will recognise similar themes in the research on hierarchical retrieval and agentic RAG architectures, where the challenge of routing queries between specialist retrieval agents maps directly onto the interoperability problem AGNTCY is solving.
The security problem that makes this urgent
The interoperability problem is not purely a developer-experience problem. It has a hard security dimension that is becoming impossible to ignore.
In a recent survey by VentureBeat, 88% of enterprises reported AI agent security incidents in the past 12 months. The incidents described range from prompt injection attacks that cause agents to act outside their intended scope, to unauthorised agent-to-agent calls that bypass access controls, to credential exfiltration via compromised agent pipelines. The common thread in many of these incidents is that the agent-to-agent communication layer was built as an afterthought, without formal identity verification or access controls.
When each agent integration is bespoke, security is also bespoke — and inconsistently applied. One team might implement proper API key rotation; another might hardcode credentials. One agent might validate the origin of incoming messages; another might trust any well-formed payload. The attack surface created by dozens of ad hoc agent-to-agent integrations is, in aggregate, enormous.
This is precisely where AGNTCY's authentication layer matters most. By defining a standard way to establish agent identity before messages are processed, AGNTCY creates a consistent security baseline across all agent interactions. A security team can audit one protocol rather than auditing fifty bespoke integrations. Access policies can be expressed in terms of agent identities rather than network addresses. Anomaly detection can operate on a single stream of AGNTCY-formatted traffic rather than trying to correlate signals across heterogeneous integration points.
The 88% figure is a wake-up call that the current approach — ad hoc integrations with ad hoc security — is not sustainable as agentic deployments scale. AGNTCY offers a structural response rather than a patchwork one.
Building multi-agent systems? Find your collaborators.
AI Tech Connect connects India and UK AI Builders working on agentic infrastructure. Browse profiles, shortlist up to 5, and we send you their contact details.
Browse Builders →How builders can adopt AGNTCY today
The specification and reference implementations are available in the AGNTCY open-source repositories. For builders ready to engage now, the recommended path is to start with the discovery and message schema specs before tackling the auth layer — getting agent discovery right is a prerequisite for everything else, and the auth specification has more moving parts that are likely to evolve as the coalition incorporates early implementor feedback.
Start with the AGNTCY discovery spec before worrying about auth. Publishing an agent's capability manifest to the discovery endpoint is a one-time, low-risk operation that immediately makes your agent findable to AGNTCY-compatible orchestrators. Auth can be layered on top once discovery is working — trying to implement both simultaneously raises the debugging surface when things do not behave as expected.
The agent registration flow works broadly as follows. Each agent publishes a capability manifest — a structured description of what the agent does, what inputs it accepts, what outputs it produces, and how to call it. The manifest is registered with an AGNTCY-compatible discovery endpoint. Other agents — including ambient orchestrators — can query that endpoint to find agents matching a capability profile, and then use the returned addressing information to send AGNTCY-formatted messages.
Below is an illustrative capability manifest in the AGNTCY JSON format. Note that exact field names and schema details are subject to change as the specification evolves — always refer to the versioned spec rather than copying this example verbatim into production code.
{
"agntcy_version": "0.1",
"agent_id": "urn:agntcy:acme:contract-review-agent:v1",
"display_name": "Contract Review Agent",
"description": "Reviews legal contracts for standard clause deviations and flags high-risk sections.",
"capabilities": [
{
"name": "review_contract",
"input_schema": {
"type": "object",
"properties": {
"document_url": { "type": "string", "format": "uri" },
"review_type": { "type": "string", "enum": ["nda", "saas", "employment"] }
},
"required": ["document_url", "review_type"]
},
"output_schema": {
"type": "object",
"properties": {
"risk_level": { "type": "string", "enum": ["low", "medium", "high"] },
"flagged_clauses": { "type": "array", "items": { "type": "string" } },
"summary": { "type": "string" }
}
}
}
],
"auth": {
"type": "bearer",
"token_endpoint": "https://agents.acme.example/token"
},
"endpoint": "https://agents.acme.example/contract-review/agntcy"
}
/* Illustrative — exact schema subject to change in spec v0.x releases */
Once an agent is registered, any AGNTCY-compatible orchestrator can discover it by querying for agents with the review_contract capability, receive the addressing information, obtain a token from the token endpoint, and send a well-formed message to the agent's endpoint. No bespoke integration code required on either side — only conformance to the shared spec.
For teams building on LangChain or LlamaIndex, watch the respective framework repositories for AGNTCY compatibility modules. Given that both frameworks are founding members of the coalition, native AGNTCY support is expected to land in their standard releases rather than requiring manual integration work.
What this means for the Indian and UK agent ecosystem
India's enterprise AI market is one of the most aggressive multi-framework adopters globally. Large engineering organisations in Bengaluru, Hyderabad, and the NCR regularly run heterogeneous agentic stacks — LangChain for orchestration, custom LlamaIndex pipelines for retrieval, and increasingly framework-specific agents from vendors integrated into enterprise software like Salesforce, ServiceNow, and SAP. The bilateral integration tax compounds quickly at this scale. Indian platform engineering teams will immediately recognise the value of a standard that eliminates the bespoke glue layer.
The sovereign AI and regulated-sector context is equally relevant. India's DPDP Act and the rapid growth of AI-native fintech and healthtech in the subcontinent mean that agent-to-agent authentication is not merely a convenience — it is a compliance requirement. AGNTCY's auth layer, when mature, could become a component of how Indian enterprises demonstrate that their AI pipelines have proper identity controls in audit contexts.
In the UK, the picture is shaped by the financial services sector's particular needs. City of London firms and UK fintech scale-ups running AI agents for compliance, trading, and customer operations face similar heterogeneity challenges, but with a harder regulatory overlay. The FCA's emerging expectations around model governance and auditability create a direct appetite for standardised, auditable agent communication logs — exactly the kind of observability that a standard protocol enables at scale. UK deep-tech teams building agent infrastructure should treat AGNTCY as an early standard to contribute to, not merely consume from: the coalition is open, and UK builder perspectives on financial-sector requirements would be a genuine contribution.
For builders in both markets, AGNTCY represents the kind of foundational bet that rewards early engagement. The spec is early; the community is thin; the feedback loops are short. Teams that engage now and contribute to the reference implementations will have an asymmetric advantage when enterprise procurement conversations start asking "is your agent AGNTCY-compatible?" in twelve to eighteen months.