What Is Interoperable Context? Why Portability Is the Real Test

Most enterprise context already exists somewhere, often in multiple places at once:

• A glossary entry settles which of two definitions of “active customer” governs
  
• The dbt model where a revenue metric is actually calculated
  
• A certified dashboard that several teams treat as the canonical number
  
• A wiki page explaining why Q3 is calculated differently from every other quarter
  
• Query history, which records the joins and filters analysts really apply even though nobody wrote them down
  

This is all real context, carefully documented. But the problem is where it’s been documented. Each of those definitions was authored in whichever tool the person happened to be working in, and it has stayed there ever since.

So the question facing most data teams is not whether their organization has context. It is whether that context can leave the room it was written in, which is what a context platform is built to solve.

What interoperable context really means

Interoperable context is business context that still works after it leaves the system where it was created. It often sits alongside a term it gets confused with:

• Data interoperability is a property of systems. It describes whether a receiving system can correctly interpret and act on data that arrived from somewhere else, rather than merely receive it.
  
• Interoperable context is a property of the meaning that travels with that data. It is the definitions, validation status, query patterns, and freshness signals that have to arrive intact for the receiving system to interpret anything correctly.
  

One is the outcome, and the other is what produces it. A system cannot be interoperable with data whose meaning stayed behind. You improve interoperability by changing how systems talk to each other. You get interoperable context by changing where context is authored and how it is served, which is an architecture decision rather than an integration project.

Why interoperable context is not a protocol

The most common thing mistaken for interoperable context right now is an open protocol. Model Context Protocol (MCP) lets any agent connect to a source and retrieve from it, and that reach genuinely matters. But a protocol is transport. It moves whatever it is pointed at, including context that was never reconciled or reviewed. An MCP server exposing four conflicting definitions of revenue distributes that ambiguity to every AI application that calls it.

Portability is a property of the context itself: whether it carries enough with it to be trusted on arrival. The protocol determines how far it can go. It does not determine whether it should have gone.

The same limit applies to prompt engineering. A carefully written prompt can tell an agent how to behave, but it cannot supply authority that the underlying metadata never recorded. Portability is a property of the infrastructure holding the context, not of the model reading it or the prompt framing the question.

What makes context portable?

Five things have to be true of context before it can travel.

Most enterprise context fails on at least the first two, and it fails quietly, because nothing about a definition tells you where it came from or who checked it. That quietness is what changed: A person handed an ambiguous definition goes and asks someone. An agent handed two plausible definitions picks one, and proceeds with full confidence, and the failure surfaces later in a board deck.

Confidence in this area runs well ahead of capability. In the 2026 State of Context Management Report, which surveyed 250 IT and data leaders, 88% said they were confident their organization had a fully operational context platform, while 61% said they usually or frequently delay AI initiatives because they lack trusted and reliable data. Both can be true at once when context exists but stays where it was written.

The market’s answer: a context layer for every platform

Platform vendors saw the same problem their own customers were hitting: agents running inside their platforms were answering questions wrong because they had no access to the business meaning behind the data. Their solution was to build a context layer into each platform, assembling definitions automatically from signals the platform already holds and serving them to that platform’s agents at query time. The instinct is right, but it’s not a complete answer.

Here are some examples: Snowflake Cortex Sense learns business definitions from query history, object metadata, and BI dashboard definitions, then serves that context to Snowflake’s Cortex agents at query time. Databricks Genie One derives an ontology from the workspace and grounds Genie’s answers in it, drawing on definitions governed in Unity Catalog. Microsoft is building IQ. Salesforce has Data Cloud.

And this is not a passing trend. According to Constellation Research, close to every significant platform vendor is now investing in some form of context layer.

Here’s what a platform-native context layer can do:

• Assemble context automatically from signals the platform already holds, with no modeling project first
  
• Give agents usable context on day one rather than after a documentation push
  
• Keep definitions consistent across every agent surface the vendor operates
  
• Stay current with the platform it lives in, because it is watching that platform directly
  

Inside its own boundary, this works. For a team whose analytics run entirely in one platform, a native context layer may be most of what they need. But this isn’t the case for most teams.

Why this isn’t sufficient

Each layer is built into the platform it serves, so the context it produces reaches that platform’s agents and stops there.

Signals can flow inward from outside. Cortex Sense reads BI dashboard definitions, and Horizon Context ingests metadata from a limited set of external data sources. The reverse does not happen. An agent running in Databricks cannot call Snowflake’s context, and neither can a custom agent, a coding assistant, or the model your support team is using.

In a single-platform estate, this costs nothing. But in a multi-platform estate, which is most of them, the result is not one context gap but several context islands. Each island is internally correct. None of them can see the others. Every definition worth having gets authored once per platform, and the drift the context layer was supposed to eliminate reappears between them.

Measured against the five properties, a per-platform context layer clears validation and currency inside its own walls and fails the rest:

Modularity, in turn, depends on open interoperability with a vibrant commercial and open-source ecosystem. Context must be portable across data platforms, AI/ML tools, and LLMs.

How does a context platform make context truly portable?

A context platform like DataHub is the infrastructure layer that ingests context from across a data estate, structures and validates it, and serves it to any agent regardless of where that agent runs:

• Context management is the organizational capability
  
• A context platform is the infrastructure that delivers it consistently
  

The relationship between a context platform and any platform-native context layers is additive:

• The native layer keeps doing what it does well for its own agents
  
• The context platform gives it what lives outside its boundary, and serves the same governed definitions to every agent the native layer cannot reach.
  

Adding a context platform into the mix changes things in three ways:

• Context has one home. Definitions, ownership, validated query patterns, and institutional knowledge from tools like Confluence and Notion land in one graph rather than being rebuilt per platform. DataHub connects more than 150 systems, which is what makes one home practical rather than aspirational.
  
• Humans validate once, upstream. A model can draft a definition from lineage and usage. It cannot decide which of two legitimate definitions wins, because that is a business call. In DataHub Cloud, generated context lands as a draft, competing definitions are surfaced for a person to resolve, and nothing publishes to agents without approval. The resolution happens once, at authoring time, and every agent downstream inherits it.
  
• Serving happens through open interfaces. Governed context reaches agents through a hosted MCP server, GraphQL, and APIs and SDKs, so Genie, Cortex, Claude, Cursor, or an agent built on a framework like LangChain all retrieve from the same graph, without a bespoke integration for each.
  

An argument against lock-in is only as strong as the architecture making it, and a closed platform arguing for portability is asking you to trust that its lock-in is the acceptable kind. DataHub’s core is open source, its context is served through open protocols, and it fields no competing agent of its own. The incentive is to make other vendors’ agents work better, which is the same thing customers want.

What this looks like in production: FIS and Databricks Genie

FIS builds software for banks, serving more than 20,000 clients whose transactions run to 75 billion per year. Its team set out to let those bank clients ask natural language questions about their own customer data, delivered inside FIS’s existing product interface.

The data lived on a mainframe, where column names carry no semantic meaning at all. Genie’s ontology derivation closed part of that gap on its own, working from what it could scan. What it could not reach was knowledge that had never been written into any system.

That got us honestly about halfway there. In any large enterprise, the real knowledge is gonna be tied up in people’s heads, and I don’t know anybody that’s writing an adapter yet that can go into someone’s brain and pull that out.

Frank ShowalterVP of Data Engineering and Governance, FIS

Four capabilities of the DataHub Context Platform closed the remaining distance:

• Context Ingestion built a unified context graph from mainframe-sourced tables, existing pipelines, and every system that touched them, including sources whose columns carried no meaning on their own.
  
• Context Intelligence mined query history and existing patterns into semantic meaning that an automated ontology scan could not reach.
  
• Context Hub gave FIS’s subject matter experts a shared workspace to review and approve proposed context before any of it reached Genie.
  
• Context Activation made that validated context available through APIs, SDKs, and MCP, so it was built once and read everywhere rather than re-documented per tool.
  

The outcome was better Genie accuracy, and beyond that, a product line FIS did not have before. Natural language query became something the company could offer its banking clients rather than an internal efficiency gain.

The architecture point matters more than either result. Genie remained the agent. Databricks remained the platform. What changed is that the context underneath both of them was authored somewhere neither one owned, which is why it was available to Genie and would be available to whatever FIS builds next.

Most organizations do not have a “context existence” problem so much as a “context location(s)” problem. The definitions exist, they are mostly correct, and the work is moving them somewhere every agent can reach, including the agents that do not exist yet. See how DataHub approaches context management, or book a demo to walk through it against your own stack.

FAQs