Every AI Vendor Is Building a Knowledge Layer. Few Are Built for Healthcare.

By Connor Bell, Senior AI Platform Engineer

Anyone who’s worked in healthcare operations knows that a member with a PCP attribution gap and two ER visits in 90 days is a care management lead. An application knows it because someone hardcoded the rule. An agent dropped into the warehouse knows neither, so it guesses, confidently.

That’s why every data and AI vendor is now building a knowledge layer (some call it a context layer): one governed place that defines what the data means, so every agent can read from it. Most of these products are built for a customer that doesn’t look like a healthcare organization.

Warehouse-native semantic layers let an agent query your tables and metrics in plain English. They know the warehouse and nothing else. Not the policy PDF, the call transcript, or what utilization management (UM) decided last quarter.

Ontology platforms model the business and the actions you can take in it. Palantir proved the value and the cost: forward-deployed engineers and years of modeling before it pays back.

Agent memory records what an agent did so the next session doesn’t start cold. But it has no shared vocabulary, no real permission model, and no way to turn “the agent did this” into “this is how we work.”

Independent context engines bundle all three and serve any agent. They’re new, the claims are broad, and nobody has run one inside a regulated enterprise with the permissions worked out.

These approaches are converging, with every vendor adding what the others have. In a year the feature lists will match, and the difference will come down to who each product was built for.

Most knowledge layers assume three things: the data is mostly in a warehouse, the data team is the buyer, and the worst outcome is a wrong answer. None of that holds in healthcare.

1. Half of what matters isn’t in the warehouse. It’s in policy documents, prior-auth criteria, appeals letters, call transcripts, contracts, and the heads of people who’ve run UM for 15 years.
2. The data team doesn’t decide. The AI program lead, who answers for ROI, and the CISO, who answers for data leaks, decide what goes to production.
3. The worst outcome is PHI in the wrong place. A prompt, a log, or an agent’s memory, outside the permissions that protected it at the source.

The third point is the one most vendors skip. A knowledge layer pulls meaning out of the system that governs it. Even if no data moves, a claims system’s permissions don’t follow a definition or fact once it’s stored somewhere else.

The usual fixes, like workspace keys, database roles, or leaving authorization to the app, work for an analytics bot. They don’t survive a third-party risk review.

Letting agents query source systems directly has its own problem. Most organizations haven’t seen proof that those systems can handle agent load, so approvals are slow. Teams usually start by building an operational view for the agent, which works but slows every project. Faster options like smart caching, metered connections, and agent crawlers are where much of the engineering work is happening now.

Vocabulary isn’t uniform. A PBM’s definition of a rebate isn’t a regional payer’s, and a 33-member association shares concepts while each member keeps its own data private.

When a vendor says its agent learns from experience, ask what it learns from. It should be what was verified to work, measured in dollars and days, not the agent’s report on its own work.

Andy Fanning, our CEO, has written about why organizational context makes AI faster and more precise with every initiative. This is the engineering side: how to build that context so a healthcare organization can trust it.

The Optura knowledge layer has three parts, and all three run on one permission model.

Knowledge is what the organization knows: facts, corrections, and guidance learned from people, documents, and agent work. Each fact carries its evidence and is visible only to the people allowed to see it, and that scope widens only through review. When a person corrects something, the correction is final. What an organization teaches the system stays with that organization.

Ontology is what that knowledge means: the organization’s vocabulary, seeded with healthcare concepts and grown from what the knowledge actually says, not from a separate modeling project. A person approves every change.

Integrations connect that vocabulary to the systems the organization already runs, so an agent reaches the right record under the right permissions. We don’t rebuild the warehouse; we make it reachable.

None of these parts is new on its own. Running all three on one permission model is what lets us hold to three rules.

One name, several definitions. A claim means one thing to UM, another to claims operations, and another to the actuaries. Forcing one definition on everyone is where enterprise data models stall. So each concept keeps one name, each department keeps its own definition, and the links between them are explicit. A UM agent uses UM’s definition and can see where the actuarial one differs. Who can see each definition follows the same permissions as the data.

“Not allowed” never looks like “nothing found.” Every read goes through one checkpoint that trims results to what the caller can see and says when it did. Otherwise an agent gets an empty result and treats it as the truth.

Nothing automated publishes. Machines propose vocabulary, mappings, and facts. People approve them, and each approval is recorded.

The knowledge layer already runs Optura’s own agents and is now rolling out to customers. The ongoing work is learning how meaning moves through each organization: which corrections stick and where a permission boundary needs to be sharper than anyone wrote down.

Healthcare organizations have more AI ideas than money or engineers to fund them, and every funding decision rests on a baseline. Getting the baseline wrong, means getting the business case wrong, and you only find out after the money is spent.

Take claim processing time. The operations dashboard says 10 minutes. Adjusters say 20, because intake and rework never made it into the column. Every proposal that touches claims is now priced against the wrong number.

A knowledge layer that holds both numbers, the evidence for each, and who approved the answer, lets you fix assumptions before you spend. It also lets you measure as you go. What an agent did is evidence. What worked against the business case becomes guidance. What you chose not to pursue, and why, is knowledge too, so the next team doesn’t start over. That loop between the knowledge layer and the value model is what ties it to ROAI™.

The market has the category right. Agents need a shared, governed understanding of the business. In healthcare, that understanding has to be built on each organization’s own vocabulary, permissions, and results. Judge us, and everyone else, on what you can measure.

If you’re evaluating any of these products, ours included, these questions will tell you whether one holds up in production.

1. Claims operations: evidence and disagreement. Your operations dashboard says a claim takes 10 minutes. Your adjusters say 20. Which number does the agent use, and what does it do when they disagree? A warehouse stores the number, not the reasons.
2. Appeals: knowing what it doesn’t know. Ask for the average turnaround on a type of appeal nobody has measured. The honest answer is “we don’t know yet, and here’s who would.” The dangerous answer is a confident number.
3. Utilization management: learning that spreads. An analyst proves a new prior-auth routing saves four days. A week later, does every agent in the organization know it, or only the one that was involved?
4. Lines of business: shared meaning, separate data. A Medicare Advantage analyst and a commercial analyst ask the same question about the same provider. They should get the same meaning and different data. Most layers give them one or the other.
5. Regulatory audit: provenance as of a date. CMS asks why an agent recommended a coverage decision in March. Can you show what it knew, where each piece came from, and who approved it, as of March?

We hold our own knowledge layer to these five questions, and we expect to be judged on the answers. For healthcare organizations, that means agents that know what its data means, respect who’s allowed to see it, and get measured on what they return. That’s what we’re building at Optura. 

Connor Bell is a Senior AI Platform Engineer at Optura and co-leads the Knowledge Platform team.