Context Engineering

The model can only use what's in its context window. Context engineering is the art of putting the right information there — and keeping the wrong information out.

What belongs in context

• The goal and acceptance criteria.
• Relevant files (found via search, not dumped blindly).
• Project conventions (CLAUDE.md / AGENTS.md / .cursorrules).
• Error messages and test output.
• Recent tool results — the loop's observations.

What should be pruned

• Old, irrelevant tool output.
• Entire files when a snippet would do.
• Boilerplate (lockfiles, minified bundles, giant generated files).

Techniques

Project memory files

Put persistent instructions where the agent always reads them:

# CLAUDE.md
Build: npm run build
Test:  npm test
Style: 2-space indent, no semicolons, functional components only.
Never: edit generated/ or vendor/.

Retrieval, then inject

Don't paste the whole repo. Search first:

find User model → read only models/user.py + its imports

Summarize the middle

On long tasks, periodically compress the history into a short status block, then continue with fresh context.

The three-bucket model

Think of context as three buckets:

1. Instructions (stable) — system prompt + project memory.
2. Evidence (changing) — files, errors, search results.
3. History (growing) — the conversation and tool log.

Most context problems come from bucket 3 growing until it crowds out bucket 2.

Why this matters

Two agents with the same model can be night-and-day different — the better one simply feeds the model better context. It's the highest-leverage skill in agentic coding.

When an agent fails, ask first: what did it not see? The answer is usually a context problem, not a model problem.