Enterprise AI rarely fails because of the model. It stalls because the context around the data was never engineered. Here is what that context actually is, and how to start building it.
A data team we know connected an AI assistant to their sales database on a Tuesday afternoon. By four o'clock, the assistant was answering questions about revenue. Charts appeared. The room was impressed. Leadership approved the project on the spot.
Six months later, the project was still not in production.
Nothing was wrong with the model. It was the same model anyone can rent. What was missing was everything around the data. Nobody had agreed on which definition of revenue the assistant should use. Nobody had decided which rows it was allowed to see. Nobody had named the person to call when two reports disagreed. And nobody had drawn the line between answers the assistant could act on and answers that needed a human first.
This is the pattern behind most enterprise AI stalls. Data starts the project. Context ships it.
Data answers one question: what exists. Rows in a table. Events in a stream. Files in a volume. It is the raw material, and most enterprises have more of it than they can read.
Context answers a different question: what to do. Which definition applies here. Who is allowed to see this number. What this column means in this business. Whether the agent may act on the answer, or must stop and ask.
An AI system needs both. Data without context is a warehouse full of unlabeled boxes. The model can open every box, but it cannot tell you which ones matter, which ones are current, or which ones it is allowed to ship.
Here is the smallest example we know, and it happens everywhere.
Ask three systems in the same company for last quarter's revenue. The sales dashboard reports bookings: everything signed. The billing system reports invoices: everything sent. The finance ledger reports recognized revenue: everything earned under accounting rules. Three honest systems. Three different numbers.
A human analyst knows which one the board means. An AI agent does not. Ask it for revenue and it will pick one definition, confidently, without telling you there were three. The answer looks right. It may even be formatted beautifully. It is still a guess.
One approved definition, stored where systems can read it, turns that guess into a reliable answer. This is why we keep saying that semantic understanding is the layer agents actually read.
Context sounds abstract until you list it. In practice it is a small set of very concrete things.
Business definitions. The agreed meaning of revenue, active customer, churn, and a dozen other words the business uses daily. One definition each, written down, owned by someone.
Ownership. Every important table has a name next to it. When the agent finds something strange, it knows which team to route the question to.
Policies and permissions. Who may see salaries. Who may see customer records. Which regions may be joined with which. The same rules your people follow, readable by machines.
Data quality state. Which tables are fresh, which are stale, which failed their checks this morning. An agent that knows a table is stale can say so instead of answering from it.
Decision history. What was decided last time this situation came up, and why. Without it, every agent starts from zero and contradicts the agent that ran yesterday.
Action boundaries. What the agent may do with an answer. Read only. Draft for approval. Or act within limits, with everything logged.
None of this is exotic. Most of it already exists in wikis, tickets, and people's heads. The work is moving it somewhere a machine can read.
The demo works because the person running it carries the context in their head. They picked the dataset. They know which definition of revenue the room expects. They have access to everything, so permission questions never come up. And nothing the demo does has consequences, so boundaries never come up either.
Production removes all four comforts. Many people ask questions, each with a different definition in mind. Permissions apply. Tables are stale some mornings. Answers have consequences.
The model did not change between the demo and production. The context did. That is the whole story.
The first instinct is to fix this with a longer prompt. Paste the revenue definition into the system prompt. Add a paragraph about permissions. It works for a week.
Then the definition changes, and one of the twelve places you pasted it does not get updated. A second agent is built by a different team with a slightly different copy. A third team fine tunes a model with last year's policy. Each agent is now reading a different version of the truth, and every answer is a small argument waiting to happen.
A prompt is a note you hand to the model once. Infrastructure is versioned, governed, tested, and shared. Definitions belong in governed tables and catalogs, with owners and history. Permissions belong in the same system that enforces them for people. When context lives there, every agent reads the same truth, and updating it once updates it everywhere.
Here is the strategic part, and it is worth saying plainly.
The model is rented. Your competitors can rent the same one. The data matters, but data alone does not tell anyone what to do with it. The layer you truly own is context: your definitions, your policies, your decision history, your boundaries. It took your business years to learn these things. No vendor can sell them to anyone else.
This is the argument at the heart of The Context Advantage: Context makes the work understandable, Control makes action safe, Cost keeps the system sustainable, and Choice prevents unnecessary lock in. The companion book goes deeper on all four.
Teams that treat context as a moat build it like one. Teams that treat it as an afterthought keep rebuilding demos.
On Databricks, this is not a new system to buy. It is the system you already have, used on purpose.
Unity Catalog holds your tables, and it also holds ownership, permissions, tags, and lineage. That is context in machine readable form. A metric definition table is context. A Genie space with clear instructions and the right tables is context packaged for an analyst, which is why Genie behaves like an analyst you onboard, not a search box you install.
When a second agent joins, it reads the same catalog instead of being briefed again in a prompt. When a definition changes, it changes once. When an agent oversteps, the same permissions that govern people govern it. We explored the system level version of this in enterprise context as the missing layer for AI agents and in one business language across every AI assistant.
This is also why context engineering is becoming a real job skill for data engineers. The people who already model data, define quality rules, and manage access are the people best placed to engineer context. It is the same craft, pointed at a new reader. Once the context exists, the remaining work is deciding what the agent needs, which tools it can use, and when it should stop and ask you.
Bring these six questions to the next review meeting. They fit on one slide.
If a project answers all six calmly, it is ready. If it answers none, it is a demo with a budget.
The stack that ships has four layers. The model, which you rent. The data, which tells you what exists. The meaning, which tells you what it is for. And the control, which keeps action safe.
Most budgets flow to the first layer. Most failures come from the missing third and fourth. The most valuable layer in the stack is the one you cannot buy: the context you build once and share with every agent you will ever run.
You can feel the revenue trap in ten minutes. Everything below runs in Databricks Free Edition.
This is the data layer. It says what exists, nothing more.
CREATE OR REPLACE TABLE workspace.default.context_lab_orders (
order_id INT,
status STRING,
amount DECIMAL(10,2),
ordered_at TIMESTAMP
);
INSERT INTO workspace.default.context_lab_orders VALUES
(1, 'booked', 120.00, TIMESTAMP '2026-10-01 09:00:00'),
(2, 'cancelled', 120.00, TIMESTAMP '2026-10-01 09:05:00'),
(3, 'booked', 80.00, TIMESTAMP '2026-10-02 11:30:00'),
(4, 'refunded', 80.00, TIMESTAMP '2026-10-03 14:10:00'),
(5, 'booked', 200.00, TIMESTAMP '2026-10-04 16:45:00');-- The naive answer: sum everything that exists
SELECT SUM(amount) AS naive_revenue
FROM workspace.default.context_lab_orders;The result is 600.00. It includes a cancelled order and a refunded one.
-- The approved answer: booked orders only
SELECT SUM(amount) AS approved_revenue
FROM workspace.default.context_lab_orders
WHERE status = 'booked';The result is 400.00. Same table. Different truth. An agent with no context has no way to know which one your board means.
CREATE OR REPLACE TABLE workspace.default.metric_definitions (
metric STRING,
approved_definition STRING,
rule_sql STRING,
owner STRING
);
INSERT INTO workspace.default.metric_definitions VALUES
(
'revenue',
'Sum of amount for orders with status booked. Cancelled and refunded orders are excluded.',
'status = ''booked'' ',
'finance-data@example.com'
);This small table is context as infrastructure. It has a definition, a rule, and an owner. A person can read it. So can an agent.
CREATE OR REPLACE VIEW workspace.default.v_revenue AS
SELECT SUM(amount) AS revenue
FROM workspace.default.context_lab_orders
WHERE status = 'booked';Now anything in the workspace, a dashboard, a notebook, or a Genie space, can answer from the same definition instead of guessing. When finance changes the rule, you update one view and one row, and every consumer moves together.
That is the whole idea at the smallest possible scale. Data said what existed. Context said what to do with it. The agent did not get smarter. The system around it did.
In the book, the natural next chapters are Chapter 20: Data Governance and Security for ownership and permissions, Chapter 13: Data Quality Engineering for freshness and validation state, and Chapter 20.5: Genie Spaces for packaging context where analysts actually ask questions. When your definitions feed pipelines, Chapter 14: Change Data Capture keeps them current.
If this way of thinking resonates, the Context Advantage hub collects the essays grouped by the four Cs, and the future of data to decisions is autonomous shows where this road leads once context is in place.
New to BricksNotes? The first three chapters are free, and the full book teaches the data engineering foundation this article builds on.