The New Logic of Interoperability: Why Integration Is a Design Decision, Not a Runtime Problem

Executive Summary

Enterprises have traditionally treated integration as work performed when one system needs another. That approach can connect applications, but it does not create interoperability. Interoperability depends on earlier agreements about meaning, authority, identity, events and contracts. AI agents make the distinction visible because they cannot reliably compensate for undocumented semantics in the way experienced developers often do. The strategic shift is from building connections at runtime to designing a fabric of explicit contracts that allows capabilities to compose predictably across domains.

Thesis

Interoperability is not primarily a runtime integration problem. It is a design-time agreement problem. Connections can be added later; shared meaning cannot be retrofitted cheaply once every domain has encoded its own definitions and assumptions. Organizations that establish explicit contracts, authoritative entities and version discipline create a fabric in which each new capability is easier to connect. Organizations that defer those decisions accumulate translation work with every new use case.

Claim A: Connectivity is not interoperability

Two systems can exchange messages and still disagree about what those messages mean. A customer identifier may represent a person in one domain, an account relationship in another and a billing entity in a third. A status field may be technically valid but operationally incompatible. Point-to-point integration hides these differences by placing translation logic between systems. The connection works, but the enterprise has not resolved the underlying semantic disagreement.

This is why integration debt can grow even while integration tooling improves. The enterprise becomes more capable of connecting inconsistent systems without becoming more consistent. Each adapter solves a local problem and creates another artifact that must be understood, tested and changed when either side evolves.

Claim B: Agentic systems turn implicit knowledge into an operational dependency

Human engineers often carry undocumented context: which source is trusted, which field is stale, which event has a misleading name and which exception is safe to ignore. AI agents operating across domains need that context to be represented explicitly. Where meaning and authority remain tacit, the agent must either guess, escalate or fail.

The important consequence is not that agents require perfect enterprise data. It is that they increase the value of explicit contracts. A platform intended to support machine-assisted action needs discoverable schemas, clear entity authority, version rules and observable exceptions. Otherwise, every new agent becomes another custom integration project.

Claim C: The interoperability fabric is a governance asset

A schema registry is useful because it makes contracts visible, but the registry is not the fabric. The fabric is the combination of technical contracts and governance agreements that determine how domains interact. It includes ownership, versioning, compatibility rules, authoritative sources and a process for changing shared definitions without breaking consumers.

That makes interoperability a cross-domain governance capability. Architecture can provide standards, but domain teams must own the meaning of the data and events they publish. Platform teams can provide registries and tooling, but leaders must create incentives that make contract discipline easier than bypassing it.

Counterposition: Standardization can destroy useful domain autonomy

A single canonical model for the entire enterprise can become as brittle as point-to-point integration. Domains have legitimate differences, and forcing every team into one universal definition can slow change and create abstractions that satisfy nobody.

The objective is therefore not semantic uniformity. It is explicit translation at stable boundaries. Shared contracts should standardize what consumers need to rely on while allowing domains to preserve internal models that fit their work. Interoperability succeeds when differences are deliberate and documented rather than accidental and hidden.

Implications for platform and engineering leaders

Begin with the journeys that matter most, especially those that cross several domains or are candidates for AI-assisted execution. Audit the contracts those journeys depend on. Identify which schemas are registered, which entities have clear authority, where versioning rules exist and where teams rely on institutional knowledge.

Then make contract registration and compatibility checks part of delivery. New domains should publish their contracts before consumers depend on them. Existing domains should prioritize the boundaries with the highest reuse or highest failure cost. Track contract coverage, breaking changes, integration lead time and the amount of custom translation required per new use case. These measures show whether the fabric is becoming easier or harder to extend.

Evidence and operating illustrations

Integration is a runtime problem. When two services need to exchange data, build the connection. When an AI agent needs to traverse domain boundaries, solve the translation at the point of deployment. When something breaks because the upstream model changed and the downstream adapter was not updated, fix it. The integration team handles this. The assumption behind this approach is that interoperability can always be added later ; that composing systems together is an operational challenge, not a design one, and that it can be deferred until the specific integration need arises.

This logic is how most enterprise platforms were built. It is the reason why, according to ONEiO's 2026 integration research, 71% of enterprise applications remain disconnected or unintegrated ; a figure that has held flat for three consecutive years despite significant investment in integration tooling. The problem was not tooling. It was the logic that said integration could be deferred.

Agentic AI has changed the cost equation for integration debt. Before agentic AI, the cost of undocumented integration was paid by developers: they learned informally which system's customer record to trust, what "CustomerUpdated" meant in the CRM versus the order management system, and how to compensate for the fact that neither matched exactly. That informal knowledge worked because developers have context and judgment. They could navigate the inconsistency.

An AI agent follows contracts literally. It does not have the contextual judgment to compensate for an undocumented entity model or a conflicting field name. If the event schema says one thing and the canonical entity says another, the agent fails. MuleSoft's 2026 Connectivity Benchmark finds that 50% of AI agents are already operating in isolated silos, unable to act across system boundaries. Gartner predicts that 40% of enterprise applications will integrate task-specific AI agents by end of 2026 ; roughly an eightfold increase in agentic load on the same underlying data fabric. The integration debt that developers managed informally is becoming an agent failure rate. The compounding is negative: each new agent deployed into an undesigned fabric produces more failures, not fewer.

For engineering organizations with existing platforms: the immediate diagnostic is a schema audit. Pull the event schemas that your AI agents' target use cases need to traverse. Count how many are registered in a shared registry, versioned, and documented. Count how many exist only in code or in the heads of senior engineers. The ratio tells you precisely where your integration debt sits and which boundaries will produce agent failures in the next use case build.

First, introduce a schema registry and register existing contracts ; even imperfect ones. The act of registration makes the debt visible. Apache Kafka Schema Registry and AWS Glue Schema Registry are mature, available, and require no significant architecture change to introduce alongside existing services.

Second, run an entity authority audit. For each core entity your AI use cases need to access, identify the de facto authoritative source and document it. This is a facilitated workshop, not a technical project. The output is a one-page authority map. It does not require new systems.

Third, make schema registration a deployment gate for new domains. Schemas that are not registered before deployment do not ship. This integrates into existing CI/CD pipelines with low friction and permanently changes the design posture for every domain that follows.