Skip to content

5.1 Context Is the Product

Prompt engineering asked "how do I phrase it?" Context engineering asks the bigger question: "what does the agent see, and who decided?" This lesson examines — with an experiment you'll run yourself — how context quality affects a task, then lays out the discipline's core principles.

What you will learn

  • Define context engineering and its relationship to the context window.
  • Run the A/B experiment that proves the effect on your own project.
  • Apply the three core principles: right things in, wrong things out, durable over repeated.

Builder principle

Every session, the model reads a briefing packet. Someone assembles that packet. Either you engineer it, or you get whatever fell in.

The claim, precisely

At any moment, the model's entire universe is its context window (Lesson 2.2): your messages, files it read, command output, its own notes, the conversation so far. Nothing else exists for it. Therefore:

Output depends on model capability, context, tools, environment, and verification. Context is one factor you can change and test.

You cannot change a hosted model's underlying capability during a session, but you can improve the task packet and compare the result. That makes context a practical place to experiment rather than a guaranteed multiplier.

Prove it to yourself

Run both versions of this session on your quick-win project (/clear between them):

Data gate — complete before adding a real example

  1. Classify: Is the material public, internal, confidential, personal, or regulated?
  2. Authorize: Do you have permission to provide it to this agent and its tools?
  3. Check handling: Do the provider, account, retention, and organizational controls permit this use?
  4. Minimize: Remove names, secrets, identifiers, and details the task does not require.
  5. Substitute: When any answer is unclear, use a synthetic example instead. Do not proceed with the real material.

Version A — bare:

Add a testimonials section to the site.

Version B — engineered:

Read SHIPPING.md and index.html first.

Add a testimonials section: 3 quotes, name + role under each.
Placement: between Services and Contact.
Style: match the existing card pattern exactly — same spacing
and hover behavior as the Services cards.
Voice: the quotes should sound like real people, not stock praise —
here's one real example to match: "[paste one]"
Done means: renders correctly at 375px; visually indistinguishable
in style from the Services section.

Same model. Same task. Compare the two diffs. Version B typically nails placement, style-matching, and tone on the first pass; Version A guesses at all three. You didn't get a better model — you built a better packet.

If comparison includes a visual result, use the accessible human-acceptance matrix. Describe the evidence you personally gathered and label any delegated visual review.

The three principles

1. Right things in. The agent needs what a new teammate would need: what this project is, what good looks like here, what we've decided, where things live. If it matters for the task, it goes in view — as files to read, examples to match, clauses to satisfy.

2. Wrong things out. Context is attention, not storage. Irrelevant files, dead conversation, three abandoned approaches ago — this stuff doesn't just waste space, it actively pollutes: the model weights what's prominent, so noise competes with signal. Curation means removing, too. (/clear is a context-engineering tool, not a reset button of shame.)

3. Durable over repeated. When a reviewed explanation recurs, consider placing it in an appropriate file that the agent can load. Keep it scoped and maintained. This principle motivates CLAUDE.md (next lesson), memory (5.3), and the second brain (5.4).

The mindset shift

Watch the pros run a session and the pattern jumps out — they spend proportionally more time before the build:

Beginner instinct Engineer-of-context instinct
Type the request and go Ask: what does it need to see to do this right?
Repeat project facts each session Write facts down once, in the right layer
Paste error text, hope Point at files, logs, and examples by path
Long meandering mega-sessions Scoped sessions, deliberately assembled
"The AI got it wrong" "What was missing from its view?"

When output disappoints, audit the task packet as well as the model/tool choice: missing context, conflicting constraints, weak examples, unsuitable capability, and inadequate verification can each matter.

Try it now

You already did — the A/B experiment above is the exercise. Close it out:

  1. In your journal: three specific differences between the A and B outputs.
  2. List what Version B's brief contained that A's didn't (files to read, placement, example, done-means…).
  3. Now the key question: which of those additions will be true for every future session in this project? Star them. Those stars are exactly what goes in CLAUDE.md — which you'll build in the next lesson.

Check your understanding

  • Name five factors that can affect output quality. Which one does this lesson ask you to test?
  • Why does irrelevant context actively hurt rather than merely waste space?
  • State the three principles. Which one generates CLAUDE.md and memory?
  • What's the productive first question when agent output disappoints?