Why AI assistants forget - and how we taught ours what to remember

AI assistants forget because their working memory is finite: when it fills up, older detail gets compressed into a summary, and a generic summary keeps the wrong things. We wrote our own compaction policy - keep the data and the reasoning, discard the journey - and it changed how reliable our AI operations work is.

Every large language model has a context window - a finite working memory. Long working sessions fill it. When that happens, the session does not stop; the older part of the conversation is compressed into a summary and work continues on top of the summary. Whatever the summary dropped is gone.

We run AI agents in production every day - on infrastructure work, on monitoring, on this very website - so we hit this constantly. And we learned the hard way that default summaries keep the wrong things.

What a generic summary throws away

A generic summariser optimises for narrative: what were we doing, roughly how was it going. It reads like minutes of a meeting. But operations work does not run on narrative - it runs on specifics. In one of our working sessions, an automatic summary kept just three of the dozens of IP addresses, host names and system identifiers the session had touched. The story survived; the data did not. The next hour was spent rediscovering facts the AI had already known.

Worse than losing data is keeping a wrong conclusion. Early in a session an AI (or a person) forms a theory about a fault. Later, the theory is disproven. A naive summary happily carries the original theory forward as fact - and once it is in the summary, it reads as established truth for the rest of the job.

The fix: tell it what to keep

The context squeeze is a hard constraint - you cannot opt out of it. What you can do is control what survives. So we wrote a compaction policy - a standing instruction the AI applies whenever it condenses its own memory. The short version: keep the data and the reasoning, discard the journey.

In practice:

• Environment first, as a named section. Every host, address, port and path touched, as a flat list. An instruction like “keep the IPs” gets quietly dropped under pressure; a mandatory section cannot be skipped without being visibly empty.
• Verbatim or not at all. Versions, commands, error strings, config values with before-and-after. If an exact value is unrecoverable, the summary must say “unknown - lost in compaction”. Never a guess: a plausible wrong value is far more dangerous than an honest gap.
• Provenance markers. Every claim carried forward is tagged measured, observed or assumed. We adopted this after an unverified inference travelled through two days of sessions as flat fact - one actual test disproved it in minutes.
• Carry the correction, not the history. When a conclusion is later proven wrong, only the correction survives. The disproven theory is not carried “for context” - context is exactly how wrong ideas re-enter.
• Decisions belong to the owner. A summary records what was decided - by a human. The AI’s own recommendations are labelled as proposals, so advice never quietly hardens into policy.

None of this is exotic. It is the same discipline as a good engineering handover - written down once, applied every time, by a machine that never gets tired of applying it.

The other half: caching

Compaction is about surviving a full memory. Caching is about not paying for the same memory twice. When a conversation’s unchanged history can be reused from cache instead of being re-processed every turn, the effect is dramatic - in our own testing, response start-up on a long session dropped from just over four seconds to about a quarter of a second once the cache was actually being reused. At API prices, cached input tokens are billed at a fraction of the full rate, so the same discipline that makes sessions reliable also makes them markedly cheaper.

The catch: caching only pays off if the start of the conversation stays byte-for-byte stable. That is an architectural decision - where system instructions live, what gets injected per-turn - and we are currently reworking our internal AI chat stack around exactly this.

Why this matters beyond our lab

This is the unglamorous layer of running AI for real: not prompts, not model choice - memory hygiene, provenance, and knowing what your tools silently discard. It is also, we would argue, the difference between using AI and operating it.

That distinction is the whole premise of a managed intelligence practice. The AI that watches our clients’ systems is subject to the same rules you just read: exact values or an honest “unknown”, corrections over history, and a human owning every decision.