Context Engineering
You can't retrain the model and there's a new one every week. The context window is the one thing you actually control — a live build-off lab on what to put in it, what to leave out, and when.
The lever you actually have
You don't train the model. You don't see its weights. And by the time you've formed an opinion about one version, there's a new one. So the question "how do I make this agent better?" has a narrower, more honest answer than it sounds like: you can't touch the model, but you fully control the context window — what goes in, in what shape, and when.
That reframe is the whole talk this module distills: a researcher's live "hands-on lab" session on context engineering for coding agents, built around a real build-off challenge between teams. Not prompt wording — what gets loaded, what gets withheld, and what gets pruned.
Whether the model offers a 200K or a 1M token window, the presenter's working guideline is: don't let a session run past roughly a quarter full. Past that point, responses get slower, cost more, and get less reliable. This is stated as gut feel, not a measured cutoff — "anyone who tells you they know the exact number is talking nonsense." Treat it as a heuristic to test against your own work, not a law.
Three kinds of context — one debatable taxonomy
The presenter's own framework, offered as a lens rather than a settled classification: everything that ends up in the window arrives one of three ways.
Loaded the same way every time, no model judgment involved. CLAUDE.md at user/project/subfolder scope, path- or extension-scoped rules, and lifecycle hooks that fire on a fixed event.
The agent decides whether and when to pull it in. Skills, sub-agents, agent teams, plugins — all conditional on the model judging them relevant to the task at hand.
You, still in the loop: what you ask, when you interrupt, when you correct a wrong turn before it compounds. Context engineering doesn't remove this — it makes the other two layers worth steering.
Deterministic context is cheap to reason about — it's always there, so keep it small. Probabilistic context is where the real budget decisions happen, because the model itself is choosing what to load based on descriptions you wrote. Bad descriptions there cost you twice: once in wasted context, once in a wrong choice.
The deterministic layer, concretely
"Less is more" isn't a slogan here — it's why the deterministic layer is split into several small files instead of one long markdown document. Each piece has one job and loads only where it applies.
CLAUDE.md → user / project / subfolder scope
rules → path- or extension-scoped conventions
hooks → fire on a lifecycle event, not a judgment callCLAUDE.md is only loaded for the default agent — sub-agents don't automatically get it, so a bloated CLAUDE.md doesn't tax every sub-task.
Rules are the right home for "how I want Python written" or "how I want commit messages formatted" — scoped so they only surface when relevant, instead of sitting in every session regardless of task.
Hooks are deterministic events you can hang something on — e.g. a stop hook that hands the session to another model for review, or a pre-input hook that rewrites dictated text before the agent sees it.
The probabilistic layer, and its real trade-off
Sub-agents get a specific, useful default worth knowing precisely: they do not inherit the parent's CLAUDE.md, memory, or persona — but they do inherit model choice and MCP settings unless told otherwise. That's what makes them safe to spin up for a research task without dragging your entire project context along.
Every skill and MCP tool description sits in context whether or not it gets called, once you have enough of them — the presenter's example is a shelf of roughly 200 skills. That's real, measurable budget spent before the agent has done anything.
Claude Code can lazy-load skill and MCP descriptions instead of keeping all of them resident — one setting, a large context saving. The model only pays for the description when it's actually considering that tool.
If you shrink descriptions to save space, the model has less to go on when picking which skill fits the task. Saving context and picking well pull in opposite directions — you can't fully optimize both.
Keep full descriptions, but scope them to the project that actually needs them rather than loading everything at user-scope everywhere. More setup work up front, better selection quality every session after.
A deterministic nudge into probabilistic behavior
The two layers aren't isolated — a deterministic hook can steer a probabilistic decision. One idea floated live in the talk: a hook that fires right before the agent would normally go out and research from scratch, reminding it to check what's already stored first.
Storing notes as a persistent markdown wiki instead of re-researching every time is Andrej Karpathy's suggestion, cited in this talk. Module 12, The Second Brain That Builds Itself, covers that pattern in full — ingest, query, lint. This module only uses it here to show a hook shaping a probabilistic choice; it's one illustration of context engineering, not the whole subject.
Why it matters under a clock, not in theory
The talk's live demo made the stakes concrete. Two identically-configured runs — same model, same CLAUDE.md, same skills — built the same hard visualization task, both nagged by a timer injected into the loop every 30 seconds to hurry up. The only difference: one run had relevant research already stored; the other had to find it from scratch under pressure. The stored-context run finished; the cold-start run either ran out of time or fell back on the model's own trained-in knowledge, with no way to check it against anything current.
The build-off that followed made the same point as a real challenge: teams got 55 minutes to build any context or memory system they wanted around a practice technical drawing, before a real drawing was revealed with only 5-10 minutes left to extract structured data from it into JSON. The task was deliberately chosen to be unsolvable cold in that window — the point was never "solve the extraction problem live," it was "did you engineer your context system before the clock started."
Stated directly in the talk: if you can't judge whether an agent's output on a task is good or bad, you shouldn't hand it that task. Context engineering only pays off on tasks where you have — or can build — a way to check the result. Otherwise you've just made a wrong answer arrive faster.
What's solid, what's one person's experiment
Worth separating before you copy any of this wholesale:
The 25% context-budget rule and the decay windows the presenter mentions for aging out stored notes are explicitly framed as heuristics from personal use, not measured results. Test them against your own workload rather than treating them as fixed thresholds.
Wiki-equipped vs. cold-start was a single illustrative comparison built by the presenter to make a point, not a repeated or independently controlled test. Directionally believable, not statistically proven.
He references real Anthropic research on activation patterns correlating with emotional language, but is explicit in Q&A that using emotionally loaded framing to steer a model is his own interpretive leap on top of that paper, not a claim the paper itself makes.
Sub-agent inheritance rules and the deferred-tools flag are Claude Code implementation details as of the models available at talk time. The underlying principle — separate scopes by default, lazy-load rarely-used descriptions, use lifecycle hooks to inject state — will likely outlive the specific flag names.
Check yourself
Three questions on the reframe and the mechanics behind it.
A teammate says "context engineering is just prompt engineering with a fancier name."
What's the actual reframe the talk is making?
You spin up a sub-agent to research a library, expecting it to already know your project's CLAUDE.md conventions the same way your default session does.
What actually happens by default?
You have ~200 skills installed and turn on deferred tools (lazy-loading) to cut context usage, then also shorten every skill description to save even more space.
What's the actual cost of that second move?
Pull up a session that felt slow or unreliable. Sort what was in the window into deterministic (CLAUDE.md, rules, hooks), probabilistic (skills, sub-agents, MCP tools), and human (what you actually asked). Odds are the deterministic layer was carrying weight it didn't need to, or the probabilistic layer was choosing badly because its descriptions were too thin or too many. Fix one, not both, and see if the next session feels different.