Most organizations have now adopted AI agents that could do remarkable work. Far fewer have a clear way to connect those agents to enterprise data spread across many systems. In almost every conversation we have, whatever the industry, someone asks how to make sure agents use the right definitions once they're pointed at real data.
Take an epidemiologist who asks an agent how many type 2 diabetes patients also filled a GLP-1 in the last year. The agent has to know which diagnosis codes, which drug codes, what continuous enrollment means, and which sources hold which variables. Ask three teams and you may get three answers, each living in a different catalog, warehouse or partner environment. Agents don't hesitate when definitions conflict. They pick one and answer with confidence.
The second blocker follows right behind. A data leader at a large pharma company described it to us this way: an agent may have access to the same five datasets its human user does, but not the five others that would make its answer right. Even with the right definition, the data usually sits behind contracts, consent terms and security reviews, and no one approves an agent with a path to data the organization can't pool or expose. Renegotiating those agreements for agents is slow. Federated access works inside them, a bit like extending the consortium.
We come at this from epidemiology and real-world data, where a definition can change the answer. We've since seen the same pattern in life sciences, healthcare, financial services and the public sector, and it comes down to two problems that most data tooling treats separately. Here is how we think about them.
Semantic layer vs. context layer: what's the difference?
Before we get to those two problems, it helps to pin down the vocabulary. The industry is using "semantic layer" and "context layer" as if they were interchangeable, and the answer to what agents need depends on where one ends and the other begins.
Here is how the main terms line up:
The first four describe data inside one system, one platform or one company's estate. That works well when the data lives in one place, and these tools are very good at it. They are also the sources we read from, which is why we treat them as partners. Newer tools that draft catalog entries with agents and steward review feed the same pipeline. Ontologies sit alongside them as shared standards: public concepts and identifiers that these tools can map to. A context layer joins those standards to a company's own internal definitions.
The gap shows up when the data an agent needs sits across business units, acquisitions, affiliates, partners and vendors, and often can't be pooled. When the data can't be pooled, the meaning isn't pooled either. Each system keeps its own definition of "active customer" or "continuous enrollment," and nothing reconciles them. The Pistoia Alliance calls one version of this FAIR silos: data that is findable and reusable inside one organization but not across them. Most large enterprises have this problem inside their own walls, and it only grows across organizations.
Reconciliation puts the competing versions side by side, and the owners decide which one the enterprise uses.
So agents face two problems at once: what the data means (context) and how to reach it safely (governed access). A tool that solves only one leaves the agent guessing or leaves security saying no. So the answer to the title question is that you need both, and neither a semantic layer nor a context layer is enough once the data lives in more than one place.
What would solving both look like? Shared meaning, paired with governed access through MCP
Context without access is a glossary. Access without context is a query engine no agent can use safely. Any serious answer has to cover both, so we'll take them in turn, using Rhino as the worked example.
Rhino started with federated networks across organizations. Code goes to the data, and only approved, privacy-screened results come back, as in a federated drug discovery network of >100 members and Swift's Secure Data Collaboration in banking. The newest piece is Enterprise Context Orchestration, which tells agents which definition applies.
You can deploy this inside a single enterprise, across the business units, regions, clouds and warehouses that each hold their own data and definitions. It also extends across organizations, such as partners, affiliates and consortia, with the same architecture and more participants. A "site" below can be either: a business unit or an outside organization.
Every agent request enters through the MCP server. The data stays in place, and definitions come from the tools you already run.
Meaning: shared definitions through Enterprise Context Orchestration (early access)
An agent has to know what the data means before it can use it correctly. We're working on that layer in Rhino's Enterprise Context Orchestration, which is in early access.
Enterprise Context Orchestration works across the catalogs and semantic layers you already run. They describe data inside their own systems; it reconciles definitions across systems and organizations. It works in two steps:
- Connect. Register the datasets that matter and bring in definitions from your existing tools. Rhino then profiles the actual values at each site: completeness, ranges, value sets and units.
- Reconcile. Conflicting definitions appear side by side, with the evidence. Owners review the evidence and approve one enterprise definition or purpose-specific variants, and every version is tracked, so nothing changes silently.
Access: the Rhino MCP server and governed platform
The second half is control over what an agent can reach. The principle is that an agent should reach only the data it has been explicitly permitted to use, and the analysis should travel to the data rather than the other way around. In practice, agents connect from any MCP-compatible tool (e.g., Claude, Gemini, internal assistants) to the Rhino MCP server, which gives them tools to discover data, plan analyses and run them. Behind it:
- Privacy-preserving, SDK analytics. The analysis runs inside each site's environment with the approved definitions applied, and only approved, privacy-screened results return.
- Enterprise integrations. Data is retrieved in place from the systems it already lives in (Snowflake, Databricks, on-premises databases), or Rhino hosts it where a partner lacks DevOps. The controls are the same either way.
- Permissions. Each data owner decides what runs on its data and what leaves.
- Controls, set per project. Role-based access, differential privacy budgets, k-anonymity thresholds, output screening and optional workload pre-approval.
- Audit. Every agent action through Rhino is logged and traceable.
Put together, it looks like this. A user asks a question in their own AI tool. The agent reads approved context through the Rhino MCP server and plans the analysis. The platform runs it next to the data and returns results with their sources and definition versions.
Does Rhino replace my catalog, semantic layer or data platform?
No. Rhino can be used as middleware that works with the stack you already have.
Some of these connections work out of the box. Others are set up during implementation.
What does this look like for a life sciences team?
Back to the epidemiologist from the opening. Here is an illustrative example based on work with a global pharmaceutical company.
Their epidemiologists work with large US claims data in Snowflake. A feasibility question (how many patients meet the criteria, what continuous enrollment looks like, which variables exist) goes through a data engineering queue and takes about two weeks. The goal is to let them ask those questions directly from the company's internal AI assistant and cut the turnaround from weeks to the length of a conversation.
The pieces:
- The claims data is mapped to OMOP.
- Approved context covers cohort rules, condition and drug code lists, the enrollment definition, and which tables hold what.
- The agent connects through the Rhino MCP server, and skills guide common steps such as concept code lookup, code lists and cohort building.
- Counts, prevalence and incidence, Kaplan-Meier and Cox run next to the data, and aggregates return under the project's privacy settings.
The highlighted step is where shared meaning enters: the agent reads approved definitions before it plans anything.
Here is how that looks to the person asking, in a demo of Rhino's context layer with illustrative figures: the question in plain language, the approved definitions the agent matched before it ran anything, and the answer with its sources and a flag.
They are starting small: synthetic data first, then a scoped real sample, then scale, all inside one company's environment.
Once one dataset works, the same approved definitions carry over when the question extends to EHR data held by partners in Europe that can't be pooled with US claims. The agent asks the same question, and each site answers it under the same definitions.
Is this only a life sciences problem?
No. Financial services is a good second example, and what follows is illustrative of what we hear from large banks. It is a single institution, and the same pattern applies across institutions.
Think of an institution with thousands of applications and federated data governance, where each domain owns its data and often its definitions of "customer," "exposure" and "active account." Many are mid-migration to a public cloud. The constraints stack up fast: GDPR, cross-border transfer rules, the EU AI Act, data sovereignty and vendor risk. The gap they name is protecting data in use, beyond data at rest and in transit.
What they want from agents is authorized discovery of what data exists and what it means, agent workflows that never surface PII, policy enforcement, and visibility into what agents did.
Those requirements line up with the pattern above: reconcile definitions across domains, give agents authorized discovery, run code inside each domain or jurisdiction, screen outputs and log what agents do. Banks have been exploring federated approaches like this for some time, including through our work with Swift.
The same two problems appear wherever data is split across business units, partners or jurisdictions: insurers and benefits providers, public agencies, manufacturers with distributed equipment fleets.
Where to start
If you're deciding where to start, pick one question your agents will need to answer across two systems (two inside your own company is plenty) and write down every definition it depends on. The places where those definitions disagree are your real backlog, and no model upgrade will close them. Governed access is the part you can put in production today. Shared meaning across systems is the newer piece, and we're building it with early-access customers.
If your teams are asking the same question, we'd like to compare notes: contact@rhinofcp.com.
