Should Your Agent Remember That, or Just Look It Up Again?
Two questions sort every fact an agent encounters into "write it down" or "fetch it fresh" — and getting the sort wrong is how an assistant ends up confidently quoting a meeting that moved last week.
You are building a personal assistant agent. In its first week it learns that your standup is at 9:30, that you dislike calls before 11, and that the budget spreadsheet lives in the shared drive. Three facts, and only one of them belongs in memory.
The default instinct when adding memory to an agent is to save everything interesting. That instinct produces an assistant that eventually tells you your standup is at 9:30 three weeks after the team moved it to 10:00. It says this with total confidence, because as far as it knows, it remembered correctly.
Two ways for an agent to know something
- Remembered — written into a memory store and pulled into the prompt at the start of a session. Free at read time, always present, and frozen at whatever it was when written.
- Looked up — fetched with a tool call at the moment it is needed. Costs a round trip, might fail, and is current.
Beginners tend to treat these as a capability ladder, where memory is the advanced version. They are not a ladder. They are two answers to a question, and the question is about the fact, not about the agent.
First question: does this fact change?
The standup time can change. The spreadsheet's contents change constantly. Your dislike of early calls will probably outlive both.
⚠️ Stale memory is worse than no memory. An agent with no memory of your calendar says "let me check" and then checks. An agent with a remembered calendar answers immediately and wrong, and there is no signal in that answer telling you which one you got. Absence of knowledge is visible; staleness is invisible.
So the first filter is blunt: if it can change without the agent being told, do not remember the value.
Second question: does a system already own it?
If some system is the authority on a fact — the calendar, the ticket tracker, the file store, the billing database — then a copy in memory is a cache. Caches need invalidation, and an agent memory store almost never has any. Nothing tells it the meeting moved.
That leaves a clean split:
- A system owns it → look it up. The tool call is the answer.
- Nothing owns it → remember it, because memory is the only place it can live.
The second bucket is bigger than it first looks, and it is where memory earns its keep. No system stores that you prefer bullet-point summaries, that you already tried the vendor's export tool and it choked on large files, or that "the quarterly doc" means the finance one and not the board one. Those facts have no home except the agent's memory, and they are exactly the facts that make an assistant feel like it knows you.
The sort, applied
Take the week's worth of facts and run them through both questions:
| Fact | Changes? | Owned by a system? | Verdict |
|---|---|---|---|
| Standup is at 9:30 | Yes | Calendar | Look it up |
| Budget spreadsheet's numbers | Yes | Shared drive | Look it up |
| No calls before 11 | Rarely | No | Remember |
| Prefers bullet-point summaries | Rarely | No | Remember |
| "Quarterly doc" = the finance one | Rarely | No | Remember |
| Budget spreadsheet lives in the shared drive | Rarely | Sort of | Remember the location |
That last row is the interesting one, and it is where the useful pattern falls out.
💡 Remember the pointer, look up the content
The location of the spreadsheet is stable. Its contents are not. Splitting the fact in two gives the best of both:
memory: "budget spreadsheet" -> drive://finance/budget-2026
runtime: read(drive://finance/budget-2026) at the moment it is needed
The agent starts every session already knowing where to look, which is the part that would otherwise take three tool calls to rediscover. It fetches what is there fresh, which is the part that goes stale.
This generalizes past file paths. Remember that the support queue is the thing to check every morning; look up what is in it. Remember which colleague owns deployments; look up whether they are on call today. Memory holds the map, tool calls read the territory.
✅ What to write down
Facts that survive the sort are almost always one of four kinds:
- Preferences — how you want things done, in what format, at what time.
- Vocabulary — what your shorthand means, which "the doc" is the doc.
- Pointers — where things live, who owns what, which tool answers which question.
- Outcomes — what was tried and what happened, so the agent stops re-suggesting the thing that failed.
None of these has a system of record. All of them are stable enough that a copy stays true.
❌ What not to write down
Anything with a timestamp attached, anything with a number that a system computes, anything phrased as "currently." If a fact would need an "as of" date to be honest, it belongs in a tool call.
When you genuinely must cache something volatile — an expensive lookup, a slow API — store it with the time it was written and have the agent say so: "as of this morning, three tickets were open." A dated claim is checkable. An undated one is a guess wearing a suit.
The payoff is smaller memory, not bigger
Filtering this way keeps the memory store short, which matters more than it sounds. A memory small enough that a human can read it in a minute is one you can audit when the agent says something odd, and one that fits in the prompt without crowding out the actual task. A memory that accumulated every fact the agent ever saw is neither.
Before saving anything, ask whether the agent could get this fact again in one tool call. If it could, let it.