A system that doesn't know what it doesn't know will always sound certain.
In Brief
- The gap. Roughly a third of agentic analytics projects are said to be in production, but that number oversells what is actually running. Most reach one brand and stop.
- The real constraint. It is not the model. It is domain knowledge, a system that understands how pharma commercial operations work, not just how to read a pharma table.
- How you get there. Build that knowledge once and reuse it, then add the few engineering choices that keep the system honest in front of real users.
The industry has settled on a comforting figure: about a third of agentic analytics projects have reached production. Look closer and the number thins out. In most cases "production" means one brand and one domain, pre-computed metrics standing in for real questions, analysts rather than decision-makers using it, and a year of setup to get there. That is a long way from a system that reasons across a full commercial portfolio for the people actually making calls. The distance between the two is not closed by a bigger model. It is closed by the unglamorous work around it, and most of all by knowledge of the business itself.
A third in production oversells what is running
The reason the gap stays hidden is that a single-brand pilot and a portfolio-wide system look identical in a demo. Both answer questions fluently on stage. With AI analytics for pharma, the difference only shows up under real conditions, when the questions get messy, the data spans a dozen domains, and an executive needs to trust the answer enough to act on it without checking it first. Getting from the demo to that point is where almost every project stalls.
The model is the easy part
Here is what most people miss. A general-purpose AI can read data. It can parse a table, compute a trend, describe a distribution. What it cannot do is understand the business the data describes.
Ask a general tool how a brand did last quarter, and it finds a column of units and adds them up. In pharma commercial data that number means little on its own. Are those total prescriptions or only new ones? Do they include free samples? Is revenue gross, or net of the rebates and copay support that can move it by a third? Does "the brand" include the second dosage form sitting in another table under a different code? Someone who knows pharma asks all of that before trusting the number. A system without that knowledge does not know to ask, so it returns a clean, confident, wrong answer.
That is the real constraint. Not how powerful the model is, but how much it understands about brands and field teams, territories and market access, patient journeys and payer dynamics, and how they interact. In pharma commercial analytics, domain knowledge is what separates an analyst you rely on from one you double-check.
Domain knowledge, built once and reused
So the practical question is how a system gets that knowledge, and how fast.
The knowledge lives in a semantic layer, the encoded understanding of how a business works: what each metric really means, which entities connect to which, the rules that turn a raw column into a business concept. Most semantic layers were built for dashboards, a static list of definitions so everyone uses the same formula. That is enough to display a number. It is not enough to reason, which needs the layer to hold how the parts of the business relate, not just what each metric is called.
Building that from scratch for every client is what sinks most projects, since it takes the better part of a year before anyone sees value. The alternative is to build it once and reuse it. A semantic layer distilled from thousands of pharma commercial practitioners lets a system start each engagement already fluent in the business rather than learning it from a blank slate.
Three more things that separate a demo from production
Domain knowledge sets the foundation. Three further choices decide whether the system holds up once real people use it.
The first is behaving like a good analyst rather than an eager one, asking when a request is vague and saying plainly when something is beyond what the data can answer. A system that guesses and sounds sure loses trust the first time it is caught. One that asks first keeps it.
The second is fixing mistakes fast. With users asking hundreds of questions a day, corrections have to land in hours, not release cycles, which means the people running the system can correct it directly instead of waiting on an engineering queue. That is what lets it improve while people use it, rather than losing them.
The third is leaving the data where it is. The system runs on top of the warehouse the client already has, so nothing moves. That is not just convenience. It turns a compliance review that can stall a project for a year into something a team can actually clear.
What this looks like in production
None of this is hypothetical. This approach runs in production today for a global specialty biopharma, live across two brands and five domains, asking multi-part questions of live data. It answers benchmark tests with better than ninety-five percent accuracy with no hallucinations observed in the responses shown to users. A new brand or domain comes online in four to six weeks, not the year the old approach demanded.
That did not come from one breakthrough. It came from treating the model as the necessary part but never the hard part, and building the four things around it that turn a convincing demo into pharma commercial analytics that holds up across a real portfolio. For any commercial organization weighing this shift, that is the question to put to a vendor. Not how capable your model is, but how much of the hard work around it you have already done.
This piece draws on ideas presented at Axtria Ignite 2026.
FAQs
Author details
