Enterprises are buying AI agents for different jobs, often from different vendors. One agent may review a supplier, another may work on a contract, and a third may assess the financial impact. Each can perform its own task. The business result depends on whether they can carry that work across systems and teams.
That is the AI agent interoperability problem. In an IDC InfoBrief sponsored by Leah, 73% of surveyed organizations said they plan to buy AI agent technologies from several vendors. Yet the report says only 29% of agents currently interact with each other. The two percentages measure different things, so they should not be subtracted. Together, they show why multivendor plans need an operating model for coordination.
What is AI agent interoperability?
AI agent interoperability is the ability of agents built in different systems to participate in the same business process. An interoperable agent can expose what it is allowed to do, receive the context needed for a task, return a usable result, and hand work to the next authorized participant. The process still needs rules for access, approvals, exceptions, and an audit trail.
Connecting an agent to an API is one part of this. The harder question is what happens after the connection works. Does the next agent know which customer, supplier, or contract the result concerns? Can it tell a draft from an approved decision? Does it know when to stop and ask a person? If the answers are unclear, the organization has connected tools without creating a dependable workflow.
Multivendor buying is already the plan
The IDC findings show that interoperability matters to buyers now, not just to architects planning a future platform. Alongside the 73% planning to buy from several vendors, 64% of surveyed organizations ranked integration and interoperability among their top vendor-selection criteria. A separate 64% rated cross-functional agent interoperability very important or absolutely critical. Only 8% said they plan to standardize on one vendor.
Those numbers point to a practical procurement question: How will this agent work with the agents, applications, and policies we already have? A feature demonstration inside one product cannot answer it. Buyers need to see the full handoff, including the context sent, the authority granted, and the result recorded.
This builds on a broader enterprise AI strategy: start with a valuable use case, then make its connections reusable across the business. Interoperability is what lets a successful use case become part of a larger system of work.
The handoff is where the business outcome lives
Consider an illustrative supplier agreement. A procurement agent identifies a supplier risk. A contracting agent needs that finding before it routes the agreement. A legal agent must review the relevant terms, while finance needs to understand the exposure before approval. Each agent may come from a different product.
The workflow succeeds only if the risk finding stays attached to the right agreement, each agent receives the information it is permitted to use, and the correct person approves the decision that requires judgment. If one step fails, the process needs a clear owner and a recoverable state. Those are business requirements, not just message-format requirements.
This is why the percentage of agents that interact is consequential. An agent can be useful in isolation while the organization still relies on people to move context between systems. The value of interoperability is that the process can advance without losing its meaning or its controls at every boundary.
Where A2A and MCP fit
Open protocols can reduce the need for a custom connection every time two systems meet. The Agent2Agent (A2A) specification focuses on communication between independent agents. It describes ways for agents to discover capabilities, exchange information, and manage collaborative tasks without sharing their internal implementation. The Model Context Protocol (MCP) focuses on how AI applications access tools and context resources. The A2A project's comparison of the two protocols treats them as complementary.
Protocol support is useful evidence of technical openness. It is not, by itself, proof that an enterprise workflow is interoperable. The organization still has to decide which agent may act on which data, what a completed task means, how approvals travel, and what happens when a vendor service is unavailable. The A2A specification provides for authentication and authorization, but the server's policy determines what an authenticated agent is actually allowed to do.
Four questions to ask before scaling AI agents
Can agents find the right capability?
Ask how an agent discovers an approved peer or tool, how capabilities are described, and how changes are versioned.
Does the handoff preserve business context?
Follow one real case across systems. Check identifiers, source data, status, and the meaning of the result the next agent receives.
Who controls action and approval?
Test what an agent can read or change, when a human must approve, and whether permissions follow the user and the task.
Can the organization explain the outcome?
Inspect the record of what each agent did, which input it used, where the process stopped, and who resolved an exception.
These questions work best in a live demonstration built around a cross-functional process. A supplier agreement, for example, makes it possible to observe the handoffs between procurement, legal, contracting, and finance. It also gives the team a measurable outcome, such as time spent waiting for review or the number of manual context transfers.
Build for the work that crosses boundaries
Enterprises do not need every agent to come from one vendor. They do need a way to coordinate work that crosses vendor and departmental boundaries without losing control of the process. The IDC results make the direction clear: multivendor buying is the expectation, while agent interaction is still limited.
Leah Maestro is Leah's approach to coordinating work across contracting, legal, procurement, and finance while connecting to existing enterprise tools. When assessing any platform for a multivendor environment, ask to see your specific external-agent and approval requirements demonstrated end to end.
Read the full IDC study for the research behind the interoperability findings and the broader picture of governance, orchestration, and cross-functional collaboration.
Frequently asked questions
What is the difference between AI agent integration and interoperability?
Integration connects an agent to a particular application, tool, or data source. Interoperability lets agents and systems use those connections to participate in a shared process, with enough context and control for the next participant to act correctly.
How is AI agent interoperability different from orchestration?
Interoperability makes communication and handoffs possible across agents and systems. Orchestration coordinates the order, state, and rules of the overall work. An enterprise process often needs both.
Do A2A and MCP solve enterprise interoperability on their own?
No. A2A provides a standard way for independent agents to communicate, while MCP provides a standard way for AI applications to use tools and context. Identity, permissions, business meaning, exception handling, and auditability still need to be designed and tested for the workflow.
Research note: Statistics in this article come from IDC's The Three Pillars of the Agentic Enterprise, InfoBrief #EUR154841426-IB, September 2026, sponsored by Leah. The InfoBrief describes an IDC survey of 410 enterprise decision-makers actively deploying or evaluating AI agents. Its figures identify the source as Leah's Agentic AI Adoption Study, April 2026 (n=410). The 73%, 64%, and 8% figures refer to surveyed organizations; the 29% finding refers to agents that interact with each other. IDC's research does not constitute an endorsement of Leah's products.
