A housing authority runs a long agentic session that reads forty case files, extracts each household's recertification date, and at the end writes a single consolidated waitlist report. Partway through, automatic compaction fires. The agent then produces a report covering only the last few cases and describes the earlier ones vaguely. What is the best explanation and remedy?

A long agentic session that accumulates forty extracted values purely in the transcript is storing results in the least durable place available. Context is a working surface, not storage, and the housing authority's vague descriptions of the early cases are the visible edge of data that no longer exists in the window at all.

Automatic compaction condenses earlier turns, tool results included, into a summary so the session can continue past the context limit. That summary preserves the thread of what happened rather than every field of every prior tool output, and it can fire mid-task. Appending each household's recertification date to a durable file as it is found, then building the report from that file, keeps only a pointer in context while the data sits somewhere compaction cannot touch.

Compaction does not corrupt tool definitions, since the tools remain available and callable, so re-registering them recovers no data; the failure is missing input context rather than a truncated response, so raising max_tokens cannot restore what is gone from the window; and compaction can be invoked manually but also runs automatically as the limit approaches, so blaming the operator misdiagnoses the cause and leaves the next long run to fail identically.

Exam caveat: externalizing results is necessary but not sufficient, because the agent also has to know the file is the source of truth after a compaction, which usually means a standing instruction plus an explicit checkpoint step. Operational check: force a compaction mid-run, ask for case number three, and confirm the agent reads the file rather than answering from recollection.