Main idea

Writing three cells into a spreadsheet took nearly fifty seconds. The reflex is to blame the service: it is slow, it will have to be replaced.

That isn't where the time went. Before writing, the assistant searched for the file, fetched its metadata, checked the tab, looked at the columns, worked out where to insert. Five recognition operations, redone at every call — while none of it changed from one time to the next.

The slowness was therefore not in the writing. It was in the rediscovery of an already stable context that nobody had bothered to declare.

Why it matters

The diagnosis changes the answer. Attributed to the tool, the slowness leads you to change it — costly work with no effect. Attributed to the rediscovery, it is treated by writing down once what doesn't move: the identifiers, the structure, and the explicit ban on going to look them up.

It is a broader family of defect: an agent that doesn't know what it knows starts over. The cost shows up nowhere as an error, only as an impression of heaviness.

Layer added by "Adding session memory, like OpenClaw" (2026-03-22). The rediscovery isn't always paid for by the machine. Reopening Claude Code on a Monday morning on a bug left hanging on Friday costs a quarter of an hour: re-explaining the architecture, restating what has already been tried, recalling the decisions made. The tool answers fast — it is the human who redoes the recognition work, and redoes it at every new session rather than at every call. The remedy is the same: write down once what doesn't move, instead of saying it again.

Nuances and limits

Freezing a context assumes it really is stable. If the structure changes, the agent will work from an out-of-date map and fail all the more obscurely for no longer checking anything.

And part of the slowness remains attributable to the tool: the diagnosis shifts the main cause, it doesn't cancel it.

Open questions

• How do you detect that a context declared fixed has stopped being so?