# Context engineering > The context window is the agent's working memory. Keep one coherent task in it, load what the task needs, and start clean when the work changes The term became common in mid-2025, when Shopify's Tobi Lütke said he preferred it to "prompt engineering". Andrej Karpathy amplified it a week later, defining it as the art and science of filling the context window with the right information for the next step. Neither of them invented the practice, and no single person coined the phrase. ## The window is a budget The harness adds every read result to the agent's working context: files, command output, your corrections and failed attempts. The window has a hard limit, and performance can deteriorate well before reaching it. Irrelevant material can reduce answer quality, and older instructions may no longer influence responses reliably. Capacity alone does not tell you whether the context is useful. When a session starts going badly, first inspect what is in the window and which of it is noise. Do this before trying another prompt. ## What to load Give the agent the files, examples and constraints this change needs. Errors happen in both directions: - **too little** --- it guesses at a documented convention and invents an architecture next to the one you have - **too much** --- a tour of the whole repository, unrelated history and every test leave less usable context for the part you asked about Before starting, ask what the agent needs to read, then judge the answer. If it requests the entire test suite to change one component, it probably has not located the component yet. ## One task per session Continue while the workstream is coherent. Start a fresh session, or `/clear`, when the job changes. The other trigger is easier to miss. After several failed attempts, their transcripts remain in context and may lead the model towards similar approaches. When you are explaining the same constraint for the third time, start again with that constraint in the brief rather than adding another correction. Resume a named session when the same work continues across sittings. ## When the window fills Long sessions get compacted: the harness summarises what happened so far and uses that summary as context. It may accurately describe the transcript without preserving the decisions that matter for the task. Write the state down while you still have it, perhaps in a `plan.md`, repository note or issue. In the next session, give that record to the agent instead of reconstructing the state from a summary. The record also helps when you return on Thursday. [Task tracking](https://comp.anu.edu.au/courses/comp4020-agentic-coding-studio/topics/task-tracking/) covers several suitable formats. ## Standing and optional context Keep `CLAUDE.md` short: commands, conventions and constraints that apply across the repository. Everything in it is read every turn, so a procedure that only some sessions need belongs in a [skill](https://comp.anu.edu.au/courses/comp4020-agentic-coding-studio/topics/skills/) instead. ## Product mechanics move Compaction, caching and exact session commands change with the harness. The [Claude Code cheatsheet](https://comp.anu.edu.au/courses/comp4020-agentic-coding-studio/topics/claude-code-cheatsheet/) links to the current vendor documentation. Use this page for durable advice about relevance and task boundaries. Source: \ Licence: [CC-BY-NC-SA-4.0](https://creativecommons.org/licenses/by-nc-sa/4.0/)\ Cite as: Swift, B. (2026). _COMP4020/COMP8020 Agentic Coding Studio_ [Course materials]. ANU School of Computing. https://doi.org/10.5281/zenodo.21395760