Why relying on your IDE's automatic context summarizer is a trap—and how 1980s Unix boot scripts give autonomous agents an indestructible memory.
"Needs a system, right? Take notes. Specific notes... You can't trust a memory." — Leonard Shelby, Memento (2000) The 200k-Token Lobotomy: The Silent Killer of Long Agent Sessions
If you use modern agentic coding environments—whether Claude Code, Google Antigravity, Cursor, or Gemini CLI—on real production tickets, you already know the feeling of dread when a complex session crosses 200,000 tokens.
On the surface, "context compaction" sounds like a helpful platform feature. When the conversation approaches the context window ceiling, the host runtime pauses your agent, hands the entire 230,000-token transcript to a background summarizer model, replaces the history with a three-paragraph prose summary, and lets the agent keep going.
Before compaction, you and the agent had spent 45 minutes establishing subtle architectural invariants: You agreed at Step 42 that BlocSignalSelector must never subscribe directly to the root state signal inside effect because doing so ruins memoization for the 98% fast path. Your adversarial code reviewer rejected two flawed implementations in Rounds 1 and 2, and dismissed a false-positive warning about didChangeDependencies. Your workflow rules strictly forbid running git commit or git push without halting at a human approval airlock.
Then the host summarizer compresses all 280 steps into polite, generic corporate mush:
"Summary: The user and assistant are working on Issue #320 in the BlocSignal repository to support custom equality in Flutter and Jaspr widgets. Several files have been modified and reviewed. The assistant is currently addressing review feedback."
When the freshly compacted agent wakes up on the very next turn: It forgets its governance laws—and immediately runs git commit and git push without asking. It forgets why Round 1 failed—and cheerfully re-implements the exact naive bug it just spent 100 steps ripping out. It loses its place in the build graph—re-running codebase archaeology or asking you what ticket you want to work on.
Because prose summarization optimizes for narrative gist, while software engineering depends on discrete, non-negotiable invariants. Summarizing a 230,000-token compiler and architecture session into three paragraphs of prose is like summarizing an executable binary by taking a JPEG screenshot of its hex dump. The Memento Principle: Never Trust the Summary—Trust the Tattoos
In Christopher Nolan's 2000 neo-noir masterpiece Memento, the protagonist Leonard Shelby suffers from anterograde amnesia. Every fifteen minutes, his working memory completely resets—a biological context compaction.
Leonard quickly discovers a fatal rule of survival: he cannot trust scribbled scrap-paper summaries or vague impressions, because his future self will misinterpret them, overwrite them, or be manipulated by them.
Instead, Leonard builds a two-tier external memory architecture: Immutable Tattoos (Fact 1, Fact 2, ...): Permanent, write-once physical truths etched directly into his skin in a strict hierarchy that his future self must read first upon waking up. Polaroid Photographs (The Active Frontier): Concrete, verifiable snapshots of physical objects in the world (His Car, The Motel Room) with brief, factual state captions.
To make an AI coding agent immune to context compaction, we needed the exact same split: never trust the host LLM summarizer to preserve your workflow or architectural constraints. Why a Single TODO.md or PROGRESS.md Scratchpad Fails
When developers first try to work around context compaction, they usually tell their agent:
"Keep a PROGRESS.md or TODO.md file updated as you work so you can read it if context resets."
If you have tried this, you know how quickly it rots: The Destructive Overwrite Trap: Because PROGRESS.md is a single mutable file, every time the agent updates its current step at the bottom of the file, it re-generates or edits the file—gradually compressing, mutating, or accidentally deleting the architectural rules and plan constraints from the top of the file. The Monolithic Bloat Trap: Or the opposite happens: the agent appends 800 lines of stream-of-consciousness notes into PROGRESS.md, burying the active instruction pointer inside a wall of stale text that suffers from the "Lost in the Middle" attention sink.
A single scratchpad file fails because it conflates immutable laws with mutable program counters. Enter 1983 Unix init.d (rc.d): Lexical Runlevel State Files
In 1983, AT&T System V Unix introduced /etc/init.d and /etc/rc.d boot directories. Instead of one giant, fragile /etc/rc shell script that broke whenever a package tried to edit it, Unix split system initialization into numbered, lexically ordered files: