Ask an AI agent how many sites are active in a study and you can get three answers. The clinical trial management system counts a site as active once it is initiated. The payments system counts it once it has an approved budget. The monitoring dashboard counts it once a patient has been screened. All three are correct inside their own system. The agent picks one, phrases it confidently, and nobody in the room knows which definition it used.
That is the real reason most AI agents on life sciences data stall after the demo. The model is not the bottleneck. The layer between the model and the data is. Most organisations have never written that layer down, so the agent reconstructs it on every query, differently each time.
This article is about that layer, usually called a semantic layer, and why it decides whether an agent can be trusted on regulated data. It ends with a short diagnostic you can run before anyone builds anything.
What a semantic layer means in practice
A semantic layer is the set of agreed definitions, curated views, mappings and lineage that sits between raw source systems and whatever consumes them, whether that consumer is an analyst, a dashboard or a language model. In practice it answers four questions for every field an agent might touch: what does this mean, which system is the source of truth for it, how is it calculated, and who is allowed to see it.
It is not an ontology project that runs for two years before anything ships. It is not a catalogue of table names. It is also not a prompt that lists column descriptions, although that is where most teams start. A working semantic layer is a maintained engineering artifact: versioned definitions, tested transformations, and a record of how every number on the surface traces back to a row in a source system.
The distinction matters because the agent inherits whatever the layer gives it. If "reimbursement date" exists in three tables with three meanings, the agent has three meanings. If the layer resolves it to one definition with one calculation and one lineage path, the agent has one.
Why the model is rarely the constraint
The public benchmarks say this more bluntly than most vendors do. Spider 2.0, an evaluation framework built from 632 real enterprise text-to-SQL workflow problems, reports that the best code agent in the study solved only 17.0% of tasks, against 91.2% on the earlier Spider 1.0 benchmark and 73.0% on BIRD. The questions did not get harder in a linguistic sense. The databases got realistic: thousands of columns, multiple dialects, business logic that lives in nobody's documentation.
A separate benchmark by Sequeda, Allemang and Jacob tested the same idea from the other direction. On an enterprise insurance schema, GPT-4 answered 16% of questions correctly when pointed directly at the SQL database. When the same questions were asked over a knowledge graph representation that carried an ontology and mappings, accuracy rose to 54%. The authors work for a data catalogue vendor, so read the absolute numbers with that in mind. The direction is the point: the same model, the same data, and the result moved because the definitions moved.
Life sciences data is harder than an insurance schema. A market access platform we work on had 390+ backend tables before anyone asked it a question in natural language. Clinical, pricing, reimbursement and assessment data arrive from different countries, on different cadences, with country-specific meanings for the same word. No model fixes that by being larger.
Why regulated data raises the bar
In an unregulated setting, an agent that is right 80% of the time can still be useful. In a regulated setting, the question is not only whether the answer is right but whether you can show how it was produced.
Both major regulators have started to say this in their own language. The FDA's January 2025 draft guidance on AI used to support regulatory decision-making is built around a risk-based credibility assessment framework tied to a defined context of use. The EMA's reflection paper on AI in the medicinal product lifecycle, adopted in September 2024, asks for a human-centric approach across development and deployment. Neither document is about semantic layers, and neither is a checklist you can engineer against. What they describe operationally is the same requirement: a defined scope, documented data, and the ability to reconstruct an output.
An agent that reads curated, versioned definitions can meet that requirement. An agent that improvises joins across raw tables cannot, no matter how good its answers look in a demo. This is why the semantic layer is not a nice-to-have for AI in life sciences. It is the thing that turns a plausible answer into an auditable one.
Where the engineering actually sits
When teams budget for an agent, the budget usually goes to the model, the orchestration framework and the chat interface. The work that decides the outcome sits one level down:
Entity resolution. The same product, country, site or payer appears under different identifiers in different systems. Resolving them is slow, specific work, and the residue has to be handled honestly: flagged and carried, not silently dropped.
Curated views. A small number of purpose-built views, each encoding one agreed definition, give the agent a surface it can reason about. The raw schema stays where it is.
A definitions registry. Every metric and field the agent can use has an owner, a calculation and a version. When the definition changes, the change is recorded and the agent's answers change with it.
Lineage. Every output can be traced back to the source rows and the transformation that produced it. Without this, the agent cannot be validated and its answers cannot be defended.
Access control at the layer, not in the prompt. Who can see what is enforced where the data is served, so the agent cannot be talked into a field it should not have.
Tests. Definitions are code. Code gets tested. A view that quietly changes meaning after a source migration is the most common way an agent starts being wrong without anyone noticing.
This is ordinary data engineering, applied with more discipline than a dashboard needs, because the consumer is a system that will phrase whatever it is given as a fact.
Definition debt: seven questions to ask before the agent
Most organisations carry what we call definition debt: the gap between how many fields their systems hold and how many of those fields have one agreed meaning. Before any agent project, it is worth answering these seven questions honestly.
For the ten metrics your team reports most often, can you name the single system of record for each one?
If two systems disagree on one of those metrics today, is there a written rule for which one wins?
Does each metric have a named owner who can approve a change to its definition?
Can you trace a number on your most-used dashboard back to the source rows without asking the person who built it?
How many of your core entities (products, sites, countries, payers) have more than one identifier across systems, and is the mapping maintained anywhere other than a spreadsheet?
When a source system was last migrated or upgraded, did any report change meaning without a code change?
Is access to sensitive fields enforced in the data layer, or only in the applications that currently read it?
If more than two of these have uncomfortable answers, the agent is not the next project. The semantic layer is. The good news is that this work is bounded, it is measurable, and it pays back whether or not an agent ever ships, because analysts and dashboards inherit the same clean definitions.
What this looked like in production
The clearest example we can share is a domain-specific AI SQL agent built for a global CRO's market access platform. The first version, a chatbot over a handful of fields, was accurate enough to demo and not useful enough to keep. The work that changed it was almost entirely in the layer underneath: 390+ backend tables analyzed, then seven purpose-built SQL views that encoded the definitions analysts actually used. Data coverage went from 20 fields to 250+, a 10x increase. Query responses got 35% faster. The agent reached production 21 weeks after kickoff and is still in daily use, freeing hundreds of analyst hours a month. The model changed over that period. The views are what made it trustworthy.
The same pattern holds when the "definitions" are expert judgement rather than database fields. For an AI engine that predicts and consolidates the PICOs European health systems ask for, built for the same CRO, the work was turning expert reasoning into 22 country decision trees, each validated by the people whose judgement it encoded, across 10 health systems and 7 disease areas, with full provenance from every consolidated PICO to its source. The language model does the reading. The decision trees are what make the answer defensible.
And the layer has to survive what sits beneath it. In a data platform modernization under a live market access platform, 8 legacy data domains were brought through one ETL framework, 143 materialized views moved to automated nightly refresh, and 142 test modules were written against 176 source modules so that a definition could not drift silently. The migration took pricing presentation records from 61.7% resolved to 100% of 38,571 migrated, with the unresolved remainder carried as flagged free text rather than dropped. That is what makes an agent's answer about pricing history something you can stand behind. The case studies describe each of these in more detail, and we have written separately about taking over a legacy pipeline nobody else understands.
A practical starting point for teams planning an agent
You do not need a two-year data programme before an agent can be useful. You need the semantic layer for one workflow. The way we approach it is to start with a landscape assessment: map the source systems, the dependencies, the owners and the definitions behind the ten or so questions the agent will be asked most, and find out where they disagree. That assessment is useful on its own; it tells you how much definition debt you carry and where.
From there, one defined workstream: the curated views, the definitions registry, the lineage and the tests for that workflow, built so the client's own team can run and extend it. The agent goes on top once the layer is stable, which is also the point at which it becomes something a validation team can review rather than something to be nervous about. This is how we scope AI and machine learning work for life sciences clients, and it is why so much of it looks like data engineering.
If you are earlier in the journey, the argument for why the data foundation, not the model, decides what AI can do is in From AI-Ready to Agent-Ready, and the governance side of letting external models touch regulated data is in External AI on Regulated Data. If you have already watched a pilot stall, why healthcare AI gets stuck between the pilot and production covers the pattern.
The decision that matters
Every organisation planning an agent on life sciences data will build a semantic layer. The only choice is whether to build it deliberately, as versioned definitions with owners, tests and lineage, or to let the agent improvise one on every query and discover the disagreements in front of a reviewer. The first is slower to start and faster to trust. The second is the demo that never becomes a tool.
Count the definitions before you count the tokens.