All posts

Context Engineering 101: Designing What Your Agent Knows

AI AgentsPromptEngineeringAISoftwareDevelopment

Prompt engineering asks "how do I phrase this?" Context engineering asks "what should the model know before it answers?" The second question is the one that scales.

TL;DR

  • Context engineering is the architecture of what information enters the model's context window.
  • Distinguish static context (always loaded) from dynamic context (loaded on demand).
  • The window is finite — curate ruthlessly; more is not better.
  • The guiding question: what would a new human hire need to know to do this task?

Beyond prompt engineering

Prompt engineering treats the prompt as the lever. That works for one-off requests. For agents doing real, repeated work, the bigger lever is context: the conventions, the relevant files, the domain knowledge, the tools available, and the memory of what happened earlier. A perfectly phrased prompt with no context still produces confident, generic, wrong answers.

Static vs. dynamic context

A useful split:

  • Static context is always present: the agent's core instructions, persona, non-negotiable rules, key conventions. It is reliable but expensive — it occupies the window on every call.
  • Dynamic context is loaded on demand: the specific files relevant to this task, retrieved documentation, the current error. It keeps the window lean by bringing in only what the moment needs.
Static  (always loaded):  instructions, conventions, guardrails
Dynamic (loaded per task): relevant files, retrieved docs, current state

Get the balance wrong in either direction and the agent suffers: too little static context and it ignores your rules; too much and you crowd out room for the actual task.

The context window is a budget, not a bucket. Every token you spend on noise is a token unavailable for signal.

The new-hire test

The most useful design heuristic: what would a competent new human hire need to know to be productive on this task? That framing surfaces the right context — the architecture overview, the naming conventions, the "we never do X here" rules, the example of how your team writes a component. Then you encode that knowledge so the agent starts with the same ground truth a good colleague would.

Curate ruthlessly

More context is not better context. Irrelevant files, stale docs, and redundant instructions dilute attention and degrade output. Practical discipline:

  • Keep static context tight — the rules that always apply, nothing more.
  • Retrieve dynamically and specifically — the three files that matter, not the whole repo.
  • Prune regularly — out-of-date context is worse than missing context, because the model trusts it.

Why it is the high-value skill

As models commoditize, the differentiator is how well you feed them. Two teams with the identical model get very different results based on context design. Context engineering is the architecture discipline of the agent era — and unlike a clever prompt, a well-designed context system compounds across every task the agent touches.

More on building reliable agents, on the blog. →