Context Engineering
How the context the model actually sees each turn is assembled, trimmed, and verified. Anchored on the 7 layers, turning CE from "read the theory" into "can decompose, instrument, and account for it."
This module answers a badly underrated question: what tokens did the model actually see this turn — and who decided that for you?
The prompt you wrote is never all the model receives. Framework defaults, conversation history, injected memory, and tool schemas all get quietly assembled in — these "you thought you didn't include them, but you did" tokens are the dark matter of context. Context Engineering (CE) is not writing a longer, finer system prompt (that's still Prompt Engineering); it is optimizing how the entire blob of context the model sees each turn is assembled.
The main thread is the 7 layers: decomposing each turn's context into system prompt, instructions, structured IO, tools, memory, history, and more — plus two cross-cutting concerns, cache and observability. By the end you'll own a capability — make all 7 layers 100% visible, then use a single CONTEXT.md to reconcile the "design ledger" against the "runtime statement"; the gap is the dark matter to investigate.
Lecture order: Lecture 0 builds the overview (7 layers + dark matter + distinguishing CE/PE/Harness), then drills in layer by layer — prompts & instructions, structured IO & tools, memory & RAG, history & compaction — closing on the two cross-cutting concerns (cache engineering, observability & evaluation).
For: engineers and PMs who need their LLM agent stable, cheap, and verifiable — especially anyone stuck on "swapped in a stronger model and it's still flaky" or "can't account for the token cost."
Posts
What the model actually sees each turn was never the prompt you wrote
The context the model receives each turn is one big blob the framework assembled for you; only after all seven layers are 100% visible can you talk about optimizing.
E · 1 Context · Post 1Why the prompt file you're reading is often not the system the model actually receives
A single system message is usually stitched together from several sources; whether a rule belongs in a file or in code comes down to three tests—scope, priority, and robustness.
E · 2 Context · Post 2Why this turn's output shouldn't have to "both speak and be parsed"
Whether a chunk of output should speak plain language or spit out JSON has one and only one criterion—"who consumes it"; whether a tool should be eager or deferred comes down to the latency red line times the number of tools.
E · 3 Context · Post 3Why the Model Misuses Memory Even After You "Injected" It
Whether to inject memory, how much, and what to do when it goes wrong—use the seven-dimension lens to decide, three layers of division of labor to avoid re-feeding, and the opposite instinct to stop treating memory as gospel.
E · 4 Context · Post 4Why Your Conversation History Quietly Balloons Where You Can't See It
Conversation history grows quietly every turn, usually managed for you by the framework and invisible in your code—only a measured growth curve shows you how close it is to the limit.
E · 5 Context · Post 5Your Static Prefix Has a Cache Marker — So Why Are You Paying for It Every Turn
Cache is a byte-for-byte prefix match — one byte off and everything after it is wasted. Marking is not caching; count your tokens first to see if you clear the model's threshold.
E · 6 Context · Post 6Why "the optimization worked" means nothing without the logs to back it up
Cache hits, leaner context, compaction kicking in—every one of these claims has to be reconstructable from the usage logs. An optimization with no observability is just superstition.