For most of the software era, technology companies fought to own a destination. Microsoft wanted the operating system, Google wanted the search box, Salesforce wanted the customer record, and cloud providers wanted the infrastructure underneath everything. AI is shifting that competition because increasingly capable software is being asked to work across systems rather than remain inside one product.
An AI agent may understand a request perfectly and still fail because the contract sits in one database, customer history lives elsewhere, permissions are managed separately, and the final action has to happen in another application. The next important technology layer is therefore forming between products. Companies that make those handoffs reliable, secure and portable could gain as much influence as the companies building the applications themselves.
The System Is No Longer the Unit
Enterprise software used to be evaluated mainly as an individual product. Companies compared CRMs against other CRMs, analytics platforms against competing analytics tools, and productivity suites against rival suites. Integration mattered, but it often came after features, price and usability.
That assumption makes less sense in a modern software stack. Okta’s 2025 Businesses at Work research found that the average customer used 101 applications, up 9% year over year, while organizations with at least 2,000 employees averaged 247 applications.
At that scale, few important business processes stay inside one product. A customer renewal may involve account history in a CRM, unresolved issues in a support platform, usage data in analytics software, invoices in a finance system, contracts in cloud storage and recent conversations in email or meeting tools.
A human employee can compensate for this fragmentation by opening several tabs and comparing records. An automated agent needs the surrounding architecture to tell it which source is current, which data matters and what it is allowed to change.
The relevant unit of competition is therefore becoming the workflow, not the application. Products still matter, but their value increasingly depends on whether they can participate in work that begins elsewhere and continues after their part is finished.
Integration Debt Is Becoming Architecture
APIs made software more modular by allowing applications to expose data and functions without requiring people to operate every system manually. The limitation is that an API provides an interface, not a shared understanding.
One platform may identify a customer by email address, another by account number and another by company domain. A field called “status” can describe a sales stage in one system and a payment condition in another. Two applications can exchange valid data while interpreting that data differently.
Organizations traditionally solve this with integration code. Engineers map fields, transform data, manage authentication and create rules for known failures. Every custom connection, however, becomes another dependency that needs maintenance when APIs change, vendors redesign data models or security policies evolve.
This creates integration debt. A connection that was cheap to build can become expensive to maintain, and companies may eventually keep mediocre software because replacing it means rebuilding dozens of workflows around it.
AI increases the pressure because agents are expected to choose tools dynamically rather than follow one hard-coded path. They need structured ways to discover capabilities, understand restrictions and return results another system can interpret without developers manually defining every possible relationship.
A Handoff Has Four Parts
Interoperability is often reduced to one question: does this product integrate with that product? A better test is to examine what survives when responsibility moves across the boundary.
| What must survive | Why it matters | Typical failure |
| Data | The receiving system needs accurate records and enough context. | Information arrives incomplete, stale or attached to the wrong entity. |
| Meaning | Both systems must interpret the information consistently. | A shared field name represents different concepts in each application. |
| Authority | The receiver must know who initiated the request and what that identity can do. | An automated service receives broader permissions than the person it represents. |
| State | Multi-step work needs a reliable record of what already happened. | A failed action repeats, a partial action appears complete or systems disagree about progress. |
A workflow can fail even when the network request, authentication and API call all succeed. If an agent retrieves the correct customer but receives outdated billing information, the integration worked technically while the business decision may still be wrong.
The challenge becomes harder when agents delegate work. The receiving system may need the objective, constraints, evidence and limits on what it can change. Passing only the final instruction can remove the context required to act safely.
Interoperability therefore is not simply about moving more data. It is about preserving enough meaning and responsibility that another system can continue the work correctly.
AI Turns Errors Into Chains
Traditional automation normally follows a route designed in advance. A form submission creates a CRM record, an overdue invoice triggers a reminder, or a completed engineering task sends a notification. Because the sequence is predictable, developers can test each transition.
Agentic software creates more variable paths. Ask an AI system to prepare an account before a renewal call and it may decide to retrieve the contract, inspect previous meetings, check support cases, compare usage and flag unpaid invoices.
That flexibility changes the risk profile. Incorrect information from one source can influence a decision, which can then be written into another system and trigger additional processes. A small local error can become a chain of technically valid but commercially wrong actions.
IBM’s 2025 Cost of a Data Breach research found that 13% of studied organizations reported breaches involving AI models or applications. Among those organizations, 97% reported lacking proper AI access controls, while 60% of the incidents involved compromised data and 31% caused operational disruption.
Those figures do not argue against connecting AI with business systems. They show why connectivity without equally mature permission controls is incomplete engineering.
Protocols Move Into the Middle
The industry is beginning to standardize parts of this communication problem because custom integrations do not scale well enough for a world of agents, tools and fragmented enterprise data.
The Model Context Protocol, or MCP, provides a common mechanism for connecting AI applications with tools and data sources. Its July 2026 specification introduced a stateless protocol core, authorization improvements, routing capabilities and an extension framework. MCP maintainers reported close to half a billion monthly downloads across Tier 1 SDKs, while its TypeScript and Python SDKs had each exceeded one billion cumulative downloads.
Agent2Agent, or A2A, addresses another layer by defining how independent agents communicate and coordinate. The Linux Foundation reported in April 2026 that more than 150 organizations supported A2A, with production use appearing across financial services, insurance, supply chains and IT operations.
The distinction matters. MCP broadly helps AI applications interact with tools and data, while A2A focuses on agents exchanging capabilities, tasks and results. Together they show interoperability expanding in two directions: downward into existing software infrastructure and sideways between autonomous systems.
The larger shift is that communication itself is becoming standardized infrastructure. Once developers expect products to expose capabilities in familiar ways, compatibility starts influencing how easily a product can enter an existing workflow.
Broken Connections Carry an Operating Cost
Integration failures rarely appear under one neat cost category. Their impact is spread across engineering maintenance, manual reconciliation, delayed work and employees compensating for systems that only partially understand one another.
AI can make those weaknesses more expensive because automation increases the speed and number of handoffs. Three failure patterns deserve particular attention:
- Incomplete context can produce a technically correct but commercially wrong action. A renewal agent may retrieve an accurate contract and customer profile but miss an unresolved escalation stored in the support platform, leading it to generate an inappropriate offer from otherwise valid data.
- Conflicting records force automation to decide which version of reality deserves trust. If a CRM contains one billing contact and the finance platform contains another, the workflow needs an authority rule, freshness signal or reconciliation step rather than simply accepting whichever answer arrives first.
- Partial execution can leave several applications individually correct but collectively inconsistent. A workflow may reserve inventory successfully and then fail before updating payment or fulfillment, requiring clear rules for retries, reversals and human intervention.
Mature interoperability therefore needs recovery logic as much as connection logic. Systems must expose whether an action completed, whether repeating it is safe and what should happen when a later dependency fails.
Without those controls, companies risk automating the visible part of a workflow while creating a hidden layer of exception handling underneath it.
Where Records Cross Boundaries
The challenge becomes more demanding when information moves between independent organizations rather than applications controlled by one company. Healthcare, insurance, finance and legal work often rely on documents produced by several parties using different systems, access rules and retention processes.
The workflow surrounding a matter handled by Weinstein Law Group may involve information originating from clients and outside organizations before becoming useful within a broader legal process. The technology problem is not getting every participant onto one platform. It is enabling different systems to exchange what is necessary while preserving enough provenance, permissions and history for the recipient to understand where the information came from and how it should be used.
That requirement extends well beyond legal services. Effective interoperability should allow organizations to remain technically independent without forcing cross-company workflows to depend on manual copying, disconnected attachments or proprietary portals that isolate information from the systems where work happens.
Permission Becomes a Control Plane
As interoperability improves, authorization becomes more important because “can connect” and “should be allowed to act” are different questions.
A finance agent may need to read an invoice, compare it with a purchase order and prepare a payment. None of those tasks automatically means it should be allowed to release funds. A support agent may need account history without receiving permission to export an entire customer database.
Good interoperability therefore requires more granular controls:
- Access should match the specific task rather than the maximum capability of the connected system. Reading records, suggesting changes, executing actions and approving irreversible decisions should be treated as distinct levels of authority.
- The identity behind an action should remain visible as work moves between systems. An agent acting for an employee should ideally inherit that person’s relevant limits instead of operating through an unrestricted shared technical account.
- Cross-system actions need a reconstructable history. Administrators should be able to determine who initiated a request, which tools were used, what information influenced the decision and which system ultimately changed the record.
This makes auditability part of interoperability rather than a separate compliance feature. Once machines begin delegating work to other machines, the history of each handoff becomes part of the business record.
Lock-In Moves Above the Application
Open protocols can weaken traditional platform lock-in by making individual components easier to replace. If several products expose compatible capabilities, an organization has less reason to stay with one vendor simply because every workflow depends on its proprietary API.
Yet interoperability does not eliminate concentration. It may move it upward.
A company might easily switch between several AI models and business applications while depending heavily on one platform for agent identity, discovery, permissions, routing and workflow history. Individual components become portable, but the layer coordinating them becomes difficult to remove.
| Control point | Why it could become valuable |
| Identity | Determines which human, service or agent is recognized across systems. |
| Discovery | Determines how software finds available tools and agents. |
| Policy | Controls which actions are permitted and which require approval. |
| Orchestration | Decides where work goes and how multiple systems participate. |
| Observability | Holds the cross-system history needed for debugging and accountability. |
A company occupying one of these layers does not need to own every application underneath it. It only needs to become difficult to bypass.
This is why “open” and “neutral” should not be treated as synonyms. A protocol can be open while identity, orchestration or observability remains commercially concentrated around one provider.
Software Will Be Designed for Machines Too
Most business software has historically been designed around a person using an interface. APIs supported the product, but they rarely defined the product’s primary relationship with the wider technology ecosystem.
Agent-driven computing changes that assumption. Applications still need strong human interfaces, but they increasingly need machine-facing capabilities that other systems can understand without relying on brittle custom logic.
Several design changes follow:
- Capabilities need to be explicit enough for software to inspect safely. Another system should be able to understand what an action does, which inputs it requires, what permissions apply and what result or failure it can return.
- Products need clearer separation between observing, proposing and acting. An agent may be allowed to retrieve information freely, prepare a proposed change under tighter controls and execute high-impact actions only after additional authorization.
- Failure states need to be machine-readable. Another system must know whether an operation can safely be retried, whether part of it already completed and when human intervention is required.
Software is therefore beginning to serve two audiences at once: the person using the product directly and the machines operating around that person. Products that work brilliantly only through their own interface may become awkward participants in increasingly automated environments.
A Better Test for Interoperability
Integration quantity remains an easy marketing metric, but a page displaying thousands of logos reveals little about whether those connections can support meaningful work.
A stronger evaluation begins with the workflow. Buyers should identify where information originates, which system is authoritative, which actions create irreversible consequences and which identities need to remain visible as work moves.
Instead of asking whether an agent can “access the CRM,” teams should ask which records it can retrieve, whether its permissions mirror the person it represents, what happens when the CRM is unavailable and whether another model or orchestration platform could take over without rebuilding the workflow.
Interoperability is strongest when replacing one component is inconvenient rather than catastrophic. If removing one product destroys identity, routing, context and audit history at the same time, the architecture may be highly integrated without being genuinely portable.
As standards mature, the strongest systems will not simply connect with more products. They will reduce the amount of special knowledge required to make those products cooperate safely.
Verdict: The Battle Is Between the Products
The last generation of enterprise technology produced an enormous market for specialized applications. The next challenge is coordinating those applications without turning every connection into custom engineering, excessive permissions or another source of lock-in.
AI has accelerated the shift because a capable model becomes much more useful when it can retrieve current information and perform actions across a business. At the same time, an agent with poorly defined authority can propagate mistakes or security problems far faster than a traditional integration.
Protocols such as MCP and A2A matter because they signal where software architecture is moving. The industry is beginning to establish common mechanisms for discovering capabilities, connecting tools and exchanging work across independently built systems. The larger commercial opportunity will form around the identity, policy, orchestration, monitoring and recovery layers surrounding those connections.
The companies with the strongest position may therefore be neither those with the longest feature lists nor those with the largest integration directories. The more durable advantage could belong to systems that allow software from different vendors to cooperate without losing context, authority or accountability at every handoff.
For years, technology companies fought to become the place where work happened. The next battle is moving into the infrastructure that determines how work travels from one system to another, and whoever controls that layer could influence far more than the connection itself.
