Pillar 1 - Instructions
The standing instructions are what the model knows before it sees anything. Get the altitude right: not too bossy, not too vague
The Four Pillars (Your Map)
Context engineering breaks into four pillars. Each answers a different question the model faces every turn. We'll take one per lesson, starting here.
1. INSTRUCTIONS "What's my role and how should I behave?" ← this lesson 2. RETRIEVAL "What outside facts do I need right now?" 3. MEMORY "What do I remember from before?" 4. TOOLS "What actions am I allowed to take?"
What the Instruction Layer Is
Instructions - usually the system prompt - are the standing rules the model reads before it ever sees a user message. Its role, its constraints, the format you want back. Think of it as the job description and house rules you hand a new employee on day one, except the model re-reads it on every turn.
You met basic prompting back in Level 0 and Level 3. The new idea here is treating the system prompt as a context-budget decision: every word in it is permanent, so it must earn its place.
The Goldilocks Zone: "The Right Altitude"
Anthropic's key idea for instructions is writing at the right altitude - a Goldilocks zone between two opposite mistakes:
Hardcoding rigid if-this-then-that rules for every situation. It feels precise but it's brittle - the moment reality doesn't match your rules, the agent breaks, and the prompt becomes a nightmare to maintain.
"Be helpful and do a good job." This gives the model nothing concrete to act on, and quietly assumes it shares context it doesn't have.
Specific enough to guide behavior, flexible enough to let the model use its own judgment. You give strong heuristics, not a rigid script.
TOO LOW "If the file ends in .test.ts AND is in /unit AND was
changed today, run npm test:unit, else if..." (brittle)
TOO HIGH "Write good tests." (useless)
RIGHT "Add tests for new behavior. Prefer the project's
existing test style. Cover the happy path and the
obvious edge cases." (heuristics)Minimal Does Not Mean Short
A common misread: "keep it minimal" means "keep it tiny." Not quite. Minimal means the smallest set of information that fully spells out the behavior you want - no more, no less. Sometimes that's a paragraph; sometimes it's a page. The test is signal, not length.
Structure and Examples
Use headers or tags like ## Background, ## Instructions, ## Output format. It helps the model (and you) find things. Exact formatting matters less as models get smarter, but clear structure never hurts.
Examples are powerful - "a picture worth a thousand words" for a model. But don't stuff in every edge case you can think of. Pick a few diverse, typicalexamples that show the behavior you want. Quality over quantity (and over budget).
You've Already Seen This Pillar in Action
Remember CLAUDE.md from Level 7 (and the Skills lesson)? That's the instruction pillar applied to a whole project: your conventions and "never do" rules, written once at the right altitude, dropped into context every session. A good SKILL.md or CLAUDE.md is context engineering of the instruction layer.
Hands-On: Fix the Altitude
Instructions, Retrieval, Memory, Tools - the four parts of context you engineer
The standing system prompt / rules the model reads before any user message, every turn
Goldilocks zone: specific enough to guide, flexible enough to let the model judge - heuristics, not a rigid script
Brittle if-else rules (too low) vs vague hand-waving (too high) both fail
The smallest set that fully specifies the behavior - could be a paragraph or a page; judge by signal
Start minimal, add a clear instruction/example only to fix a real observed failure
A few diverse, typical examples beat a laundry list of every edge case