What Is Data Interoperability? Why Connectors Aren’t Enough

Every vendor in your stack now claims to offer interoperable data. What most of them mean is that they have connectors. To be clear: Connectors matter. But they’re the entry-level bar to interoperability. Because of this, the word “interoperable” does very different work depending on who says it and what they mean. And those differences matter much more now that agents, not analysts, are the fastest-growing consumers of enterprise data.

What data interoperability actually means

A connection is not interoperability. A pipe between Snowflake and a BI tool proves that data can move between the systems. Interoperability is the harder thing that has to happen next: when the data arrives, the receiving system needs to ‘understand’ it well enough to use it correctly.

That distinction is the whole subject. Data can arrive intact and still be unusable, because, for example, the receiving system has no way to know that rev_net_adj is the finance team’s audited revenue figure, that it excludes intercompany transfers, or that a different table with a nearly identical name is the one the sales org actually reports on.

Interoperability closes that gap. It lets teams:

• Combine data from multiple systems without manual reconciliation
  
• Onboard a new tool without rebuilding governance from scratch
  
• Give both people and machines a consistent answer to the same question
  

A context platform is the infrastructure layer that makes this possible across a stack no single vendor controls.

Data interoperability vs. data integration

These two terms get used interchangeably, and they are not the same thing:

• Data integration is the movement problem. It covers extracting data from a source, transforming it, and landing it somewhere else. Integration is measured in pipelines, connectors, and successful runs.
  
• Data interoperability is the comprehension problem. It covers whether the receiving system can interpret and act on what it received. Interoperability is measured in whether the answer coming out the other end is right.
  

You can have complete integration and near-zero interoperability. Most enterprises do. Every system is connected, and the definition of “active customer” still differs across four of them.

Connectors vs. interoperability

Most platforms claim interoperability because they have connectors. That is why a connector count is a misleading measure of it.

A connector proves a pipe exists, which is the integration layer and genuinely necessary, but it does not carry the meaning attached to what it moved:

• A metric defined in dbt lives in dbt
  
• A certified dashboard definition lives in the BI tool
  
• A caveat about why Q3 is calculated differently lives in a Confluence page that three people know about
  

Each is a legitimate act of context creation, and none of them travel.

This is worth keeping in mind as the claim evolves. The newest version of “we’re interoperable” is “we have an MCP server.” An open protocol like MCP lets any agent connect to a source and pull from it, which genuinely matters for reach. But a protocol is still plumbing. It carries context to the agent without guaranteeing that context was validated, reconciled, or governed first. An MCP server that exposes raw, conflicting definitions just distributes the ambiguity faster.

So interoperability is not a count of the systems you connect, or the protocols you support. It is whether meaning survives the trip between them.

How do you get from data integration to interoperability?

Interoperability is usually described in four levels. It is a useful model, but it’s misleading because the four levels are not four kinds of interoperability. They are a progression that starts in integration and only crosses into interoperability halfway up.

	Level	What it establishes
Integration ↓	1. Transport (aka foundational, technical)	A connection exists and data moves between systems
	2. Syntactic (aka structural)	Formats and structures are mutually readable
Interoperability	3. Semantic	The receiving system shares meaning, not just format
	4. Organizational	Governance and process align so meaning can flow and be trusted

Integration has to come first. You cannot comprehend data you cannot move or parse, so transport and syntactic are real prerequisites, not throwaway steps. But that’s just the beginning, not the destination.

Here’s the challenge for those trying to grasp this space: Most organizations complete the first two integration pieces but then they stop and call the result interoperability. It is not. Interoperability begins at the semantic level, where systems share meaning rather than just format, and it is not finished until the organizational level makes that meaning governed and trustworthy.

The industry has spent years selling integration as if it were interoperability. It photographs well in a pitch deck. Then you are left holding a hundred connectors that all move data and none of them agree on what the data means. Technically, everything is wired together. Practically, nothing understands anything.

Where most stacks sit today

Transport and syntactic interoperability are largely solved problems. Managed connectors, open table formats, and REST APIs have commoditized the mechanics of moving structured data between platforms. Snowflake, Databricks, and the major clouds all federate query access across a defined list of external systems.

Semantic interoperability is where the work often stops. Most organizations have a business glossary somewhere. Far fewer have one that reaches the systems where the data is actually consumed. According to the 2026 State of Context Management Report, 57% of organizations struggle to identify authoritative sources of truth across their data estate. Organizational interoperability is mostly aspirational outside of regulated industries where a standards body forced the issue.

How AI agents highlight the gap between integration and interoperability

This conflation of integration and interoperability might have worked when a human or a purpose-built application sat on the receiving end, there to supply the judgment the model leaves out. But that is no longer the case. Now the consumer is an agent, not a human.

Handed two plausible definitions of the same metric, an agent picks one and proceeds with full confidence. There is no pause, no Slack message, and no visible signal that a judgment call was made. The failure surfaces later, in a board deck.

That means an agent needs four things made explicit that a human on the receiving end used to supply on their own:

• Authority: When two definitions of “active customer” exist, which one governs.
  
• Validation: Whether a person with domain expertise confirmed the definition, or whether a model inferred it.
  
• Usage: How analysts actually query the asset, including the joins and filters that never made it into documentation.
  
• Recency: What changed in the last 48 hours, and whether the definition it is reasoning over is still current.
  

These are context problems, and they are the reason interoperability claims that stop at the semantic rung leave agents guessing. The cost of that gap is measurable. The 2026 State of Context Management Report found that 41% of organizations cite data fragmentation and 43% cite tool integration complexity as obstacles to scaling AI agents, and that 57% are duplicating AI efforts across departments because no unified context graph exists.

Where humans still stay in the loop: Upstream validation

In this ‘new’ AI consumer reality, humans do not disappear from interoperability. They move upstream. Instead of resolving ambiguity at read time, once per query, a person resolves it once, at authoring time, and every agent downstream inherits the answer.

This matters most when the ambiguity is not a data problem. Finance and sales define “active customer” differently, and no amount of query history settles it, because it is a business decision. A model can draft a definition from lineage and usage. It cannot pick which of two legitimate definitions wins. That call goes to the domain expert who owns the term, before the definition reaches an agent.

In DataHub Cloud, that happens in Context Hub. Generated context lands as a draft, competing definitions are surfaced for a human to resolve instead of one being picked automatically, and context is reviewed and approved before agents rely on it. Evaluation closes the loop. When an agent gets an answer wrong, you can trace it back to the context behind it. Miro used this to move agent accuracy from roughly 50% to roughly 90%.

Five things true data interoperability actually requires

Five capabilities separate interoperability that holds up in an agentic stack from interoperability that stops at the pipe.

1. Context travels the full stack, from source to BI

Meaning gets created at every stage of a data workflow, not only at the warehouse. A column description written by an ingestion engineer, a metric defined in the transformation layer, and a certification applied to a dashboard are all context, and all three describe the same underlying asset.

Interoperable context connects them. DataHub connects more than 100 systems from source through transformation to BI, so a definition authored anywhere in that chain remains attached to the asset as it moves through the rest of the workflow, from source to prompt, so the context an agent retrieves is AI-ready rather than reassembled on the fly.

Pinterest built its semantic backbone on exactly this principle, unifying context and intent signals so its text-to-SQL agents could resolve questions against the assets analysts actually use.

2. Structured signals and unstructured knowledge live in one graph

Interoperable context has to span both halves of what an organization knows.

The structured half is schemas, lineage, glossary terms, and metric definitions in dbt or Power BI. The unstructured half is Confluence pages, Notion docs, and runbooks. A platform that federates only structured metadata, ignoring the unstructured data sources, is solving half the problem, and usually the easier half. This is not a rare shortfall. In BARC’s 2026 study, 70% of organizations reported that less than half of their unstructured data is discoverable and usable for analytics and AI.

The reason matters. Institutional knowledge about why a metric is calculated a certain way almost never lives in a schema. It lives in a runbook, a decision doc, or a thread from 14 months ago. DataHub fuses both halves into a single, unified context graph and can link each piece of knowledge to the assets it describes, so an agent retrieving a metric definition also retrieves the caveat attached to it.

3. Any agent can reach the same context

Context served through a single vendor’s runtime gives data access only to that vendor’s agents. Context served through an open protocol reaches whatever the organization is running.

DataHub serves governed context through a hosted MCP server, so Genie, Cortex, Claude, Cursor, or a custom agent built on an internal framework all retrieve from the same graph. The protocol handles reach. What makes that reach worth having is that the context on the other end is already governed and validated, rather than raw metadata piped to whatever asks for it. The alternative is rebuilding the same definitions once per platform, which reintroduces the drift the platform was supposed to eliminate.

4. Context survives change instead of decaying after setup

A connector that pulls once is not interoperable in any durable sense. Context drifts the moment a schema changes, a pipeline is restructured, data quality shifts, or a definition is updated somewhere else in the stack.

This is why the architecture underneath matters more than the feature list. Event-driven propagation reflects a change as it happens. Scheduled batch jobs guarantee a window during which agents are reasoning over definitions that are already wrong, and nobody can see which ones. The question to ask a vendor is not whether context updates, but what the minimum latency is between a change in a source system and its reflection in the context layer.

5. Governed context flows outward as well as inward

Most interoperability claims describe ingestion: pulling data and metadata in from many sources. The harder and less-discussed half is pushing governed context back out.

A glossary term or sensitivity tag defined once should appear on that asset everywhere it lives, not only in the tool where it was authored. DataHub does this through platform-specific sync automations, available in DataHub Cloud.

• Snowflake Metadata Sync applies DataHub tags, glossary terms, and descriptions to Snowflake, and removes them when they are removed in DataHub.
  
• BigQuery Metadata Sync synchronizes tags, descriptions, and column glossary terms, mapping glossary assignments to BigQuery policy tags.
  

Terms also propagate along column-level lineage, so a column of sensitive data classified as PII in one table carries that classification to every downstream copy.

The practical effect is that governance authored once shows up in the console where the data engineer is actually working, rather than in a catalog they have to remember to open.

Separating integration from interoperability: A handy checklist

When a vendor claims interoperability, these are the questions that tell you whether they truly mean it. Each one tests their claim against the definition in this piece, and separates true interoperability from integration dressing itself up as interoperability.

• Does it connect structured and unstructured sources across the full stack? Databases alone leave out the documentation where institutional knowledge lives.
  
• Does it extract semantic meaning, or only technical metadata? Business definitions and validated query patterns, rather than schemas and column names.
  
• Does it propagate continuously as data and definitions change? Ask for the minimum latency between a source change and its reflection in the context layer.
  
• Does context flow outward to every platform, as well as inward from every source? Ask specifically what gets written back — tags, glossary terms, descriptions — and to which platforms.
  
• Does it serve any agent through an open protocol? MCP or an equivalent, rather than a single vendor’s runtime.
  
• Does it route ambiguous or conflicting context to a human before an agent sees it? A review workflow and an approval step that is on by default.
  

A platform that clears all six is interoperable in the sense that we’ve outlined. A platform that clears the first two has connectors and merely achieves integration.

FAQs