Context engineering is becoming a real job skill for data engineers

The model is not the moat. The layer around it is.

A friend of mine runs a small analytics team. Last month they wired an AI agent into their warehouse so anyone could ask questions in plain English.

On day two, someone asked a simple question. How many active customers do we have?

The agent answered in three seconds. Confident. Clean. Wrong.

It had found a table named customers that nobody had used since a migration two years earlier. Nothing in the system had told it which table was the truth. Nobody had decided what the agent was allowed to know.

The model was fine. The context was not.

Prompting was never the hard part

For the last couple of years, the conversation around AI has been about prompts. Write a better prompt, get a better answer.

That worked when a human read every answer and quietly corrected it. It stops working the moment an agent answers a business question, or worse, takes an action.

At that point the question changes. It is no longer how do I ask this well. It is what does this agent know, where does it look, what does it remember, what is it allowed to touch, and who can see why it decided what it decided.

That work has a name now. Context engineering.

The five decisions behind every agent answer

Five context decisions: know, retrieve, remember, use, govern

Every agent answer is the result of five decisions somebody made, on purpose or by accident.

Know. What is the agent's world? Which tables, documents, metric definitions, and business rules are inside the boundary, and which are deliberately outside it. My friend's team had never drawn this boundary, so the boundary became "whatever exists".

Retrieve. How does the agent find the right piece at the right moment? Search quality matters here more than model size. An agent with a small model and precise retrieval beats a large model rummaging through everything.

Remember. What carries over between turns and sessions, and what should be forgotten. Memory that never expires becomes a slow leak of stale facts.

Use. Which tools and actions are available. Reading a gold table is very different from writing to one, and the difference should be enforced by the platform, not by a sentence in a prompt.

Govern. Who is allowed to see what, what gets logged, and how you reconstruct a decision after the fact. This is the part teams skip first and regret most.

None of this is model work. All of it is data work. That is why data engineers are the natural owners of it.

Why the model is not the moat

Models keep getting better, and they get better for everyone at roughly the same time. Whatever model you use today, your competitor can use something similar tomorrow.

What does not transfer is the layer around the model. Your definitions. Your lineage. Your permissions. Your evaluation loop. Your cost discipline.

That is the argument at the centre of The Context Advantage, the sister living book to this one. It frames the durable advantage as four things you actually control:

If you want the long version of that thinking, the first three chapters are free. It is platform independent, so it reads as a companion to the hands-on Databricks work here rather than a repeat of it.

What a dedicated certification actually signals

Databricks now has a certification for context engineering. That matters for a reason that has nothing to do with the exam itself.

Certifications tend to arrive after a skill stops being optional. When a vendor formalises something, it means enough customers are doing it, enough of them are doing it badly, and there is now an agreed shape for doing it well.

So the signal is not "go collect a badge". The signal is that the industry has decided the layer around the model is a job, not a side effect.

We wrote a separate walkthrough of what the exam covers in the Context Engineer Associate explainer, and the book's team keeps a practice exam for it.

What to practise first in Free Edition

You do not need an agent framework to start. You need the boring foundations that agents depend on, and you can build all of them in Databricks Free Edition.

Start with governance, because context without permissions is just exposure. Work through Unity Catalog until you can explain, without hedging, which table is the source of truth for a metric and who can read it.

Then make the data trustworthy. Data quality is where you learn to write expectations instead of hoping. An agent cannot tell the difference between a clean row and a broken one unless you encoded that difference somewhere.

Then look at shape and cost. Partitioning and performance teaches you why the same question can cost a cent or a dollar depending on how the table was laid out. Agents ask questions in volume, so the per-answer cost stops being a rounding error.

Finally, try the natural language layer yourself. Genie Spaces is the fastest way to feel how much a curated set of tables and clear column names changes answer quality. Give it a messy schema, then give it a curated one, and watch the difference.

If you want the wider picture of how the platform itself is changing underneath all this, the data stack is being redesigned for AI agents and Unity AI Gateway is GA cover the platform side.

Where this leaves traditional data engineering

Some people read all of this as a warning that data engineering is being replaced. I read it the other way.

Modelling, lineage, quality, governance, cost awareness. These were always the unglamorous parts of the job, the parts that were hard to justify in a planning meeting. Agents have made them load bearing. A vague metric definition used to cause an argument. Now it causes an automated decision.

The skills did not change. The stakes did.

If you already know how to make data trustworthy, you are most of the way to context engineering. What is left is learning to think about an agent as a consumer with no judgement and infinite confidence, and designing for that.

That is a good place for a data engineer to be standing right now.

Continue learning