Mistake 1: Writing Too Much
The first instinct is to save everything. Every tool result. Every decision. Every draft. "We'll need it later."
You won't. Most of it will never be read again. What you actually save is buried under what you should have thrown away.
Fix: Memory should be smaller than the conversation that produced it. If the memory file is longer than the chat that wrote it, you're keeping too much.
Three things earn a place in long-term memory:
- Stable facts about the user, project, or environment.
- Decisions that affect future behavior (and the reasoning behind
them).
- Open threads the agent is expected to come back to.
Everything else is conversation, not memory. Let it pass.
Mistake 2: Writing Too Little
The opposite mistake: the agent saves a single sentence per session. "Worked on Q3 plan." That's not memory; that's a log entry.
A week later, the agent has no way to recover the context, the constraints, or the open questions from that session. The next session starts from zero again.
Fix: Memory should be enough to reconstruct intent. Not the full transcript, but enough that a fresh agent could pick up the work and ask the right questions.
The minimum useful memory note has:
- What the work is (one sentence).
- Why it matters (one sentence, often the user's framing).
- What's open (one sentence or a short list).
- What the next step looks like (one sentence).
If you can't fill those four lines, you don't yet understand the work well enough to leave it for later.
Mistake 3: Writing in the Wrong Place
The third mistake is the most expensive: memory in a place the human can't see, edit, or delete.
This shows up in three flavors:
- Inside an opaque vector store. You can't read what the agent
remembers. When the agent starts behaving oddly, you have no audit trail.
- In a single running file. Every session appends. After three
months, the file is huge and the recent context is buried.
- In a database only the agent queries. Same problem as the
vector store, dressed up.
Fix: Memory should live somewhere a human can:
- Read it without a tool call.
- Edit it with a normal text editor.
- Delete from it without a ritual.
Markdown files in the workspace, one per concern, are the boring right answer. They are searchable. They are diffable. They survive every tooling change. They are honest about what the agent is being told to remember.
How to Tell Which Mistake You Are Making
- Too much: Memory file is longer than the conversation that
produced it.
- Too little: Memory file is shorter than the "why" behind the
work.
- Wrong place: You can't read or edit the memory without a tool
call.
What To Take Away
Memory is the part of an agent that survives across sessions. Treat it like a notebook you'd hand to a colleague: small enough to read, clear enough to act on, and always editable.
The cost of getting memory wrong is invisible at first — the agent seems to be working. The cost shows up three months later when the agent can't remember what it was doing, can't remember why, and the only fix is to rebuild the memory file from scratch.
Get it right early.