The same model can seem like a different person with different context. Does it know the goal, available tools, what just happened, and which rules it must not violate? Each answer directly changes its next action.
The goal of context engineering is not to show the model more, but to show it correct, sufficient and trustworthy information at every step.
01 / LAYERSSplit context into four layers
A system instruction, user goal, assistant history and tool results have different responsibilities. Merging them into one large block makes priority, source and traceability worse. Keep a system layer for identity, long-term rules, security boundary and output conventions; a task layer for the current problem and acceptance test; a trajectory layer for decisions, tool calls and real feedback; and a state layer for remaining steps, time, budget, failures and confirmations.
02 / PRACTICETool results must return to context
An agent loop is not continuous prose. It acts, then observes again. Tool parameters, execution results and errors must enter the next round; otherwise the model cannot distinguish “I intend to do this” from “I did it.” Production systems also need a maximum iteration count, repeated-call detection and clear stopping conditions so the agent does not turn forever on one error. A plan is not a result: only verifiable tool feedback moves an agent forward.
03 / CACHE-AWAREStable content goes first and changing content goes last
KV Cache and prompt cache favor a stable prefix. Keep system rules, fixed tool definitions and a few high-quality examples in a stable order; place the current question, tool results and state panel later where they can change. This is not only a performance optimization. It forces a clear architectural question: what is a long-term rule, and what is temporary state for one task?
04 / PRACTICEA system prompt organizes a process
A useful system prompt states role and objective, then workflow, tool-use rules, output format and a few boundaries. More rules are not automatically safer; conflicting rules without priority are harder to execute. Turn abstract requirements into observable actions. Use a few examples for edge cases instead of covering everything. Treat external materials as untrusted input so prompt injection cannot replace system rules. Tool descriptions should say when to use the tool, what inputs mean, how it fails and what side effect it has.
05 / PRACTICELoad Skills when needed and keep direction with state
Domain knowledge need not live permanently in context. Load a Skill when a task matches to supply a method, template or operating convention; use a short status panel to record progress, time and next action. They solve different questions: a Skill answers “how should this kind of work be done?”, while state answers “where is this work now?”.
06 / COMPRESS OR ISOLATEIsolate first, then compress
Long tasks cannot accumulate raw conversation without limit. Retain recent originals, stage summaries, key facts and external archives in layers. When subtasks are independent, however, isolation is often more reliable than compression: one sub-agent checks dates, another checks citations, then their conclusions are combined. Each context is shorter and less likely to contaminate another. As a first exercise, remove one of the system instruction, tool description, history trajectory or status panel and observe the first step where the agent gets weaker.
Source book and chapter references
- bojieli/ai-agent-book.
- Chapter 2 — context engineering.
- Chapter 2 experiments.
- This is an applied reorganization, not a replacement for the source book; use the source text and code for exact claims.
READER COMMENTS
Leave the thought this article gave you.
No comments yet. You can leave the first one.