Memory is the polite word we use when an LLM agent remembers a document, a user preference, or a previous chat message. It sounds reassuring. It also hides the awkward part: most agent memory is just stored text waiting to be retrieved. That is useful, but it is not the same as belief. ...
Memory is usually sold as the adult upgrade for LLM agents. Give the agent a past. Give it a vector database. Give it episodes, reflections, mistakes, summaries, and a long enough context window to remember every tiny embarrassment. Surely it will become more reliable. The RPMS paper is useful because it interrupts that comforting story with a less fashionable point: memory can make an agent worse when the world has hard action rules.1 ...
Mistakes are cheap until an agent repeats them. A human worker who keeps failing at the same task usually leaves traces: a blocked aisle, a missing tool, a wrong form field, an error message, a process exception. A competent manager does not simply tell the worker to “try again with more confidence.” The useful move is more boring and more valuable: identify the pattern, write the repair rule, and make sure the next attempt starts from the point of failure rather than from the beginning. ...
Memory has become the awkward invoice attached to every serious AI agent demo. A short chatbot can survive on vibes. A long-running coding assistant cannot. After a few weeks of debugging sessions, architecture debates, config changes, rejected fixes, and “remember we tried this already?” moments, the agent’s past becomes valuable. It also becomes inconveniently large. The obvious solution is to stuff more transcript into the prompt. The obvious solution is usually how software gets expensive before it gets useful. ...
Logs are where automation failures usually go to become archaeology. A business deploys an AI agent. The agent calls APIs, checks intermediate states, makes assumptions, retries after errors, occasionally succeeds by accident, and sometimes discovers a genuinely efficient route through a workflow. The full execution trace is stored somewhere. In theory, this is valuable evidence. In practice, it often becomes a swamp: too verbose for managers, too unstructured for engineers, and too raw for the next agent run. ...
Mistakes are useful only when they are converted into something operational. That is the small, inconvenient detail often missing from agent hype. An LLM agent can fail at a web-shopping task, wander through a simulated room, push the wrong Sokoban box, or uncover the wrong MineSweeper cell. Fine. Failure happens. The useful question is not whether the agent failed. The useful question is whether the system can extract a reusable signal from that failure before the next attempt. ...
Meetings are where context goes to suffer. A product manager remembers the customer constraint. A data engineer remembers the schema problem. A finance lead remembers the cost ceiling. A compliance officer remembers the rule nobody else wanted to read. The trouble begins when everyone is forced to work from the same swollen transcript, the same vague summary, or the same “shared memory” that turns specialists into slightly different versions of the same forgetful intern. ...
Workflow diagrams age badly. A process that looked clean in January usually becomes a small archaeological site by March: one more exception, one more conditional branch, one more “temporary” manual approval that survives longer than the intern who added it. This is how many AI-agent projects quietly become ordinary software projects with a chatbot sitting on top, smiling politely while humans keep repairing the plumbing. ...
Click. That is where most web-agent demos become either impressive or mildly tragic. The model reads the instruction, understands the goal, produces a confident plan, and then clicks the wrong thing. Or it clicks the right thing before a modal appears. Or it scrolls, forgets why it scrolled, repeats an action, and quietly turns a three-step workflow into interpretive dance. ...
Memory is easy to sell. Give an AI agent a bigger context window. Add a vector database. Store every user preference, meeting note, support ticket, and half-correct instruction that ever passed through the system. Then call it “persistent memory,” because apparently a drawer full of old receipts is now intelligence. The problem is that agents do not fail only because they forget. They also fail because they remember too much, too flatly, and too obediently. Old facts compete with new ones. Repeated but trivial details crowd out rare but important constraints. Retrieval brings back something semantically similar but temporally wrong. The agent sounds confident because the database found something. Very helpful. Very dangerous. ...