The model sees one buffer and nothing else, so everything the agent knows on this turn is something you decided to put there. Six topics on filling it well: the reframe that turns prompt writing into selection under a budget, the system prompt you fully control, a token budget enforced in code, compaction that does not drop the fact the ticket depended on, the degradation that arrives long before the window is full, and the caching that makes re-sending the same prefix twelve times affordable.
6 topics
The second wound opens in this chapter, and it opens quietly. On long Sundry threads the agent started quoting the company's own 30-day return window at buyers whose seller runs the statutory 14 days. Nobody deployed anything. The system prompt was unchanged, the tools were unchanged, the model was unchanged. What changed is that the threads got longer, and somewhere past turn fifteen the correct policy stopped being the one the model reached for.
That is not a bug you can find by reading code, because the code did exactly what it was written to do: append a message and call the model again. Chapter 2 established the arithmetic underneath it — every turn re-sends everything, so a twelve-turn ticket bills 87,960 input tokens for a context that peaks at 13,380. This chapter spends that arithmetic. What goes into the buffer, what it costs on every remaining turn, what to cut first, and what happens to quality long before the window is anywhere near full.
Two of these topics carry weight beyond the chapter. Topic 27 has to compress a long thread without dropping "already refunded $40" — a summary that loses that line re-opens Chapter 3's double-refund wound by a completely different route, so irreversible actions live in structured state that compaction cannot touch. Topic 29 is where the cost story starts paying: ordering the context stable-to-volatile took Sundry from $0.41 a ticket to $0.14 before any of Chapter 13's work. The drift itself is named and measured in Topic 28, mitigated here, and properly closed with retrieval in Chapter 6.
One buffer, five tenants, and only one of them written by you
Room for the answer
Subtracted before anything else is allowed in. Spend it on one more tool result and the reply stops in the middle of a sentence, which the loop has to handle as its own outcome.
Tool results
Whatever your APIs happened to return. The only tenant that scales with how hard the ticket is, and the one nobody reads end to end.
Conversation history
The buyer's words and the model's own replies, one exchange longer every turn. Somewhere past turn fifteen this is where the correct policy stops being the one the model reaches for.
Tool schemas
Fixed until somebody connects another server, then fixed again at a larger number. They travel with every request whether the ticket needs any of them or not.
System prompt
The part you control completely, and the part that gets the afternoons. A twelve-turn ticket re-sends all five tenants twelve times over: 87,960 input tokens billed for a context that peaks at 13,380.