Prompt engineering vs context engineering.

The short answer

Prompt engineering is the craft of wording a request so a model responds well. Context engineering is the discipline of deciding what the model should see at every step of a task: business definitions, retrieved facts, memory, tool outputs, permissions, and how all of it fits inside a token budget.

A perfect prompt over the wrong context gives you a confident wrong answer. A plain prompt over the right context usually gives you the right one. That is why the work has moved.

Side by side

• Unit of work. Prompting: one message. Context engineering: a whole task, often many turns and many tools.
• Main lever. Prompting: wording, examples, role. Context engineering: what is retrieved, remembered, compacted, and withheld.
• Inputs. Prompting: text you write. Context engineering: metrics, entities, policies, documents, history, tool results.
• Typical failure. Prompting: vague or ignored instructions. Context engineering: missing meaning, stale memory, context rot, leaked data.
• How you test it. Prompting: try a few inputs. Context engineering: evaluation sets tied to business definitions.
• Who owns it. Prompting: whoever writes the request. Context engineering: a named owner, usually a data or context engineer.
• Cost impact. Prompting: small. Context engineering: large, because tokens, caching, and retries are decided here.

Why prompting stopped being enough

Early chat use was one question and one answer. Agents changed that. An agent reads instructions, calls tools, retrieves documents, writes to memory, and hands off to other agents. By turn ten, the words you wrote are a small fraction of what the model is reading. The rest is context, and someone has to design it.

Enterprise questions also carry hidden meaning. "Active customer" or "net revenue" has a company-specific definition. No phrasing trick supplies that definition. Only a governed context layer does. The book explains this in Chapter 5: Context Is the New Data Layer and Chapter 7: Semantic Layers, Ontologies, and Metrics.

When prompt engineering is enough

Personal productivity, one-off drafting, brainstorming, and small tasks where the model already has everything it needs. If a wrong answer costs nothing and the facts are in the message, careful prompting is the right tool.

When you need context engineering

Any agent that touches company data, money, customers, or compliance. Any system with memory or tools. Any workflow where the same question must get the same governed answer for every user. If you need to explain later why the agent did something, you need context engineering.

The four layers context engineers design

1. Instructions. Still prompts, but versioned, tested, and kept short. This is where prompting skill lives on.
2. Knowledge. Retrieval over documents and structured data, grounded in business definitions. See Chapter 35: Retrieval Mechanics.
3. Memory. What the system remembers across sessions, who owns it, and when it expires. See Chapter 10: Institutional Memory Is the Moat.
4. Budget. What gets compacted, cached, or dropped so the window stays useful and affordable. See Chapter 36: Compaction and the Token Budget.

How to move from prompting to context engineering

1. Pick one agent or assistant your team already uses.
2. Write down every source it reads, not only the prompt.
3. Find the three business terms it gets wrong most often and define them in one governed place.
4. Build a small evaluation set of 20 to 50 real questions with known correct answers.
5. Measure tokens per correct answer, not tokens per call.
6. Assign a named owner for the context, the same way you would for a data pipeline.

The full 30-day path is in the essay The 30-Day Path from Data Engineer to Context Engineer, and the practice exam lets you test yourself against the Databricks Context Engineer Associate blueprint.

Frequently asked questions