Async

Module 1.6 - Context engineering: the throughline

Prompting, token cost, and model choice can feel like three separate skills. They are not. They are all decisions about one thing: what information you put in front of the model, in what form, at what price, to get a reliable result. That is context engineering - and naming it is the point of this module, because it is the throughline of the entire course.

Why it is the real skill

Models are largely fixed; you rarely train them. What you control is the context - and in 2026 the gap between a demo that works once and a system that works reliably almost always comes down to context: what goes into the window, in what order, and how fresh it is. Prompting decides the instructions and examples. Token economics decides how much context you can afford. Model selection decides how much the context can be relied upon to be used well.

Context engineering across the whole course

Hold this lens and the syllabus organizes itself. RAG (Week 2) is engineering the context by retrieving the right documents into it. Tools and MCP (Week 3) are engineering the context by letting the model pull in live information and actions. Memory (Week 5) is engineering the context by carrying forward what the agent has learned. Evals (Week 4) measure whether your context engineering actually works.

Landing it on your capstone

The exercise is to ask, for your specific problem: what is the right context to put in front of the model, in what shape, at what cost, for it to reliably do the job? Answering that is the design of your whole system in miniature - and everything after this week is you getting fluent at sourcing that context well.

Watch out

Common mistakes

  • Treating prompting, cost, and model choice as unrelated tricks.
  • Over-stuffing context in the belief that more is better.
  • Ignoring the order and freshness of context (the model attends unevenly, and stale context produces confident wrong answers).