Latest / The Practical AI Digest / The Agent Interoperability Problem: Why Your AI Agents Can Not Talk to Each Other

Transcript

The Agent Interoperability Problem: Why Your AI Agents Can Not Talk to Each Other · The Practical AI Digest

• 0:00
  Here is the question that exposes the biggest gap between
• 0:03
  what the AI industry is selling and what it can actually
• 0:07
  deliver. You have an AI agent that
• 0:09
  handles your customer support tickets.
• 0:12
  You have another one that manages your inventory, and you
• 0:15
  have a third one that does financial forecasting.
• 0:19
  All three are supposedly intelligent.
• 0:21
  All three can reason, plan, and take actions.
• 0:24
  But can they talk to each other? Can the support agent tell the
• 0:28
  inventory agent that a product is getting a surge of
• 0:31
  complaints, so maybe do not reorder 10,000 more units?
• 0:36
  Can the forecasting agent ask the support agent how many
• 0:39
  refund requests came in last quarter?
• 0:42
  The answer for the vast majority of production deployments in
• 0:46
  2026 is no, they cannot. And the reason is not that the
• 0:51
  models are not smart enough, it is that we never built the phone
• 0:55
  lines. IMO, and this is the practical
• 0:59
  AI Digest. Today we are talking about the
• 1:02
  agent interoperability problem, why your AI agents cannot talk
• 1:07
  to each other, and the three protocols that are trying to fix
• 1:10
  it before the whole thing collapses under its own weight.
• 1:14
  Let me frame the scale of this problem with a number from
• 1:17
  Composio 2026 AI Agent Report. 90% of enterprises now have AI
• 1:25
  agents deployed in production, but only 23% have successfully
• 1:30
  scaled them beyond a single use case.
• 1:33
  That gap, 67 percentage points of companies stuck at one agent
• 1:37
  doing one thing, is almost entirely an interoperability
• 1:41
  problem. The agent works.
• 1:44
  The agent works great, but it is an island, and islands do not
• 1:50
  compound. This is not a new problem in
• 1:52
  computing. We solved it for applications
• 1:55
  decades ago with APIs. We solved it for microservices
• 1:59
  with REST and GRPC. We solved it for web browsers
• 2:03
  with HTTP. Every time a new computing
• 2:06
  paradigm emerges, the first generation is a bunch of
• 2:09
  isolated systems that cannot communicate, and then someone
• 2:13
  builds the connective tissue and the entire ecosystem explodes in
• 2:17
  capability. We are in that preconnective
• 2:20
  tissue moment for AI agents right now.
• 2:24
  The challenge with agents is that they are fundamentally
• 2:27
  different from traditional software in ways that make the
• 2:30
  old integration patterns insufficient.
• 2:33
  An API call is deterministic. You send a request, you get a
• 2:37
  response, you know the schema. And agent interaction is not
• 2:40
  like that. The agent might need to
• 2:43
  negotiate, it might need to ask clarifying questions, it might
• 2:47
  need to stream partial results over minutes or hours as it
• 2:50
  works through a complex task. It might fail part way through
• 2:54
  and need to hand off gracefully. The interaction pattern is
• 2:58
  closer to how 2 humans collaborate on a project than
• 3:01
  how 2 services exchange data, and we do not have good
• 3:05
  protocols for that. What we do have as of mid 2026
• 3:10
  are three protocols that each tackle a different piece of this
• 3:13
  puzzle and understanding how they fit together is the key to
• 3:18
  understanding where agent infrastructure is heading.
• 3:22
  The 1st is MCP, the model context protocol created by
• 3:27
  Anthropic and now governed by the Linux Foundation.
• 3:31
  MCP is the one you have probably heard of.
• 3:34
  It has 97,000,000 monthly SDK downloads as of early 2026.
• 3:40
  It is integrated into every major AI provider tool chain.
• 3:44
  It is, for all practical purposes, the standard for how
• 3:47
  an agent connects to tools and data sources.
• 3:51
  Think of MCP as the power strip for AI agents.
• 3:54
  Your agent needs to read a file from Google Drive.
• 3:58
  There is an MCP server for that. It needs to query a database MCP
• 4:04
  server, send a Slack message MCP server.
• 4:08
  The protocol defines a clean client server interface, where
• 4:11
  the agent is the client and the tool is the server.
• 4:15
  The agent discovers what capabilities the server offers,
• 4:18
  sends structured requests, and gets structured responses back.
• 4:22
  It is simple, it is elegant, and it works.
• 4:26
  But here's the critical thing about MCP that most coverage
• 4:29
  gets wrong. MCP is vertical integration.
• 4:34
  It connects an agent downward to its tools.
• 4:37
  It does not connect an agent sideways to other agents.
• 4:41
  Your customer support agent can use MCP to read from your
• 4:44
  ticketing system, but it cannot use MCP to ask your inventory
• 4:48
  agent a question. MCP gives agents hands, it does
• 4:53
  not give them the ability to coordinate.
• 4:55
  This is where the second protocol comes in.
• 4:59
  A to a Agent to Agent was created by Google and donated to
• 5:03
  the Linux Foundation in June 2025.
• 5:06
  It launched with over 50 partners, including AWS,
• 5:10
  Microsoft, Salesforce, and SAP. A 2A is specifically designed
• 5:14
  for horizontal coordination, agent to agent, peer-to-peer.
• 5:20
  The design of a 2A reflects a deep understanding of how agent
• 5:24
  interactions actually work in practice.
• 5:27
  It introduces a concept called an agent card, which is
• 5:32
  essentially a machine readable resume that an agent publishes
• 5:36
  to describe what it can do, what inputs it needs, and what
• 5:40
  outputs it produces. When one agent wants to
• 5:43
  collaborate with another, it first reads the agent card to
• 5:47
  understand the other agent capabilities.
• 5:50
  This is analogous to how you might check a colleague on
• 5:53
  LinkedIn before reaching out with the request.
• 5:56
  You want to know if they are the right person before you start a
• 6:00
  conversation. Then A to a provides a task life
• 6:04
  cycle protocol. One agent can create a task for
• 6:07
  another agent, check on its progress, receive partial
• 6:11
  updates, and get the final result.
• 6:14
  The interaction is asynchronous by default, which is the right
• 6:17
  call because real agent work takes time.
• 6:22
  You do not want your customer support agent frozen waiting
• 6:25
  synchronously for the inventory agent to finish a full stock
• 6:29
  analysis. You want it to fire off the
• 6:31
  request, keep handling tickets, and get notified when the result
• 6:35
  is ready. A to A also handles something
• 6:39
  that most protocol designers get wrong on the first try, which is
• 6:42
  failure and hand off. If an agent cannot complete a
• 6:46
  task. A to A defines explicit error
• 6:49
  States and hand off mechanisms. The failing agent can say, I
• 6:53
  cannot do this, here's the partial work I completed, and
• 6:57
  here's a suggestion for who might be able to finish it.
• 7:00
  This is crucial in production environments where reliability
• 7:03
  matters more than peak performance.
• 7:06
  A system that fails gracefully is infinitely more valuable than
• 7:11
  one that fails silently. The third protocol is ACP, the
• 7:16
  aging communication protocol originally created by IBM.
• 7:20
  ACP took a different philosophical approach than A to
• 7:24
  a, where A to a builds a full life cycle framework with
• 7:27
  discovery, task management, and streaming.
• 7:30
  ACP was deliberately minimalist. It used standard REST
• 7:34
  conventions, standard Http://methods, standard Jason
• 7:38
  payloads. The argument was that
• 7:41
  enterprises already have massive investment in REST
• 7:45
  infrastructure. Load balancers, API gateways,
• 7:49
  monitoring tools, and making agents communicate over plane.
• 7:54
  REST would be the fastest path to adoption.
• 7:57
  This is a legitimate engineering argument.
• 8:01
  Every enterprise has people who know REST.
• 8:04
  Not every enterprise has people who understand custom binary
• 8:07
  protocols or GRPC streaming. If you can make agent
• 8:12
  communication look like a regular API call, you remove a
• 8:15
  huge barrier to adoption. But here is the interesting
• 8:19
  part. In September 2025, IBM announced
• 8:23
  that ACP would officially merge with a 2A under the Linux
• 8:27
  Foundation. Kate Blair, IBM director of
• 8:32
  Incubation, who had been overseeing ACP, joined the a 2A
• 8:36
  technical steering committee. The reasoning was
• 8:39
  straightforward. Maintaining 2 agent, 2 agent
• 8:42
  standards creates unnecessary fragmentation.
• 8:45
  The industry needs one horizontal protocol, not two,
• 8:49
  and A to a had more momentum. This merger is significant
• 8:53
  because it signals that the industry is converging faster
• 8:57
  than most people expected. We are not heading toward a
• 9:00
  fragmented landscape of competing agent protocols.
• 9:04
  We are heading toward a two layer stack MCP for vertical
• 9:08
  agent to tool, A to A for horizontal agent to agent.
• 9:12
  That is it. 2 protocols that complement each other, not
• 9:16
  compete. There is also 4th protocol worth
• 9:19
  mentioning even though it is earlier in its life cycle.
• 9:23
  A&P, the Agent Network Protocol, is a community driven effort
• 9:28
  focused on open discovery of agents across the public
• 9:31
  Internet. Think of it as DNS for agents,
• 9:35
  where A to A assumes you already know which agent you want to
• 9:39
  talk to. A&P tries to solve the discovery
• 9:42
  problem. How does your procurement agent
• 9:45
  find a compliance agent in the 1st place?
• 9:48
  A&P proposes A decentralized registry where agents publish
• 9:52
  their capabilities and other agents can search for them.
• 9:56
  It is ambitious, it is early, and it faces all the trust
• 9:59
  problems of any open registry, but it is solving a real gap
• 10:04
  that neither MCP nor a 2A currently address.
• 10:07
  The analogy that clarifies how all of these fit together is the
• 10:11
  one from the Xylo's research team.
• 10:14
  MCP is the power strip, you plug your tools into it.
• 10:19
  A 2A is the phone line, you call your colleagues through it.
• 10:23
  ACP before the merger was the desk where work gets done and
• 10:28
  A&P is the directory you look up who to call.
• 10:32
  No single protocol does everything and that is by
• 10:34
  design. The industry tried the
• 10:37
  monolithic approach with enterprise service buses in the
• 10:40
  2000s and it did not work. A layered stack where each
• 10:44
  protocol handles one concern well is more robust than a
• 10:48
  single protocol that handles everything poorly.
• 10:50
  Google Agent Development Kit already implements both MCP and
• 10:55
  a 2A Salesforce. Agentforce implements both.
• 10:59
  ServiceNow now Assist implements both.
• 11:02
  The reference architecture is solidifying in real time.
• 11:06
  Let me put some dollar figures on why this matters because the
• 11:09
  cost of not solving interoperability is staggering.
• 11:14
  Composio found that the average enterprise spent $500,000 on a
• 11:18
  failed multi agent pilot in 2025.
• 11:23
  Not on the models, not on the inference compute on custom
• 11:27
  integration work. 5 senior engineers spending three months
• 11:31
  building bespoke connectors between agents that were never
• 11:34
  designed to talk to each other. That is half $1,000,000 on
• 11:38
  plumbing, and when the pilot gets shelved, that plumbing gets
• 11:41
  thrown away. Multiply that across the 63% of
• 11:46
  executives who report platform sprawl as a growing concern, and
• 11:50
  you start to see the scale of the waste.
• 11:53
  The economic argument for standardized protocols is not
• 11:57
  that they make cool demos possible.
• 11:59
  It is that they eliminate a category of engineering work
• 12:04
  that currently consumes months of senior engineering time per
• 12:08
  integration. If your agents speak MCP and a
• 12:12
  2A natively, the custom connector work drops to near 0.
• 12:17
  The integration becomes configuration, not development.
• 12:21
  So if the protocols exist and major players are adopting them,
• 12:26
  why is interoperability still a problem?
• 12:29
  Because protocols are necessary but not sufficient.
• 12:33
  Having HTTP did not automatically make every website
• 12:36
  work together. Having REST did not
• 12:39
  automatically make every API compatible.
• 12:43
  The protocol is the syntax, the semantics, what the data
• 12:47
  actually means, how capabilities map to business processes, how
• 12:52
  errors propagate across organizational boundaries.
• 12:55
  Those are the hard problems that protocols cannot solve by
• 12:58
  themselves. Let me give you a concrete
• 13:01
  example. Say you have a procurement agent
• 13:04
  built on Salesforce and a compliance agent built on
• 13:08
  ServiceNow. Both support A to a.
• 13:11
  In theory, the procurement agent should be able to ask the
• 13:15
  compliance agent to review a vendor before signing a purchase
• 13:18
  order. But what does review a vendor
• 13:21
  actually mean? The procurement agent thinks it
• 13:24
  means checking if the vendor is on an approved list.
• 13:28
  The compliance agent thinks it means running a full risk
• 13:31
  assessment including financial stability, cybersecurity
• 13:34
  posture, and regulatory history. The A to A task gets created.
• 13:40
  The compliance agent does its thing and comes back with a 30
• 13:44
  page risk report when the procurement agent just wanted a
• 13:47
  yes or no. This is the semantic gap, and it
• 13:51
  is the same gap that has plagued enterprise software integration
• 13:54
  for decades. EDI, Soapy, REST, RAFQL.
• 14:00
  Every generation of integration technology solves the transport
• 14:04
  problem and then discovers that the real problem was always
• 14:07
  about shared meaning. The agent world has an
• 14:12
  additional complication that traditional software integration
• 14:15
  did not face. Agents are non deterministic.
• 14:19
  The same agent given the same input twice might produce
• 14:23
  different outputs. It might take different
• 14:25
  approaches. It might ask different
• 14:27
  clarifying questions. This makes testing, debugging
• 14:31
  and monitoring agent to agent interactions significantly
• 14:35
  harder than testing traditional API integrations.
• 14:39
  You cannot just replay a successful interaction and
• 14:42
  expect the same result. You need to test for behavioral
• 14:46
  envelopes, ranges of acceptable outcomes rather than exact
• 14:50
  expected outputs. There is also the trust problem,
• 14:54
  which the protocols are only beginning to address.
• 14:57
  When 2 APIs communicate within the same organization, trust is
• 15:02
  implicit. You control both endpoints.
• 15:05
  When 2 agents communicate across organizational boundaries, trust
• 15:09
  is earned, not given. How do you verify that the agent
• 15:13
  claiming to be your supplier inventory system is actually
• 15:17
  authorized to share stock levels?
• 15:19
  How do you prevent one agent from manipulating another
• 15:22
  through carefully crafted prompts?
• 15:24
  Essentially, an agent to agent prompt injection A to A has
• 15:29
  authentication and authorization mechanisms, but the attack
• 15:33
  surface of agent to agent communication is fundamentally
• 15:37
  larger than traditional API communication because the agents
• 15:41
  can interpret and act on natural language, not just structured
• 15:45
  data. The NIST AI Agent Standards
• 15:48
  Initiative, launched in 2026, is trying to establish governance
• 15:53
  frameworks for exactly these scenarios.
• 15:56
  Their focus areas include agent identity verification,
• 16:01
  capability attestation, audit trails for multi agent
• 16:05
  decisions, and liability frameworks for when a chain of
• 16:09
  agents produces A harmful outcome.
• 16:12
  These are governance problems, not protocol problems, but they
• 16:16
  will determine whether multi agent systems ever achieve
• 16:20
  mainstream enterprise adoption. Let me bring this back to the
• 16:24
  practitioner level. If you are building or deploying
• 16:28
  AI agents today, here's what the interoperability landscape means
• 16:32
  for your architecture decisions. First, adopt MCP now.
• 16:37
  It is the clear foundation layer.
• 16:40
  It has critical mass universal tool support and a stable
• 16:44
  specification. If your agents are not using MCP
• 16:48
  for tool integration, you're building custom connectors that
• 16:52
  you'll have to throw away. Second, design for A to a.
• 16:56
  Even if you are not implementing it yet, Structure your agents
• 17:00
  with clear capability descriptions, well defined input
• 17:04
  and output schemas, and explicit error handling.
• 17:07
  When you do add A to a, these architectural patterns translate
• 17:12
  directly into agent cards and task definitions.
• 17:16
  If your agent is a monolith that takes unstructured text and
• 17:19
  returns unstructured text, it will be very difficult to make
• 17:22
  it interoperable later. Third, treat the semantic gap as
• 17:26
  a product problem, not a technical one.
• 17:30
  The hardest part of making two agents work together is agreeing
• 17:33
  on what the words mean. Define your domain vocabulary.
• 17:37
  Explicitly document what review a vendor means in your context.
• 17:43
  Build shared ontologies for common business concepts.
• 17:47
  This is the work that no protocol can do for you, and it
• 17:50
  is the work that will determine whether your multi agent system
• 17:54
  actually delivers value or just passes messages back and forth.
• 17:58
  4th plan for the trust boundary. Every agent to agent interaction
• 18:04
  crosses a trust boundary, even if both agents are within your
• 18:08
  organization. Build in verification, build in
• 18:11
  audit trails, Build in the ability to explain why a chain
• 18:15
  of agents made a particular decision.
• 18:18
  Because when something goes wrong in a multi agent system,
• 18:22
  and it will, the first question will be which agent made the
• 18:25
  wrong call and the second question will be why did the
• 18:29
  other agents trust it. And 5th watch your
• 18:33
  observability. In a traditional microservices
• 18:37
  architecture you have distributed tracing.
• 18:40
  You can follow a request from the API Gateway through 10
• 18:43
  services and back. Multi agent systems need the
• 18:47
  equivalent, but for reasoning chains.
• 18:50
  When agent A asks agent B, which asks agent C, which makes the
• 18:55
  decision that agent A acts on, you need to be able to
• 18:58
  reconstruct that entire reasoning chain after the fact.
• 19:02
  Not just the messages that were passed, but the reasoning each
• 19:05
  agent applied to produce its output.
• 19:08
  This is harder than distributed tracing because the reasoning is
• 19:12
  non deterministic. 2 identical replays will produce different
• 19:17
  traces. The tooling for this barely
• 19:19
  exists today, but it will be table stakes within a year.
• 19:23
  There is one more dimension of the interoperability problem
• 19:28
  that deserves attention, and that is the organizational
• 19:32
  dimension. Protocols solve the technical
• 19:35
  problem of how agents communicate.
• 19:38
  They do not solve the organizational problem of who
• 19:42
  owns the agent, who is liable for its outputs, and who pays
• 19:46
  when it breaks. In an enterprise with a customer
• 19:49
  service agent owned by the support team and a billing agent
• 19:53
  owned by the finance team, who is responsible when the two
• 19:57
  agents collaborate to issue a refund that violates company
• 20:00
  policy? The support team says the
• 20:04
  billing agent approved it. The finance team says the
• 20:07
  support agent initiated it. Both are right, neither feels
• 20:12
  accountable. This is the multi agent
• 20:15
  governance problem and it mirrors the challenges that
• 20:18
  organizations faced when they first adopted microservices.
• 20:23
  Ownership boundaries, Slas between internal teams.
• 20:27
  Incident response for cross team failures.
• 20:31
  The companies that solve microservices governance did it
• 20:35
  by establishing clear service ownership, explicit Slas, and
• 20:39
  shared on call rotations. Multi agent systems will need
• 20:44
  the same organizational infrastructure adapted for the
• 20:48
  fact that agents make judgment calls, not just deterministic
• 20:52
  computations. The agent interoperability
• 20:56
  problem is real, it is urgent, and it is solvable.
• 21:01
  The protocols are here. The governance frameworks are
• 21:05
  coming. The missing piece is the
• 21:08
  unglamorous integration work that turns a protocol
• 21:11
  specification into a working system.
• 21:15
  This is not the kind of work that makes headlines or gets
• 21:18
  published at conferences, but it is the work that will determine
• 21:22
  whether the 90% of enterprises that have deployed agents can
• 21:26
  join the 23% that have actually scaled them.
• 21:30
  The AI industry spent 2024 and 2025 proving that individual
• 21:35
  agents can be remarkably capable.
• 21:38
  The challenge for 2026 and beyond is proving that they can
• 21:42
  be remarkably capable together. I am MO Bouillon.
• 21:47
  This has been the Practical AI Digest.
• 21:50
  See you in two weeks.