Ontology, Context and Semantic Data Layers

Most enterprise AI failures are described as hallucination problems.

The model made something up. The answer was not grounded. The agent pulled the wrong document, joined the wrong table, or interpreted the customer incorrectly.

That diagnosis is usually too shallow.

The deeper problem is not that the agent lacked facts. It lacked business meaning.

It did not know what the company means by revenue. It did not know whether "customer" means the legal entity, the billing account, the end user, or the parent account. It did not know which source wins when Salesforce disagrees with the warehouse. It did not know whether churn means gross logo churn, net revenue retention loss, support-driven attrition, or something the CFO defined three board decks ago and never wrote down.

So it did what models do when meaning is underspecified.

It guessed.

That is the real bottleneck in enterprise AI. Not intelligence in the abstract. Meaning in the institution.

If agents are going to run real workflows, companies need two layers that most AI demos quietly skip.

Ontology is what the business means.

The context layer is how agents reliably access and use that meaning.

The first is semantic. The second is operational. Together, they are the beginning of the semantic data layer every serious AI-native company will need.

Ontology is the business made explicit

Ontology sounds academic. In practice, it is brutally concrete.

It is the agreed definition of the things a business runs on: customers, products, contracts, invoices, accounts, renewals, territories, entitlements, opportunities, usage, margin, risk, and revenue.

It includes the metrics and the rules behind them. ARR. NRR. Gross retention. Activation. Pipeline. Expansion. Gross margin. Cost to serve. Forecast category. Strategic account. At-risk renewal.

It includes relationships. A customer belongs to a parent account. A contract covers a set of products. A support case touches an entitlement. A renewal depends on usage, sentiment, open issues, price history, and executive sponsorship.

It includes synonyms and business language. One team says bookings. Another says committed ARR. One system says account. Another says organization. One analyst says usage. Another means consumption, seats, API calls, or active workflows.

And it includes authority. If the CRM, billing system, product database, support platform, and data warehouse disagree, which one wins for which question?

That last part matters more than most people admit.

A company does not have one reality. It has many operational realities held together by meetings, dashboards, Slack threads, spreadsheet exceptions, tribal knowledge, and the quiet heroism of people who know where the bodies are buried.

Agents cannot inherit that by osmosis.

They need it encoded.

This is why Baris Gultekin's conversation on Masters of Automation matters. His point that there is no AI strategy without a data strategy is not a slogan. It is an architecture claim.

Enterprise AI does not become trustworthy because a model has read the internet. It becomes trustworthy when the model can reason against the company's own definitions, permissions, sources, and workflows.

That is ontology.

Not an abstract knowledge graph for its own sake. The operating vocabulary of the company, made explicit enough for machines to use and humans to challenge.

The context layer is the machinery around meaning

Ontology defines what the business means. It does not, by itself, make agents useful.

For that, you need the context layer.

The context layer is the broader operating system around meaning. It discovers or ingests context. It applies permissions. It retrieves the right evidence. It preserves provenance. It serves the relevant slice to an agent. It evaluates whether the answer or action was good. It governs updates over time.

Ontology says: this is net revenue.

The context layer says: this user is allowed to ask about these accounts, the authoritative definition lives here, the current answer requires these tables and these contracts, the evidence came from these rows and documents, the agent used this version of the metric, and the result passed or failed these checks.

That distinction is the whole game.

Too many teams collapse ontology and context into one fuzzy pile called "knowledge." They throw documents into a vector database, wire up retrieval, and call it an enterprise brain.

That can work for low-stakes search. It does not work for high-stakes operations.

A vector index can retrieve similar text. It cannot, by itself, decide which business definition is authoritative. It cannot know whether a metric is additive, whether a user has access, whether an answer needs row-level evidence, whether a policy changed last week, or whether a workflow should stop because confidence is low.

RAG was a major step because it gave models access to external knowledge instead of forcing every fact to live inside model weights. The original retrieval-augmented generation paper framed that move clearly: combine a language model with an external memory that can be retrieved at inference time.

But enterprise RAG is not just retrieval.

It is semantic retrieval under permission, with provenance, evaluation, and governance.

That is a much harder sentence, which is why fewer demos say it out loud.

Semantic data layer

Ontology defines the meaning. Semantic views and models map that meaning to data. The context layer governs what agents can retrieve, cite, evaluate, and update.

Business reality

Inputs

• Systems of record
• Documents and policies
• Workflow events
• Human judgment

Ontology

The agreed vocabulary of the business: what entities, metrics, rules, relationships, and sources mean.

EntitiesMetricsRelationshipsRulesAuthority

Semantic views and models

Mapping

Business concepts are mapped to tables, documents, APIs, workflow systems, and verified examples.

Context layer

The runtime around meaning

The layer that decides what an agent is allowed to know, what it should retrieve, how it should cite evidence, and how the system learns from outcomes.

Permissions

Who can ask, see, and act.

Retrieval

Which evidence belongs in scope.

Provenance

Where the answer came from.

Evaluation

Whether the action worked.

Governance

How meaning changes safely.

Agent interfaces

Use

• RAG answers
• Text-to-SQL
• Workflow agents
• Agent handoffs

Feedback loop

Learn

Outcomes become evaluation cases. Evaluation exposes missing context. Missing context updates the ontology, rules, permissions, and verified examples.

The semantic layer is becoming real

This is no longer only a whiteboard pattern.

One useful implementation signal is Snowflake Semantic Views: schema-level objects for storing semantic business concepts directly in the database. The product detail matters less than the direction. Business meaning is moving into a machine-usable layer closer to the systems agents actually query.

The same pattern shows up in Cortex Analyst, where semantic models help turn natural-language questions into SQL against governed data. The docs are explicit about the problem generic text-to-SQL systems face when they see only raw schemas: schemas do not carry enough business process definition, metric logic, or relationship knowledge.

That is the key.

Raw schema is not enough.

A sales leader asks for net revenue by region. The database stores columns, joins, facts, dates, product codes, discounts, invoices, and territory mappings.

The semantic layer translates between those worlds.

A table can tell an agent that a column exists. It cannot tell the agent why the column matters, when to use it, whether it is stale, what it means to the finance team, how it rolls up, or which business exception breaks the obvious join.

The CREATE SEMANTIC VIEW syntax is revealing because it is not just "describe this table better." It includes logical tables, relationships, facts, dimensions, metrics, synonyms, custom SQL generation instructions, question categorization instructions, verified queries, tags, and public/private access modifiers.

That is not documentation in the old sense.

It is machine-usable business meaning.

Text-to-SQL is the obvious case. Workflows are the bigger one.

Text-to-SQL is the cleanest place to see the pattern because the failure is visible.

A user asks, "What is expansion ARR for enterprise customers in EMEA last quarter?"

The agent has to understand expansion, ARR, enterprise, EMEA, quarter, customer, and the relevant source tables. It has to know the metric formula, the region logic, the customer segmentation rule, and the right time boundary. It has to generate SQL that respects access controls and returns something verifiable.

Without a semantic layer, the agent is guessing across a swamp of table names.

With a semantic layer, it is reasoning over business concepts mapped to physical data.

But analytics is only the first act.

The same pattern applies to business workflows.

Imagine an enterprise renewal agent. Its job is not merely to summarize account history. It needs to know what a customer is, which contract is active, which products are entitled, which support cases matter, which usage metrics signal value, which executive sponsor owns the relationship, which commercial terms are sensitive, and which actions it is allowed to take.

That is ontology.

Then it needs to retrieve the right account data, respect role permissions, cite the evidence, distinguish fresh facts from stale notes, draft the renewal plan, route the risky case to a human, record the outcome, and update the playbook when the strategy changes.

That is the context layer.

Now repeat the pattern for finance close, customer support, legal intake, procurement, security triage, clinical operations, insurance claims, supply chain exceptions, and sales forecasting.

Every serious agentic workflow has the same hidden structure.

First, the company has to define what things mean.

Then the runtime has to decide what the agent can know, what it can do, what evidence it must show, and how the system learns from the result.

This is why "skills are the new apps" is such a useful frame from the Baris episode. A skill is not just an instruction file. At enterprise scale, a skill is a packaged capability sitting on top of meaning, permissions, tools, evidence, and evaluation.

Without the semantic layer underneath, skills become clever macros.

With it, they become reusable business capabilities.

Natural language is not enough

There is a tempting counterargument here.

If models keep getting better, maybe they will infer the ontology from the mess. Maybe the whole point of natural language interfaces is that humans no longer need to formalize everything.

This is half true and fully dangerous.

Better models will infer more. They will read tables, parse documents, inspect examples, ask clarifying questions, and recover a surprising amount of structure from messy environments. That is real.

But inference is not authority.

An agent can infer what "active customer" probably means. It cannot decide what the company means when revenue recognition, sales compensation, customer success coverage, and board reporting each depend on the answer.

That distinction is where Stephen Wolfram's conversation becomes useful. His recurring contrast between language-like reasoning and formal computation is not just a philosophical point. It is a practical warning.

Natural language is powerful because it is flexible. Business operations are hard because they need precision.

Agents need both.

They need the flexibility of language to understand intent, handle ambiguity, and collaborate with people. But they also need formalized definitions, deterministic rules, verified queries, tests, policies, and system boundaries.

The future is not natural language replacing structure.

It is natural language operating through structure.

That is a quieter claim than the usual AI interface story, but it is much closer to how durable systems get built.

Provenance is not optional

Once agents start acting, provenance stops being a nice feature.

It becomes the basis of trust.

A human analyst can say, "I pulled this from the billing table, checked it against the contract, and excluded one acquisition-related anomaly." That statement carries operational meaning. It tells the listener where the answer came from and how much judgment went into it.

Agents need the same discipline.

For every meaningful answer or action, the system should know: which sources were used, which definitions applied, which permissions were checked, which tool calls ran, which evidence was shown, which assumptions were made, and which version of the ontology was active.

This is where the context layer connects to the broader agent infrastructure conversation.

Ramesh Raskar's Agent Zero and NANDA work pushes on trust, identity, certification, interoperability, and attestation in a world of many agents. That argument applies inside the enterprise too.

When multiple agents collaborate across systems, you need to know not only what they did, but why they were allowed to do it and which evidence they relied on.

The Model Context Protocol is one emerging pattern for connecting AI applications to data sources, tools, and workflows. It does not solve enterprise semantics by itself. But it points toward the same operating reality: agents need standardized ways to access external systems, and those connections need governance.

Context without provenance is just memory with confidence.

That is not enough for work that touches customers, money, contracts, health, security, or reputation.

Evaluation belongs inside the context layer

Most companies still evaluate AI like they evaluate a demo.

Did the answer look good? Did the executive like the prototype? Did the chatbot feel impressive in the meeting?

That is theater.

For agentic systems, evaluation has to move closer to the workflow.

In analytics, that means verified questions and expected SQL. Did the system choose the right metric? Did it join the right entities? Did it respect time boundaries? Did it aggregate correctly? Did it cite the result?

In RAG, it means retrieval quality, source relevance, citation faithfulness, freshness, permission correctness, and answer quality.

In workflows, it means outcome quality. Did the agent resolve the support case? Reduce escalation? Improve forecast accuracy? Shorten cycle time? Catch the contract risk? Route the edge case to the right person?

Evaluation is not separate from context. It is how the context layer learns.

If an agent uses the wrong definition of churn, the fix is not only a better prompt. The fix may be an ontology update, a verified query, a permission adjustment, a retrieval rule, a new evaluation case, or a clearer source-of-truth policy.

This is how companies stop treating AI errors as one-off model failures and start treating them as system feedback.

The best organizations will not merely deploy agents. They will build loops that make the agents and the institution smarter together.

The semantic data layer is the new operating leverage

There is a reason this all sounds less glamorous than the model discourse.

Models are clean objects. They have names, benchmarks, launches, and leaderboards.

Semantic data layers are institutional work. They require arguments between finance and sales. They expose messy ownership. They force teams to define metrics they have been happily interpreting differently for years. They make politics visible.

That is exactly why they matter.

The hard part of enterprise AI is not getting a model to produce fluent text. That is increasingly cheap.

The hard part is getting the system to know what the company means, act only where it has permission, show its work, improve from outcomes, and stay aligned as the business changes.

That is not a chatbot.

It is an operating layer.

The companies that build it will have a compounding advantage because every agent, workflow, dashboard, analysis, support process, planning cycle, and executive decision can draw from the same governed meaning.

The companies that do not will keep rediscovering the same failure in different costumes.

The sales agent will use one definition of customer health. The finance agent will use another definition of revenue. The support agent will miss the contractual nuance. The analytics assistant will generate plausible SQL over the wrong join. The executive chatbot will summarize conflicting dashboards as if they were one coherent truth.

None of that will look like a grand architectural failure in the moment.

It will look like small errors, low trust, human rework, and pilots that never quite graduate.

That is how AI theater dies: not loudly, but by failing to become operating infrastructure.

What I would build first

The practical path is not to boil the ocean.

Start with one high-value domain where meaning already matters and mistakes are expensive. Revenue, renewals, support, finance close, claims, risk, or pipeline.

Define the core business entities. Write down the metrics and their formulas. Name the authoritative sources. Map the relationships. Capture synonyms. Specify access rules. Identify the questions and workflows agents should handle. Create verified examples. Decide what evidence must be shown. Build evaluation cases before scaling.

Then put agents on top of that layer.

Not the other way around.

This is the unglamorous order that serious systems require. Meaning first. Context second. Agents third. Autonomy last.

Most companies will try to skip to the last step because it makes for the better demo.

The better operators will do the boring thing that compounds.

They will make the business legible to machines.

The real claim

Ontology is not a data governance side quest. It is the semantic core of the agentic enterprise.

The context layer is not a nicer search box. It is the runtime that lets agents use meaning responsibly.

Together, they become the semantic data layer: the place where institutional knowledge stops living only in people, slides, dashboards, and folklore, and starts becoming an executable asset.

That is the durable enterprise AI advantage.

Not the chatbot. Not the prompt library. Not the model wrapper.

The advantage is the company that can turn its own meaning into governed machine action.

Everything else is an interface waiting for a foundation.

On Masters of Automation, I keep returning to the same question: what happens when intelligence becomes abundant, but trust, meaning, and responsibility still have to be designed? The answer, in the enterprise, starts here. Make the business legible to machines without making people disappear from judgment. If that is the future you want to reason about from first principles, the newsletter is where it continues. all signal, no spam.