Data Gets AI Started. Context Gets It to Production.

Every enterprise AI team has lived the same week. On Friday afternoon, someone connects a capable model to a clean set of warehouse tables, writes a careful prompt, and asks a question in plain English. The answer comes back in seconds, correct, well formatted, and impressive. The room is delighted. A pilot is approved before the weekend.

On Monday morning, the pilot meets the business. A sales leader asks for churn and gets a number that disagrees with the board deck. A finance analyst asks about revenue and the agent includes bookings that have not been recognised. A support manager asks the agent to issue a goodwill credit, and nobody can say whether it should be allowed to. By Wednesday, the pilot is in a holding pattern that looks a lot like the last three.

Nothing was wrong with the data. The tables were clean, tested, and documented. What was missing was everything the data does not say: which definition of churn the board uses, which revenue counts, which actions need a human, and why the exception for the largest customer exists. Data got the demo started. Context is what would have got it to production.

This is the oldest lesson in the book, stated in Chapter 1: when the model is smart but the meaning is missing, the answer is fluent and wrong. It is also why Chapter 3 insists that smart models still need smart systems.

For ten years, the industry message was simple: get your data in order and AI will follow. That message was right for dashboards and predictive models, because a human analyst stood between the data and the decision, supplying the meaning in their head. The analyst knew which customers to exclude, which quarter had the accounting change, and which metric the executive team actually trusted.

Agents remove that human from the middle. The model now reads the data and acts on it directly, which means every piece of meaning the analyst used to supply silently must now be supplied explicitly. That explicit meaning is context. Chapter 5 calls it the new data layer, sitting above storage and compute.

The distinction matters because the two layers are built and maintained differently. Data is captured by systems: transactions, events, logs. Context is held by people: definitions agreed in meetings, policies written by legal, exceptions approved by a director, lessons learned from an incident. Chapter 8 puts it plainly: catalogs describe data; memory describes meaning. You can have a perfect catalog and no memory at all.

When a pilot stalls, teams usually blame the model and try a bigger one. In practice, the stall almost always sits in one of four gaps, and none of them is closed by a smarter model.

**The semantic gap.** Two clean tables can disagree about what a word means. Marketing counts a customer at sign-up; finance counts a customer at first payment; the board counts only accounts above a revenue threshold. An agent given all three tables will pick one, confidently, and it will often pick the wrong one for the person asking. Chapter 6 shows why naive retrieval cannot fix this, and Chapter 7 explains semantic layers, ontologies, and governed metrics without jargon.

**The memory gap.** Data records what happened; it rarely records why. Why was the discount extended to one region? Why was a product line excluded from forecasts last year? An agent without that history repeats decisions the organisation already learned to avoid. Chapter 10 argues that this accumulated why is the real moat, because no competitor and no model vendor can download it.

**The action gap.** Permission to read a record is not permission to change it. The governance most enterprises have was built for humans clicking buttons, and it answers the question who can see. Agents need an answer to a harder question: what may this agent do, at what size, and with whose approval. Chapter 13 and Chapter 14 make the shift from access control to action control.

**The drift gap.** Context written once decays. Products are renamed, policies change, a definition is quietly updated in one team and not another. The agent keeps citing the old version with total confidence. Chapter 11 treats context as a living layer with owners, versions, and review cycles, exactly like code.

Look at what a typical prototype contains: a model, a prompt, and some tables. Three layers. It works because the person building it is also the person testing it, and they quietly supply all the missing context themselves when they choose which questions to ask.

A production system cannot rely on that. It needs a context layer that holds definitions and history, guardrails that bound what the agent can do, an evaluation set that proves quality before and after every change, and an audit trail that can explain any action to a regulator or a customer. Five layers at minimum, and the model is the only one that came for free.

This is why so many teams describe the move to production as starting over. They are not starting over. They are building the four layers the demo never needed. Chapter 30 lays these out as a nine-step reference architecture for a trusted agent, and it is worth reading before the pilot rather than after it stalls.

Once a team accepts that context matters, the instinct is to put every document into a vector index and let the agent search it. That is a start, not a strategy. Enterprise corpora are full of near-duplicates, outdated versions, and exact identifiers such as policy numbers and product codes that semantic search handles badly.

Chapter 35 covers what production retrieval actually requires: chunking that respects document structure, hybrid search that combines keyword and semantic matching, fusion of the two ranked lists, and a reranker that reorders candidates before anything reaches the model. Above all, it requires measurement. If you cannot say what fraction of the right evidence reached the model, you cannot say whether a change helped.

The governance point is that retrieval quality is a context question, not an infrastructure detail. The best retrieval pipeline in the world will faithfully surface a deprecated policy if nobody marked it deprecated. Mechanics and meaning have to be built together.

Prototypes are cheap because they are small. Production is expensive in ways that rarely appear on the first estimate: oversized prompts stuffed with every document just in case, retries when the answer looks wrong, long conversations that drag their entire history into every call, and the human time spent checking answers nobody trusts.

Context is the lever that controls almost all of that cost. A precise context layer means smaller, more relevant prompts. Clear definitions mean fewer wrong answers to retry or review. Chapter 18 traces where the money actually goes, Chapter 20 asks teams to design for a budget from the first day, and Chapter 36 treats the context window itself as a budget, with explicit allocations and compaction rules for long-running agents.

The metric that survives production is cost per correct outcome. A cheap answer that is wrong is the most expensive answer in the system, because someone has to find it, fix it, and explain it.

A useful way to make all of this concrete is to treat the path to production as four gates. An agent does not go live until it passes each one, and each has a named owner.

**The meaning gate.** Every business term the agent relies on has one governed definition, an owner, and a version. If two teams disagree, the disagreement is resolved before launch, not discovered by a customer.

**The permission gate.** Every action the agent can take is listed, bounded by size and rate, and mapped to an approval rule. Chapter 15 covers guardrails and audit trails; Chapter 17 is explicit about when a human must stay in the loop.

**The economics gate.** The team can state the expected cost per correct outcome and has a budget alert that fires before the finance team notices. Chapter 19 helps decide which tasks deserve the most capable model and which do not.

**The evaluation gate.** A representative test set, written with the business rather than by the engineers alone, passes at an agreed threshold, and is re-run on every change to the model, the prompt, or the context. Chapter 16 frames this as designed trust: confidence earned with evidence.

If context is what gets AI to production, someone has to own it. In most organisations that someone is emerging from the data team. Data engineers already understand lineage, quality, testing, and ownership. The shift is from making data available to making meaning available to machines.

Chapter 9 names the role: the Context Engineer, who owns definitions, retrieval quality, permissions, and evaluations for the agents a company runs. Chapter 26 describes how the data professional's role evolves, and Chapter 29 lays out a roadmap for beginners through senior practitioners.

This is good news for data people. The skills that made a strong data engineer — rigour about definitions, suspicion of silent changes, patience with stakeholders — are exactly the skills that take agents to production. If you are preparing formally, the practice exams for the Databricks Context Engineer Associate certification map every domain to the chapters that teach it.

None of this requires a multi-year programme. Chapter 31 describes building a first context layer in eight weeks, and the shape is simple enough to start this month.

**Weeks one and two:** pick one agent and one workflow. List every business term it touches and every action it can take. Find the owner of each.

**Weeks three and four:** write governed definitions for those terms, with version history and the reasons behind each rule. Mark deprecated documents so retrieval stops surfacing them.

**Weeks five and six:** build the evaluation set with the business, wire up hybrid retrieval and reranking, and set action limits and approval rules.

**Weeks seven and eight:** run the four gates, set a budget alert, launch to a small group, and schedule the first context review for thirty days later. The review is not optional; it is what keeps the drift gap closed.

Then do it again for the next agent. The second one is faster, because most of the definitions now already exist. That compounding is the whole point: data gets every agent started, but the context layer is what makes each new agent cheaper and safer than the last.