Context is a limited resource, and understanding what fills it matters more than any saving tricks. It is consumed not only by your messages: loaded instructions, the content of read files, tool output, images, the instructions of loaded skills and summaries after compaction - all of this takes up space. The practical consequence is simple: a long chat becomes unreliable if the decisions made dissolve in the noise. It is not the volume of the conversation by itself that is useful, but the density of the relevant in it.

Hence the discipline of compaction and keeping the goal. /compact is applied after a finished stage, not in the middle of an unresolved incident: compaction at a bad moment risks carrying off exactly the context you still need. /goal keeps a brief statement of the goal along the way, but does not replace a detailed task contract - it is a reminder of direction, not the full set of boundaries and checks. One keeps focus, the other sets the frame; they should not be confused.

Memories are a separate mechanism with their own rules and their own risk. They may blend into future sessions, that is, affect the agent's behavior beyond the current conversation. Hence two requirements: they are checked - because a stale or wrong note will quietly influence the work - and no secrets are kept in them, because memory outlives the session and is available further on. Memories are useful while they are durable observations, not a dump of temporary task state.

The key skill of context management is putting knowledge where it belongs rather than dumping everything into the conversation. A one-off constraint lives in the current prompt or /goal. The repository's commands and conventions - in AGENTS.md. A repeatable procedure - in a skill. Mechanical policy - in the sandbox, permissions, rules or a hook. Long-term knowledge - in reviewed instructions, not in auto memory. Each type of knowledge has its right place, and choosing the place matters more than cramming one with everything.

It helps to gather this correspondence into a table once, so as not to invent a new entity for every task. Below is the map: which knowledge goes where. You return to it when your hand reaches to put a procedure in the prompt or a policy in memory: each mechanism has its own loading semantics and its own cost in context. Correctly placed knowledge loads when needed rather than hanging in every conversation, taking up space and lowering the density of the relevant.