Your AI agent does not have a semantic problem. Your tables do.

Most companies have enough data. What their AI lacks is a governed explanation of what words like revenue, active customer, and at risk actually mean.

Most companies do not have a data shortage.

They have customer records, sales transactions, product events, support tickets, contracts, invoices, payments, and forecasts. Years of business activity are already sitting in tables.

Yet an AI agent can look across all of it and still struggle with a question that sounds simple:

Which customers are at risk?

The data may be available. The meaning is not.

Does "at risk" mean a customer who stopped buying? A customer with three open support issues? A contract that expires in 60 days? A sharp drop in product usage? A late invoice? Or some combination of all five?

A person who has worked inside the company for years often knows which meaning applies. They know that the enterprise team uses annual contract value, while the finance team reports recognized revenue. They know that a paused account is not the same as a lost account. They know which exceptions matter.

An agent does not automatically know any of this.

This is why enterprise AI needs more than access to data. It needs semantic understanding: a shared explanation of what the company's language means, where each definition comes from, who owns it, and when it is safe to use.

More data gives AI information. Better meaning gives it understanding.

The problem existed before AI

Imagine that two dashboards show different revenue for the same month.

The first sums completed orders. The second subtracts refunds. Finance uses recognized revenue from the general ledger. Sales uses booked revenue from signed contracts.

Each number may be correct for its purpose. The failure is not arithmetic. The failure is that one familiar word hides several valid business concepts.

Data teams have lived with this problem for years. Analysts ask which table is trusted. Leaders debate why two reports disagree. Engineers add another column called revenue_final_v2 and hope its purpose is obvious.

AI makes the old problem more visible because it removes the human pause.

An experienced analyst may ask, "Do you mean booked or recognized revenue?" An agent may choose a plausible column, write valid SQL, and return a confident answer. The query can be technically perfect and still answer the wrong business question.

That is not mainly a model problem. It is a meaning problem in the data model.

Retrieval is not understanding

Retrieval helps a system find relevant material.

It might find a revenue table, a finance policy, a support dashboard, and a note that mentions churn. That is useful. It gives the model evidence to work with.

But finding five relevant objects does not resolve a disagreement between them.

Retrieval cannot decide by itself:

• which definition is authoritative for this question
• whether an exception applies
• whether a metric changed last quarter
• which team owns the definition
• whether the user is allowed to see the underlying detail
• whether the result is safe to turn into an action

These are semantic and governance questions.

A search result says, "This information may be relevant." A governed definition says, "For this purpose, this is what the term means."

What semantic context actually contains

A semantic layer is sometimes described as friendly names placed over technical tables. That is too small a definition.

Useful semantic context can include the business definition, calculation rule, relationships, allowed filters, known exceptions, owner, source, freshness expectation, access policy, and change history for a concept.

Consider active customer.

A first attempt might say:

SELECT DISTINCT customer_id
FROM orders
WHERE order_date >= CURRENT_DATE() - INTERVAL 90 DAYS

That definition treats any customer with an order in the last 90 days as active.

But what about a new enterprise customer whose contract is signed but whose first order has not arrived? What about a customer with a suspended account? What about a refunded test order? What about a business where the normal buying cycle is six months?

The SQL is easy. Agreement about the business meaning is the hard part.

A useful semantic contract might say:

Now the agent has more than a column. It has a concept it can use and explain.

Start in the gold layer, not in the prompt

It is tempting to solve ambiguity by writing a longer system prompt.

A prompt can remind an agent to use net revenue. It cannot make three teams agree on how net revenue is calculated. It cannot repair duplicate customer identities. It cannot create ownership. It cannot preserve a definition through years of policy changes.

The durable work belongs in the data platform.

In a medallion architecture, bronze preserves source facts and silver cleans and connects them. Gold is where data becomes ready for a business purpose. That makes the gold layer a natural home for stable business concepts such as active customer, qualified opportunity, net revenue, or product adoption.

A clear gold table could expose explicit fields instead of one vague total:

CREATE OR REPLACE VIEW gold.monthly_revenue AS
SELECT
  DATE_TRUNC('month', order_date) AS revenue_month,
  SUM(order_amount) AS gross_revenue,
  SUM(refund_amount) AS refunds,
  SUM(order_amount - refund_amount) AS net_revenue
FROM silver.completed_orders
WHERE is_test_order = FALSE
GROUP BY DATE_TRUNC('month', order_date)

This example does not solve recognized revenue. That may need accounting events and a different owner. The important habit is to keep distinct meanings distinct.

Names should make the choice visible. Documentation should explain the choice. Tests should protect the choice.

You can practise this idea in Databricks Free Edition by building a small bronze, silver, and gold flow, then adding comments to the tables and columns. The medallion architecture lesson and data quality lesson provide the foundation.

A practical example: who is at risk?

Suppose customer support, product, and finance each create an at-risk list.

Support flags customers with two or more severe unresolved cases.

Product flags customers whose weekly usage fell by 40 percent.

Finance flags customers with an invoice more than 30 days late.

None of these teams is wrong. They are measuring different kinds of risk.

The bad solution is to merge the three lists and name the result at_risk_customers without explanation.

The better solution is to preserve the signals and define the decision they support:

SELECT
  customer_id,
  severe_open_cases,
  usage_change_28d_pct,
  overdue_balance,
  contract_end_date,
  CASE
    WHEN severe_open_cases >= 2 THEN 'service_risk'
    WHEN usage_change_28d_pct <= -40 THEN 'adoption_risk'
    WHEN overdue_balance > 0 THEN 'payment_risk'
    WHEN contract_end_date <= CURRENT_DATE() + INTERVAL 60 DAYS THEN 'renewal_risk'
    ELSE 'no_current_signal'
  END AS primary_risk_signal
FROM gold.customer_health

Even this logic is only a starting point.

A domain owner still needs to decide precedence. A data steward needs to record exclusions. The team needs to decide whether one signal is enough for outreach or whether several signals must agree. Historical versions matter because last month's rule may not be today's rule.

This is where Unity Catalog matters. Governance is not only about hiding sensitive columns. It also helps people find the approved asset, understand its lineage, inspect its documentation, and know who is responsible for it.

The exact enterprise governance features available depend on the Databricks workspace and plan. The concept can still be practised in Free Edition: use clear names, comments, small gold tables, simple tests, and a written owner for each metric.

Meaning must have an owner

Many semantic projects fail because they try to make the data team the final authority on every business term.

Data engineers can show how a number is produced. They should not quietly decide what counts as revenue for financial reporting or what makes an account eligible for a retention offer.

A useful division of responsibility is simple.

The business owner defines the intent and exceptions. The data team turns that intent into traceable logic. Governance controls who can change and use it. Consumers can see the definition and challenge it.

Ownership also prevents a glossary from becoming a museum of old definitions.

When refund policy changes, who reviews net revenue? When a product changes its event model, who checks the active-user metric? When a region reorganizes, who updates account ownership rules?

A definition without an owner slowly becomes a guess.

The risk rises when the system can act

A wrong dashboard can mislead a meeting.

A wrong recommendation can waste an employee's time.

A wrong automated action can contact the wrong customer, block a valid payment, change a price, or start an unnecessary escalation.

This is why semantic governance becomes more important as AI moves closer to action.

A strong path looks like this:

1. Show the source and definition behind an answer.
2. Produce a recommendation without changing business state.
3. Validate the recommendation against rules and permissions.
4. Ask for approval when the consequence is meaningful.
5. Perform the action through a controlled system.
6. Measure the outcome and keep an audit trail.

This connects directly to our explainer on AI agent memory versus business state. Semantic context helps an agent interpret a term. The system of record still decides what is actually true and whether a state transition occurred.

The two ideas support each other, but they are not interchangeable.

Watch the explainer

https://youtu.be/ffzKYR-YP3s

Where Genie fits

Databricks is building this direction into its AI products.

Genie One gives business users a conversational way to work with governed enterprise data. Genie Ontology, currently in Public Preview, brings modeled and inferred context together so people and agents can work from a more consistent understanding.

These features require a paid Databricks workspace. The concepts are explained here for understanding.

The important point is that an ontology does not make careful data modeling unnecessary. It depends on authoritative semantics underneath it. Certified data, metric definitions, useful descriptions, permissions, and lineage give the context layer something trustworthy to serve.

Our article on shared context and trusted action follows the next part of the story: how stable meaning can support a conversation, an application, and an agent through the same decision journey.

The Genie Spaces lesson shows how natural-language questions sit on top of structured data and instructions. The AI Gateway and Serving lesson explains the serving and control layer around AI systems. Both are most useful after the underlying business meaning is clear.

For current product details, see the official Databricks documentation for Genie One and Genie Ontology.

The Context Advantage

This is a practical example of The Context Advantage.

Models keep improving. Their general knowledge becomes easier for every company to access. Your company's language does not.

A competitor cannot easily copy why your finance team recognizes revenue in a particular way, which product signals predict renewal, how regional ownership works, or which exceptions matter for regulated customers.

That operating knowledge is context. When it is made explicit and governed, it becomes useful infrastructure.

The 4Cs help explain the full picture:

• Context gives the model the right business meaning.
• Control decides which definitions, data, and actions are allowed.
• Cost helps the team apply deeper reasoning where it creates value.
• Choice keeps models and tools replaceable while company knowledge remains durable.

Context without control can spread a wrong definition quickly. Control without context can produce a safe system that is not useful. Strong enterprise AI needs both.

Build one semantic contract this week

Do not begin by trying to model the whole company.

Choose one term that creates repeated confusion. Revenue, active customer, churn, qualified lead, on-time delivery, or resolved case are good candidates.

Then work through a small sequence:

1. Collect the definitions already used by different teams.
2. Name each distinct concept instead of forcing false agreement.
3. Choose the definition for one clear business purpose.
4. Record its formula, grain, sources, exclusions, owner, and review date.
5. Build it into a business-ready gold table or view.
6. Add data quality checks for its important assumptions.
7. Test real questions, including ambiguous ones.
8. Require the AI to show which definition it used.

That last step matters.

A trustworthy answer should not only provide a number. It should make the interpretation inspectable: "I used net revenue after refunds, based on the finance-approved monthly revenue view."

The agent does not need to expose every technical detail. It does need to make consequential meaning visible.

Company language is infrastructure

The semantic layer is not a final coat of polish for an AI application.

It is part of the foundation.

When definitions live only in people's heads, every dashboard, app, copilot, and agent must guess. When those definitions become governed data products, the same meaning can travel across every interface.

That work may look less impressive than a new model demo. It is also the work that makes the demo useful six months later.

Data engineering has always been about more than moving records. It turns raw events into shared understanding. Enterprise AI makes that responsibility clearer.

More data can help an agent find an answer.

Better meaning helps the organization trust the decision that follows.