AI Agents Don't Need Memory Layers. They Need Better Prompts and Fewer Tools.

The most over-funded category in AI right now is agent memory. mem0 raised $24M. Graphiti, Cognee, Zep, Letta, Adapt — every quarter brings a new "memory layer" startup with the same pitch: your agent forgets things, and we fixed that.

They did not fix anything. They built a load-bearing abstraction on top of a problem that only exists because the surrounding system is broken in a specific way. Fix the system, the problem disappears.

Why Your Agent "Forgets" — It's Not Memory

I have audited about forty production agent systems in the last eighteen months. The reason agents appear to forget is almost never that the model lacks a memory mechanism. It is one of three things:

The tool list is too long. Twenty tools, average. The agent picks the wrong one, calls it with garbage parameters, and the user concludes the agent forgot how to do X. No. The agent never knew. Twenty tools is an attention budget you blew through on tool descriptions, not a capability boundary.

The prompt is bloated. Forty kilobytes of system prompt. Three nested personas. A rigid JSON schema for "internal reasoning." The agent cannot find the relevant instruction in the wall of text. Memory will not save you. Trimming your prompt will.

The scope is wrong. One agent is asked to book meetings, draft docs, query databases, file tickets, summarize threads. Two hours later the user asks what was the meeting time? Memory will not save you. Splitting into three purpose-built agents will.

Every memory layer I have seen deployed sits on top of one of these three failure modes. It does not address them. It papers over them.

What Memory Layers Actually Do

They capture noise. The user said the meeting got moved to Thursday at 3 two turns ago. The memory layer indexes it. Next session, it injects that fact into the prompt — whether or not it is relevant. Your agent confidently acts on stale state.

They hallucinate. The summarization step is itself an LLM call. It loses information, invents information, compresses in ways the next session cannot detect. I have watched memory layers summarize a multi-turn negotiation into user discussed project timeline and inject that non-fact into a critical turn three days later.

They drift. Every team I have watched adopt a memory layer has, within six months, hired someone to maintain it — debugging why yesterday's memory is corrupting today's decisions.

What Actually Works

A well-prompted agent with five tools and a tight scope will outperform a poorly-prompted agent with fifty tools and a memory layer every time, on every metric that matters to the user. Four changes cover most of it:

Cut the prompt to under 4KB. Make every line earn its place.

Cut the tool list to five or fewer. If the agent cannot fit the tool descriptions in working memory, it cannot use them reliably. If you need more, route them through a sub-agent with its own narrow scope.

Split the agent by job. A customer support agent should not also be writing blog posts. Three agents, three prompts, three small tool lists. No memory layer needed.

Use a long context window. Frontier models handle 200K to 1M tokens with 95%+ needle-in-a-haystack accuracy. If the relevant "memory" fits in 100K tokens, put it in the prompt. Memory layers were a workaround for tiny context windows. That workaround is now worse than the original problem.

The Take

The agent memory industry is a category error with a Series A. It is selling infrastructure for a problem that does not exist in well-designed systems and actively makes worse in poorly-designed ones. The best case for adopting one is we do not want to fix our prompts and tool lists. That is a tax on bad architecture.

Stop reaching for a memory layer. Reach for a shorter prompt. Fewer tools. Tighter scope. Longer context window.

Your agent does not have a memory problem. Your agent has a design problem. The memory industry will not tell you that, because the alternative is admitting their product solves a problem you should never have had.

— Mr. Technology