Anatomy of a context
System, user, history, examples, retrieved data and tool results.
What you’ll learn
Four ideas, one module.
Instructions vs data
Who wrote each part, and how far to trust it.
Order and hygiene
A deliberate order, and removing what pollutes the window.
Prompt injection
Why the prompt can’t fix it, and how systems defend in layers.
Applied exercise
Redesign an overloaded context
Redesign an overloaded assistant context with conflicting instructions, irrelevant history and poor retrieval.
- Conflicting instructions
- Irrelevant history
- Poor retrieval
- Ordering and trust
Cheat sheet · for your projects
Treat the context like an API contract: every part needs an owner and a trust level.
Ask on every project
- What exactly does the model receive on one request, in order? Can we log it?
- Who owns each part of the context, and when was it last reviewed?
- Which parts can a user, an email, a web page or a tool result write into?
- If injected text took control, what is the worst the system would let it do?
- What gets trimmed, summarized or dropped when the window fills up?
Rules of thumb
- Fix a conflicting instruction at its source; never add a rule to overrule another.
- Label untrusted content with its source and pass it as data, never as instructions.
- Vary few-shot examples and include an edge case; the model copies their flaws too.
- Cap what a hijacked model can do: least-privilege tools, approval for sends and deletes.
Template
Context assembly template
- Role and rules: purpose, hard limits and tone; one owner, no conflicts, stable so it caches
- Examples: a few varied input and output pairs in the target format, including an edge case
- Reference material: only relevant chunks, delimited, labeled with source and date, as data
- Tool results: the fields the task needs, not raw dumps, labeled with the system they came from
- History: recent turns that still matter; older ones summarized or dropped
- Task and output format: the current question restated, plus the schema or format required
Leave at the door
Five myths this module breaks.
| Myth | What’s actually true |
|---|---|
| “A better prompt fixes everything.” | Most failures are what’s in the window. |
| “More context is always safer.” | Irrelevant tokens distract and mislead. |
| “The system prompt is secret and binding.” | It can leak, and users can talk around it. |
| “Ask for JSON and you’ll get it.” | Enforce a schema if you can. Validate always. |
| “One line in the prompt stops injection.” | No prompt fixes it. Limit what the system can do. |
Next · Module 05