Context Engineering

A support agent types "Draft the renewal email for Dana" into an AI tool. The sentence is clear. Yet the model cannot write a useful email from that sentence alone, because it does not know who Dana is, what plan she has, or what happened on her account. No rewording of the sentence can supply those facts.

The previous lesson covered prompt engineering, which is about the words of the request. Context engineering is the wider version of the same work. It covers not only what you ask, but everything that is put in front of the model before it answers: documents, instructions, and tools.

This lesson explains how the two terms relate, what choosing context looks like in a concrete case, and how much difference it makes to the answer. After this lesson you can explain why two people who type the same prompt can get very different results, and what to add when a well-worded prompt still produces a generic answer.

1. The prompt is only part of what the model gets

The lesson on context listed the parts of a request: system instructions, developer instructions, the conversation so far, the user's message, attached files, retrieved documents, saved memory, and tool definitions. The prompt is the part the user writes. Everything else also reaches the model, and the model reads all of it as one input.

So the prompt is only one part of what the model gets. Everything else in front of the model counts as much as the prompt does. A model can only answer from what it learned in training and from what is in the request. If a fact about Dana is not in the request, the model does not have it.

This is the reason a second term was needed. Improving the answer is often not about better wording. It is about better material.

2. How the two terms relate

The two terms are not rivals. One sits inside the other.

flowchart TB
    subgraph CE["Context engineering: everything the model gets before it answers"]
        PE["Prompt engineering:<br/>the words you type"]
    end

The inner box is prompt engineering. It deals with the words of the request. The outer box is context engineering. It deals with everything the model receives, and the prompt is one item inside that.

The outer box was always there. From the first chat products onward, models received instructions and documents along with the user's message. That wider work had no name of its own until the term "context engineering" became common. Many people were already doing it: anyone who pasted a reference document into a chat before asking a question was choosing context.

Because of this history, the two terms are sometimes used loosely for the same thing. When a distinction is needed, the test is this: changing the words of the request is prompt engineering, and changing what is sent along with the request is context engineering.

The term became common as AI tools grew more complex. A simple chat has little context to manage. An agent, an AI system that can take actions and that later lessons cover in detail, may read files, call tools, and run for many steps. Deciding what goes into its context at each step is a large part of making it work.

3. Choosing the context for one task

Go back to the renewal email. The prompt stays the same: "Draft the renewal email for Dana." What is sent with it is the part that needs deciding.

Suppose the company has a shared drive with thousands of files. Sending all of them is not possible, and it would not help. The work is to pick the ones that bear on this task.

The right documents:

account/dana-reyes.md
tickets/4471.md
tickets/4489.md
contracts/renewal-terms.pdf

The right instructions and the right tools:

instructions/
  tone-of-voice.md
  never-promise-a-date.md

tools/
  lookup_contract()
  check_renewal_window()

Each item has a reason to be there.

The names ending in () are tools. A tool is an action that the software around the model can perform when the model asks for it. The model cannot open a company's contract system on its own. If a description of lookup_contract() is in the context, the model can ask for that lookup, and the result is added to the context as text.

None of these items is the prompt. All of them are what the model has to work from. The selection is four documents out of a whole drive, two instruction files, and two tools. Deciding which four files and which two tools is the whole job of context engineering.

4. Why not send everything

A natural thought is that more context is always better, so the safe choice is to send everything available. Three limits make that a poor choice.

• Space. The context window is a fixed size. A whole drive does not fit.
• Cost and speed. Every token in the context is processed and billed. Ten times the context is roughly ten times the input cost, and a slower answer.
• Accuracy. A model that is given a large amount of unrelated material can lose track of the relevant parts or mix up details from different documents. If the context holds tickets from fifty customers, the email to Dana may mention someone else's problem.

So context engineering works in two directions. It adds what the model needs, and it leaves out what the model does not need. Too little context gives a generic answer. Too much gives a slow, expensive, and sometimes confused one.

5. The same prompt with and without context

Here is the effect on the actual output. The prompt and the model are the same in both cases.

With the prompt alone:

you:     Draft the renewal email for Dana.

model:   Dear valued customer, we hope you have been
         enjoying your subscription and would love to
         have you stay with us...

With the context from section 3 around the prompt:

you:     Draft the renewal email for Dana.

model:   Hi Dana, your plan comes up for renewal next
         month. Both tickets you raised are closed, and
         your current terms carry over...

The first email is fluent and polite, and it is about nobody in particular. It could be sent to any customer of any company. The model had nothing specific to use, so it wrote the most typical renewal email it could.

The second email uses Dana's name, states when her plan renews, mentions her two tickets, and says what happens to her terms. Every one of those details came from a document or a tool in the context. The friendly, direct opening follows the tone-of-voice instruction. The email says "next month" and not an exact day, which respects the rule about never promising a date.

The same model received the same typed sentence. In the second case it had something to work from.

An everyday comparison: two temporary workers are each asked to write to a customer. One is given only the request. The other is also given the customer's file and the company style guide. The second letter is better, and the reason is not that the second worker is more skilled. The comparison stops being accurate at one point: a human worker could go and find the file unprompted, while a model can only use what is placed in its context or what its tools can fetch.

6. Who does context engineering

The work is shared between people and software.

For a person using a chat app, the practical rule follows from section 5. When an answer is generic, check what the model was given before rewording the prompt. If the answer needs facts about a specific customer, project, or document, those facts have to be in the context.

Interview points

• Context engineering is deciding everything a model receives before it answers: instructions, documents, tool definitions, memory, and history, as well as the prompt.
• Prompt engineering is a subset of context engineering. It covers the wording of the request, while context engineering covers what is sent with it.
• A model answers only from its training and the current context. Facts that are missing from the context cannot appear in the answer, however well the prompt is worded.
• The same prompt and the same model give a generic answer without context and a specific one with the right context.
• Good context is selective. The aim is the few documents, instructions, and tools that bear on the task, not everything available.
• Sending too much context costs tokens, slows the response, and can reduce accuracy because relevant details are buried among unrelated ones.
• Tools are part of the context. A model can request only the tools whose descriptions it was given, and tool results come back into the context as text.
• Users do context engineering by attaching and pasting material. Developers do it by designing system prompts, retrieval, tool sets, and what is kept across turns.

Summary

• The prompt is one part of what the model receives.
• Context engineering is choosing all of it, and prompt engineering is the part about wording.
• The wider work existed before it had a name.
• For one task, the job is picking the few documents, instructions, and tools that matter.
• Too little context gives generic answers, and too much adds cost and confusion.
• The same prompt gives a far better answer when the right context is around it.