Your agent doesn't have a memory problem. It has an uptime problem.

There is a lot of good writing right now about agent memory. Vector stores, episodic recall, context compaction, memory layers, mem0. The framing is consistent: the model can reason but it cannot remember, so we bolt on a memory system and close the gap. I think a large share of what gets called a memory problem is not one. It is a machine that turned off. Those two failures feel identical from the chat window and they have nothing to do with each other. Two different things we call memory Semantic memory is the one everyone is building. What did the user tell me three weeks ago, what is in this codebase, what did we decide about the schema. Facts and context. Embeddings help. This is real work and I am not dismissing it. Execution state is where the agent actually was. Step seven of twelve. A dev server running on port 3000. Half a migration applied. Three files edited and not yet committed. A test suite midway through. The reasoning that produced the current half-finished state, sitting in the scrollback. No vector database recovers the second one. You cannot embed your way back to a process that no longer exists. The failure that made me stop conflating them I gave Claude Code a four-hour refactor, closed my laptop to catch a train, and came back to nothing. Not a partial result. Not an error I could read. The process was gone, the scrollback was gone, and I had no way to determine how far it had gotten. Some files were modified. I could not tell whether that was a coherent halfway point or an incoherent one, which meant I could not trust any of it. So I did the only available thing: reverted, re-explained the whole task from the top, and paid for the same context a second time. Nothing was wrong with the model's memory. The model was fine. The computer stopped. I did that three more times before I accepted it was a design problem rather than bad luck. Why this keeps getting mislabeled Because the symptom presents as amnesia. You come back, you start a new session, and the agent has no idea what happened. That looks exactly like forgetting. The natural conclusion is that it needs a better memory, and there is an entire tooling ecosystem ready to agree with you. But run the counterfactual. Give that agent perfect recall of every prior conversation. It still does not know that it was midway through applying a migration when the process died, because that fact was never in a conversation. It was in a running process and a shell's scrollback, and both are gone. Perfect memory and zero uptime still loses your work. It just loses it more articulately. The scrollback is the memory nobody preserves Here is the part I find genuinely strange about the current conversation. The most information-dense artifact of an agent run is the terminal scrollback. Every command it tried. Every error it hit. Every dead end it backed out of. What it decided and, more usefully, what it already ruled out. We spend enormous effort embedding documentation the agent could re-read at any time, and we throw away the one record of what this specific agent already attempted on this specific task. That log is not a nice-to-have. "I tried X and it failed with this error" is worth more than any retrieved doc, because it is the only thing in the system that stops the next session from repeating the same failed approach. It vanishes on disconnect and almost nobody treats that as a loss. What actually survives a session boundary Worth being precise about, because the boundaries are not where people assume. Survives, if the disk persists: files, git history, anything the agent deliberately wrote down. Does not survive: the process, the shell, environment state, background servers, in-flight work, and the scrollback. Most cloud dev environments are containers with an idle reaper. The timer does not care that something is running. It cares that no human has typed anything recently, which is precisely the condition of a long unattended agent task doing its job correctly. That is the shape of the whole problem. We built agents that reason for hours, and we run them on infrastructure designed for sessions that last seconds. The unglamorous fixes Nothing here is clever, which I suspect is why it gets skipped. Run the agent under tmux or screen. If the agent is a child of your SSH session, a dropped connection is a kill signal. Under a multiplexer it is not, and the scrollback is still there when you reattach. Use a machine that does not get reclaimed. A plain VPS is fine. What you need is a disk that persists and no idle reaper, not anything sophisticated. Have the agent write a notes file, and read it first. This is the cheapest thing on the list and the closest to real memory. Not a summary of the conversation. A running log of what it did, what broke, and what it ruled out. It only works if the disk persists, which loops back to the point. Preinstall the tools before you start. Half of a bad session is the agent discovering the machine is empty and installing its way out, which is another way of losing time to state that should have already existed. None of that is an AI problem. It is 1990s systems administration, and it recovers more agent work than any memory layer I have tried. What I built instead of doing that four more times I ran the VPS-and-tmux setup for a long time and eventually got tired of maintaining it, so I turned it into a product. It is called HolyCode Cloud. It is a Linux machine in a browser tab, with the persistence problem already solved: - The process does not die when you disconnect. Close the laptop, get on a train, open the same session on your phone. The scrollback is still there. - The disk persists. Files, git history, notes files, installed packages. It is a real machine with a real volume, not a container that gets reclaimed for being idle. - The tools are already installed. Python, Node, build-essential, Playwright with its system dependencies actually resolved, Postgres, ffmpeg, pandoc, gh. Agents stop losing sessions to setup. - Six agent CLIs preinstalled: Claude Code, Codex, Gemini, OpenCode, Cursor and Pi, all on your PATH. Bring your own API key and the provider bills you directly. I do not mark up tokens. - It suspends when you are not using it and wakes in about a second, so an always-on machine does not mean an always-billing one. The honest edge, since I would rather you read it here: if the box sits idle for several days the wake is closer to a minute than a second. Nothing is lost, you just wait. And a hard crash still takes the shell with it. Files survive, scrollback does not. It is paid, and everything in the section above this one works without it. If you enjoy owning the box, own the box. That route is genuinely fine and I did it that way for a long time. The question I actually want answered I have run agents on persistent machines for months now and I still do not think the ergonomics are solved. Reattaching to read what happened overnight works, but it is clearly a workaround rather than a design. So: how are you running long agent tasks right now? Not the model. The plumbing. Are you leaving a laptop open with sleep disabled? Screen on a VPS? A cloud sandbox you have quietly noticed keeps timing out? Or have you just stopped giving agents work that takes longer than you are willing to sit and watch? That last one is the answer I hear most, and it is the one I find hardest to argue with. If the infrastructure is unreliable enough, the rational response is to stop trusting it with anything important. Which means we have models capable of multi-hour work and a habit of only giving them multi-minute tasks. I would rather fix the plumbing than train the habit. Top comments (0)