Context vs. Prompt Engineering
Prompt Engineering: Writing instructions for single tasks
Context Engineering: Managing all tokens (instructions + tools + data + history) across multi-turn interactions
Key shift: "What to say" → "What information to include"
Core Problem: Context Rot
- More tokens = worse recall/accuracy
- Context is finite with diminishing returns
- LLMs have "attention budget" that depletes
Guiding Principle:
Smallest set of high-signal tokens for desired outcome
Effective Context Components
System Prompts
✅ Simple, direct language at right altitude (not too specific/vague)
✅ Use XML tags or Markdown sections
✅ Start minimal, add based on failures
❌ No hardcoded logic or vague guidance
Tools
✅ Token-efficient, self-contained, minimal overlap
✅ Descriptive parameters, clear purpose
❌ No bloated tool sets or ambiguous choices
Examples
✅ Curate diverse, canonical examples
❌ No edge case laundry lists
Retrieval Strategies
Just-In-Time (JIT):
- Maintain identifiers (paths, links)
- Load data dynamically with tools
- Progressive discovery
- Trade-off: Slower but efficient
Hybrid (Recommended):
- Critical data upfront
- JIT exploration as needed
- Example: Claude Code
Long-Horizon Techniques
1. Compaction
Summarize → restart with compressed version
- Use for: Conversational flow, near limit
- Keep: Key decisions, bugs, recent files
- Discard: Old tool results
- Quick win: Clear deep tool results
2. Note-Taking
Persistent notes outside context
- Use for: Iterative work, milestones
- Examples: To-dos, NOTES.md, progress logs
- Tool: Memory tool (beta)
3. Sub-Agents
Specialized agents → condensed summaries
- Use for: Complex research, parallel work
- Pattern: Main coordinates, subs explore (10k→2k tokens)
Decision Framework

Quick Wins
- Remove bloated tools/examples
- Structure prompts with XML/Markdown
- Use hybrid retrieval
- Clear old tool results
- Add memory tool for notes
Core Principle
"Do the simplest thing that works"
Context remains precious - thoughtful curation beats exhaustive inclusion.