CORE GUIDE
Context management
Context management continuously decides what to load, refresh, compact and remove as a task evolves.
Mental model
Good context is assembled just-in-time from state and evidence; it is not a transcript that grows forever.
Why it matters
Long-running work changes. Facts become stale, goals are refined, tools return new state and intermediate reasoning loses value. Without an explicit context lifecycle, the prompt becomes a mixture of current evidence and historical residue.
01
A context lifecycle
Before each meaningful step, the application identifies the decision to make, loads the minimum relevant state and evidence, preserves durable constraints, and compacts or discards transient material. Retrieval and memory are inputs to this lifecycle rather than separate magic features.
02
Example: repository editing agent
Instead of resending the entire repository and chat history, an editing agent loads the current task spec, the files it will modify, relevant tests and the latest tool results. After a successful change it persists the decision and drops raw command output.
Common failure modes
- Equating conversation history with application state.
- Reloading large static prefixes even when they do not affect the next step.
- Failing to invalidate context after the underlying source changes.
Engineering heuristics
- Build context around the next decision, not the whole project.
- Separate durable state, retrievable knowledge and transient observations.
- Record why an item was retained so compaction policies can be audited.
Takeaways
- 01Context management is a lifecycle, not a one-time prompt optimization.
- 02State should survive outside the prompt when it matters after compaction.
- 03Retrieval, memory and summarization are selection mechanisms inside one larger policy.
Related concepts from the Knowledge Graph
These relationships come from the canonical graph, not a separate Guide taxonomy.