# Agent interoperability: a complete explainer **Tagline:** News & Media | **Authors:** Jeff Mills | **Categories:** Tech DE | **Published:** 2026-07-14 | **Updated:** 2026-07-16 You built a research AI agent in the [LangGraph framework](https://redis.io/blog/ai-agent-orchestration-platforms/). Another team shipped a customer-service agent in CrewAI. A third team wired up tools through the OpenAI Agents SDK. Now leadership asks: can these things work together? For most teams, the honest answer is "sort of, with a lot of glue code." Agent interoperability lets agents built on different frameworks discover each other, delegate work, and share context—without custom glue code holding it all together. It matters because multi-agent systems are going mainstream, and fragmented state slows everything down. [70% of AI apps](https://www.gartner.com/en/newsroom/press-releases/2025-06-11-gartner-predicts-that-guardian-agents-will-capture-10-15-percent-of-the-agentic-ai-market-by-2030) are projected to use multi-agent systems by 2028, and [task-specific agents](https://www.gartner.com/en/newsroom/press-releases/2025-08-26-gartner-predicts-40-percent-of-enterprise-apps-will-feature-task-specific-ai-agents-by-2026-up-from-less-than-5-percent-in-2025) are already showing up across enterprise apps this year. Agents that can't cooperate across frameworks hit a scaling ceiling fast. This guide covers what agent interoperability actually means, how the major protocols split tool access from agent coordination, and why shared state stays your problem after you adopt them. ## **What agent interoperability means & what breaks without it** Agent interoperability is what cuts down that glue code. It's the ability of agents built on different frameworks to find each other, share context, and hand off work across vendor and framework lines. Rather than making every framework behave the same way, the goal is to give agents a common way to describe what they do and pass work between them. In practice, that means your LangGraph agent can find your CrewAI agent, see what it does, hand it a task, and get a usable result back, without a custom integration written just for that pair. Without it, a few failure modes show up again and again: - **Integration sprawl.** Wiring N agents to M tools with custom code leaves you maintaining N×M integrations. Add one new tool and every app that touches it needs an update. - **Duplicated work.** Teams rebuild the same capabilities in isolation because agents can't reuse what other agents already do. - **Brittle wiring.** Point-to-point integrations don't scale, and each one carries its own auth, error handling, and data transformation quirks. - **Fragmented context.** Information gets split across agents, so no single agent has the full picture, and decisions drift out of sync. These aren't hypothetical concerns. The lack of interoperability across agent protocols echoes the early internet, before shared standards like HTTP replaced custom point-to-point integrations. The stakes are real: [over 40%](https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027) of agentic AI projects are projected to be canceled by the end of 2027, often due to rising costs and unclear business value. Integration sprawl feeds both. The protocol layer is consolidating fast, and that starts with separating tool access from agent-to-agent coordination. ## **The protocol layer: MCP, A2A & ACP at a glance** Those failure modes pushed the industry toward two standards that split the problem cleanly: the Model Context Protocol (MCP) for how agents reach tools and data, and the Agent2Agent (A2A) Protocol for how agents talk to each other. ### **MCP: the agent-to-tool layer** MCP is an [open-source standard](https://modelcontextprotocol.io/introduction) for connecting AI apps to external systems like data sources, tools, and workflows. Think of it as a shared plug for AI apps. Instead of writing five custom integrations for five tools, you connect to five MCP servers through one consistent interface. MCP has moved fast since Anthropic introduced it in November 2024. It reached a reported [100 million monthly downloads](https://www.anthropic.com/news/introducing-anthropic-labs), and in December 2025 Anthropic donated the protocol to the [Agentic AI Foundation](https://www.anthropic.com/news/donating-the-model-context-protocol-and-establishing-of-the-agentic-ai-foundation), a directed fund under the Linux Foundation co-founded by Anthropic, Block, and OpenAI, with support from Google, Microsoft, AWS, Cloudflare, and Bloomberg. ### **A2A: the agent-to-agent layer** A2A handles the layer above tools. It gives agents a standard way to find each other, share information securely, and coordinate on tasks across frameworks. The idea is simple: each agent publishes a short profile describing what it does, and every request between agents is wrapped in a task with a clear status (submitted, working, completed, or failed), so both sides always know where things stand. A2A now lives under the Linux Foundation too. By April 2026, [more than 150 organizations](https://www.linuxfoundation.org/press/a2a-protocol-surpasses-150-organizations-lands-in-major-cloud-platforms-and-sees-enterprise-production-use-in-first-year) backed A2A, with integration across major cloud platforms. ### **ACP: merged into A2A** If you've seen the Agent Communication Protocol (ACP) in older architecture discussions, you can simplify your mental model. IBM Research launched ACP in March 2025 to power its BeeAI Platform, and in August 2025 ACP [joined forces](https://lfaidata.foundation/communityblog/2025/08/29/acp-joins-forces-with-a2a-under-the-linux-foundations-lf-ai-data) with A2A under the Linux Foundation, with migration paths for existing ACP users. Treat ACP as historical. For new architecture planning, focus on MCP for agent-to-tool and A2A for agent-to-agent. So adopt both and interoperability is covered, right? Not quite. ## **What protocols don't solve: shared state** Here's what surprises teams after their first multi-framework deployment: MCP and A2A standardize how agents talk, but neither one manages state. The MCP architecture docs are clear that the protocol does not dictate how apps use LLMs or manage context. A2A works the same way: it coordinates work across frameworks, but shared memory sits outside its scope. In LangGraph, short-term memory stays inside a single thread, so sharing context across threads takes extra work. In parallel workflows, sub-agents run on their own, and any data sharing between them has to be built explicitly. Give every agent its own private store and each one becomes a small stateful service to run, back up, and keep in sync. When state stays fragmented, you get failures protocols can't prevent. One agent can undo another agent's intentional change because both are working from stale views of the same data. That's a classic lost update, the same problem distributed databases have handled since the 1970s. Context problems compound in the same way. If one agent picks up bad or outdated information, that context gets passed to the next agent, and the next, until decisions are being made on a story that doesn't match reality. The protocols moved this problem; they didn't remove it. A shared-state layer is what keeps agent context coherent across frameworks, tools, and long-running tasks. ## **The shared-state pattern underneath interoperable agents** Since neither MCP nor A2A manages shared state, teams building multi-framework systems usually land on the same answer: an external state layer that any agent can read from and write to, no matter which framework it runs on. For work that spans multiple interactions or long-running tasks, that state lives outside the agent instead of in memory. Several patterns dominate: - **Blackboard architecture.** Agents don't talk to each other directly. They read from and write to a [shared data region](https://arxiv.org/html/2510.01285v1), and each one decides on its own what to pick up and contribute. - **Layered memory.** Shared memory gets split into layers: a record of past events, a semantic layer of learned patterns, and a current-state layer for what's true right now. - **Checkpoints.** Each agent's session gets persisted so work can resume after a crash or restart. - **Pub/sub messaging.** Publish/subscribe (pub/sub) messaging lets agents react to events as they happen instead of polling each other. Whatever the pattern, production shared-state layers tend to need the same things: safe concurrent writes when multiple agents update at once, real indexing instead of brute-force scans, and audit trails for who touched what. Many also benefit from hybrid search that combines keyword and vector similarity, plus filters for operational data. That's a demanding list for something agents hit constantly, which is where the data layer choice starts to matter. ## **What Redis provides across multi-framework agent systems** Shared state sits in the hot path of every agent turn, so speed matters. Redis is a real-time data platform with a memory-first architecture, and it supports [vector search](https://university.redis.io/course/1npvvtfft2agew), semantic caching, and pub/sub alongside the operational data your apps already use—the exact mix a shared-state layer needs. Because Redis sits outside any single framework, it becomes the layer frameworks share instead of another silo. The native integrations cover the main entry points: - **LangGraph.** The [Redis checkpoint integration](https://redis.io/blog/langgraph-redis-build-smarter-ai-agents-with-memory-persistence) handles thread-level persistence and cross-thread memory. - **AutoGen, Cognee & A2A.** The [Fall 2025 release](https://redis.io/blog/fall-release-2025) added native support for all three frameworks. - **MCP.** The [official Redis MCP Server](https://github.com/redis/mcp-redis) exposes read, write, and query operations to any MCP-compatible client. These are the primitives. If you'd rather not wire them together yourself, Redis Iris bundles them into a managed context engine. It sits between an agent and the data it needs to act, and it bundles four capabilities: - **Redis Data Integration.** Keeps Redis in sync with your existing databases so agents always work from current data. - **Redis Context Retriever.** Governed, schema-first access to your business data, so agents work through defined tools instead of raw database queries. - **Redis Agent Memory.** Persistent short-term and long-term memory so agents remember past interactions and preferences across sessions. - **Redis LangCache.** Semantic caching that returns cached responses for similar queries in milliseconds instead of triggering a fresh LLM call. Redis Search handles vector, full-text, and structured search underneath. Iris runs across agent frameworks and is available as a managed service on Redis Cloud. The cost impact is real: in high-repetition workloads, semantic caching with Redis LangCache measured [up to 73% lower](https://redis.io/blog/llm-token-optimization-speed-up-apps/) LLM inference costs in Redis benchmarks, since repeated intents get served from cache instead of the model. Results depend on query patterns and cache hit rates. ## **Redis: the shared-state layer that makes agents interoperable** Protocols only get you halfway. MCP handles how agents reach tools and data, A2A handles how agents find and delegate to each other, and both now sit under neutral Linux Foundation governance, which makes them stronger candidates for multi-framework standardization. But neither protocol gives you a shared state layer. Without one, agents built on different frameworks still work from stale, fragmented, or conflicting views of the world, and context problems compound at every hop. The teams getting this right treat shared state as infrastructure: an external, fast, framework-neutral layer that any agent can read from and write to. Redis fits that role because it combines memory, vector search, semantic caching, and pub/sub coordination in one platform instead of spreading agent context across separate systems, and it plugs into the frameworks and protocols you're already using. If you're building agents on more than one framework, [try Redis Iris](https://redis.io/try-free/?rcplan=iris) and see how a shared context layer changes what your agents can do together, or [talk to our team](https://redis.io/meeting/) about designing the state layer for your multi-agent architecture.