What It Sees: Context, Not Memory
The agent knows two kinds of thing: what its training taught it about code in general, and what is in its context in this session. Your team's conventions, yesterday's decision and the reason refunds looks the way it does are in neither, unless someone wrote them down somewhere the agent reads.
Many of its strangest mistakes stop being strange once you ask what was in front of it. A helper written twice, a convention ignored, an approach you rejected yesterday proposed again with full confidence: each one traces to something the agent could not see. The fix, almost always, is to change what it sees.
Training, Context, Files
Training is general and dated. It is public code and documentation up to a cut-off date, absorbed before the model was released, so it holds at most an old copy of your repository, never the code you are changing today. It is why the agent writes fluent code in your language on the first try, and why it sometimes reaches for a library call that changed two versions ago.
Context is the working set of this session: the tool's instructions, your project instructions file, your messages, every file it has read and every command output so far. It is the only place your code exists for the agent, and only once it has been read. Files are what persists: the code itself, the project instructions file, notes, commit messages. Of the three, only files survive the end of a session.
A Session Starts Empty
Open a new session and the agent knows nothing of the last one. The helper it wrote yesterday, the approach you tried and rejected, the question Ines, who leads the team, answered about how refunds treat a class the gym cancels: unless that is in a file the harness loads at the start or one the agent reads during the task, it is gone. The agent will propose the rejected approach again, with the same confidence as the first time, because from its side there was no first time.
At Cragmoor this happens in the most ordinary way. On Monday you ask the agent to speed up the class list, it proposes keeping the week's schedule in memory, and you reject that because two gyms edit their timetables during the day and the cached copy would go stale. On Tuesday, in a new session, you ask for something nearby and it proposes the same cache. Nothing went wrong with the model. The reason you gave on Monday was in Monday's context, and Monday's context is gone.
This is the single most useful fact about working with an agent across days. It has the skills of a capable colleague and none of the history, every single morning. Brief it the way you would brief a contractor on their first day, and write down whatever the next contractor will need.
The Window Is Bounded
Context has a size limit, counted in tokens, which Working with LLMs from Zero covers if the term is new. The limit is generous by the standards of a conversation and small by the standards of a codebase. Cragmoor's booking service is about 60,000 lines. A typical session reads a few dozen files of it, chosen by searching for the words in your request.
Search is driven by your words. Ask about "the refund window" and the agent searches for refund, window, maybe 24, and finds refunds. If the same rule is also enforced somewhere that calls it "free cancellation until", in a file the search never matched, that file is not in the session. Chapter 4 returns to exactly this case with the refund task.
For the agent, code it did not read does not exist. It will not contradict the time-zone helper in schedule out of carelessness; it never opened schedule, so as far as it knows there is no helper to use. The parts of the codebase it skipped are the parts it is most likely to contradict.
The Mistakes This Explains
Run through the agent's characteristic mistakes at Cragmoor and most of them sort into one of the three sources.
| What the agent did | Where it came from | The fix |
|---|---|---|
Wrote a new time-zone helper when schedule already has one | Context: it never opened schedule | Point it at the file, or name the helper in the instructions file |
| Formatted errors unlike the rest of the code | Nowhere: the convention is not written down | Write the convention down where every session reads it |
| Contradicted what you said two hours earlier | Context: the early message faded in a long session | Start a fresh session with a short written handoff |
| Called an option your library version does not have | Training, not your lock file | Have it read the version you depend on, or its documentation |
In every row the fix is a change to what the agent sees, not a sterner instruction. "Be careful to use existing helpers" does nothing for an agent that has not read the file containing the helper. "Use the helper in schedule for every class time" does, because it names the file and puts the fact in front of it.
The transcript sorts a mistake into its source in under a minute. If the agent never opened the file that held the answer, the mistake came from context, and the fix is a pointer. If it opened the file and still went its own way, look for a convention that lives only in people's heads, and write it down. If it used an option or a call that does not exist in your version, it reached into training, and the fix is to have it read the version you depend on. Only when none of the three applies is it worth asking whether the model simply got it wrong.
Writing Things Down Is the Memory
The only memory that carries from one session to the next is text in files. The project instructions file is read at the start of every session, and Chapter 3 is about writing it. A short handoff note carries a long task into a fresh session. A saved plan holds the decisions you made before any code changed. A commit message that says why a change was made is the reason the next reader, human or agent, does not undo it.
As of 2026 some tools also save notes of their own, which load into later sessions. Those are files too, written by the agent, which means they can be wrong, and they go stale in the same way any other file does. Read them as you would read a colleague's notes: useful, and not authoritative until checked against the code.
A good handoff note is short. What the task is, what has been decided and why, what has been tried and rejected and why, which files matter, and what is left. Eight or ten lines carry a day's work into a fresh session better than the day's whole transcript would, because the transcript also carries every dead end with the same weight as the conclusions.
Training is what the model learned before release: languages, common libraries and general practice, frozen at a cut-off. It holds at most an old copy of your repository, never today's. When a mistake comes from training, give the agent the version you actually use.
Context is what it has in front of it this session. It holds your code only once read, and is gone when the session ends. When a mistake comes from context, point the agent at the file it missed.
Files are what you wrote down, and the only thing a new session can know about your project. When a mistake comes from nowhere at all, write the missing fact down where every session reads it.
- "It remembers yesterday's conversation." A new session starts with only what the harness loads, the instructions files and any saved notes. Everything else lived in a context that no longer exists.
- "It has read the whole repository." It read what it searched for. On a 60,000-line codebase that is a small fraction, and the parts it skipped are the parts it will contradict.
- "If it got it wrong, the model is not good enough." More often the information was not in its context. The same model, given the file with the existing helper, uses the helper.
- "Telling it to remember will make it remember." A sentence in this session lasts for this session. To persist, it has to be in a file that a future session reads.
- "Its training covers my dependencies." Training reflects public code up to a cut-off. The version pinned in your lock file is something it knows only after it reads it.
- Ask what was in its context before blaming the model. The fix is usually a file to point to, not a better phrasing.
- Write every decision that must outlive the session into a file the agent reads. The next session has no other way to learn it.
- Brief each session as you would a capable colleague on their first day: the agent has the skills and none of the history.
- Distrust any statement about your codebase that the agent makes without having read the code in this session. The transcript shows whether it did.
Knowledge Check
Yesterday Ines told you, in an agent session, that refunds for a class the gym cancels are always full. Today you start a fresh session on related work. What does the agent know about her ruling?
- Nothing, unless the ruling was written into a file it loads or reads
- All of it, because sessions on one repository share a single context
- The gist of it, because the model was trained on yesterday's session
- A rough version, since the model keeps a memory of every user it serves
The agent writes a new function to convert a class time to a gym's local time, although schedule already has one. Which source does the mistake most likely come from?
- Training, because its knowledge of time zones is out of date
- Context, because it never read the file that holds the helper
- The model, because it is not capable enough to reuse existing code
- The files, because the schedule helper is broken and cannot be used
The agent keeps formatting error messages differently from the rest of the code. You add "follow our conventions carefully" to your request. Why is that unlikely to help?
- Agents ignore any instruction that appears inside a request
- The convention can only be learned by retraining the model
- The convention is written nowhere, so the words add no information
- Requests longer than one sentence are cut off before the model sees them
At the end of a long session you have settled three decisions about the refund change. What should happen before you close it?
- Ask the agent to remember the three decisions for next time
- Write them into a file that the next session will read
- Leave the session open so tomorrow continues the same context
- Repeat the decisions in the chat so they weigh more in context
The agent says confidently that refunds are calculated in booking. The transcript shows it never opened that file. How much weight should the claim get?
- Full weight, since its training covers how booking services work
- Full weight, because it would not state it so confidently otherwise
- Little, until it or you have read the code in this session
- Most of it, provided the file name appeared in a search result
You got correct