You come back on Monday and the agent picks up where it stopped. It knows which files it touched on Friday, which test was still red, what you decided about retries. It read all of that out of a file it wrote to itself before shutting down, and for a moment the thing looks like it remembers. Then it opens one of those files to make the change, and the function it is looking for is not there. Somebody renamed it on Saturday. The memory was intact. What had gone stale was the index underneath it, still describing a repository that no longer exists.

The board is not the building

Picture a small hotel, eighty rooms over six floors. Behind reception hangs a board with one row per room and a marker on each: occupied, empty and clean, empty and not yet cleaned. Nobody walks six floors to answer somebody standing at reception. They read the board. The board is not the hotel. It is a cheap, compact claim about the hotel, and it is useful exactly as long as somebody keeps it honest.

Keeping it honest is a small job done often. A cleaner finishes two rooms, two rows change. Nobody rewrites the whole board because two rooms changed. That is incremental indexing: the harness keeps the index on disk, compares the current state of the files against what it indexed last time, and recomputes only the parts affected. Edit three files and the search updates those three chunks and reuses the index for everything else. The full rebuild is held in reserve for one case only — when the rows stop meaning what they meant. The hotel renumbers its floors, or “clean” comes to mean a longer checklist, and every marker on the board is now a lie told in good faith. In an index, that is a change of embedding model, or of how text is cut into chunks.

Knowing where costs less than knowing what

Reception keeps two memories, and they cost different amounts. The board says which rooms exist and what state they are in. The folder in the drawer says what happened during a particular stay: the late arrival, the broken kettle, the disputed bill. You glance at the board constantly. You pull a folder rarely, because it takes longer and you need a reason.

A two-tier cache splits those same two costs. One tier holds listings and metadata — where things are, what they are called, when they changed — and holds them for a fixed time to live. The other holds the bytes of the objects already opened. Scan a remote bucket once and the call goes out over the network; search it again inside the TTL and the answer comes from the local index; read the same report twice and the second read never leaves the machine. What this buys you is a decision you can actually make, because discovering where data lives and reading what it says are now separate bills, and you can afford to pay one far more often than the other. The failure is separate too. A cache with no expiry and no invalidation does not go quiet when it falls behind. It answers, confidently, with yesterday.

A stale index is worse than none

This is what external memory is, under the friendly name. A state file the loop reads at the start of a run and writes back at the end is a claim about the world, parked outside the conversation so it can outlive one. It stays true only while something keeps realigning it, which is why serious loops ship a second tool with no other job than drift detection: comparing what the state file says the loop is doing against what the loop actually did. The night manager who walks the floors and fixes the board.

The same discipline shows up at the smallest scale. When a long session is about to be compacted, a hook can build a structured snapshot first — a couple of kilobytes, written in priority tiers, so that if the budget gets tight the vague material goes first and the active files, the open tasks and the decisions always survive — then inject it back on the other side.

None of this is intelligence. It is bookkeeping, done often enough to stay true. Your agent does not remember. It looks something up, and a memory is only as true as its index is fresh.