AI agent memory
AI agent memory is what an agent knows that outlives the moment it's thinking. By default that's almost nothing: an agent's working memory is its context window, and the window closes when the run ends. The next run — even of the same agent — starts blank. "Give it memory" usually means bolt on a vector store so it can recall snippets of its own past text. That helps, but it answers only one of the questions an agent actually has.
The memory an agent needs to *act* is bigger than recall. What's the plan, and what's already done? What did we decide, and why — so I don't reopen it? What did the last run learn that I shouldn't rediscover? And critically: is any of this shared with the other agents and the human, or is it locked in one session no one else can see? Recall of past chat text answers none of those. This is the difference between an agent that remembers and an agent that just searches its own transcript.
Why agents forget — and why a vector store alone isn't memory
An agent forgets for a structural reason, not a fixable bug: everything it "knows" mid-task lives in the context window, and the window is per-session and finite. End the run, start a new one, and the slate is wiped. Schedule an overnight job, open a second terminal, spawn a subagent — each is a fresh mind with no access to what the others hold. The forgetting isn't the agent being careless; it's the absence of anywhere durable to keep what it knows.
The standard fix — embed past messages into a vector store and retrieve the similar ones — is recall, and recall is a fraction of memory. A pile of fuzzy-matched text fragments has no structure: it can't tell you a task is claimed, that a decision was settled and shouldn't be reopened, or that a "done" was actually verified. It's also usually private to one agent's history. Real working memory has to be a record you can query and trust — tasks with state, decisions that hold, knowledge with provenance — not just a search box over old conversation.
Four kinds of memory. Recall is only one.
Strip "give the agent memory" down and it's four different needs wearing one word. Recall is only the third of them — and even that one breaks if the memory isn't shared.
It has to outlive the session
The context window is scratch paper, not memory — it's gone when the run ends. Anything the next run needs has to live somewhere durable it can read on demand: the plan, the open work, what's finished. Keep it only in the window and every run re-learns the project from zero, or worse, acts on a stale copy a human pasted into the prompt.
Where an agent's memory should live →It has to be structured, not a pile of text
A vector store recalls fragments that look similar to your query. It can't tell you a task is owned, that a decision is settled, or that a result was verified — because those are states and records, not paragraphs. Memory you can act on is typed: tasks with status, an append-only decision log, knowledge notes — queryable as facts, not fuzzy-matched as prose.
vs a vector store / agent memory →Recall you can trust
Recall is real memory's third job — surfacing the relevant past finding so the agent doesn't redo the research. But retrieval is only as good as what's stored: a note that was wrong, stale, or never verified poisons every run that recalls it. Memory needs semantic search and a notion of what's trustworthy — verified done, append-only decisions, provenance on what it learned.
How you know an agent actually finished →It has to be shared, not private
Memory locked in one agent's history isn't team memory — the second agent, and the human watching, can't see it. The moment more than one agent works the project, what each remembers has to be readable by all of them and by you. Otherwise agent B re-litigates what agent A settled, because A's memory of the decision never left A's session.
When two agents can't see each other's work →How Ledgenter is an agent's memory
Ledgenter is one MCP server — 61 tools over a single typed contract — and durable shared memory is its whole point. The work an agent needs to remember lives in typed rooms every agent and the human share: projects and a task dependency graph (what's planned and done), an append-only decision log (what was settled and why), a searchable knowledge base with semantic recall (what was learned), an audit of who did what, and handoffs that carry context to the next worker. Recall is in there — but as one room among several, not the whole house. Tenant isolation is sealed at the database, so one workspace's memory is never visible to another's.
The effect is an agent that walks into a project it has never seen and is already oriented. It calls whoami, reads the open work that's now no one else's, searches the knowledge base before redoing research, sees which decisions are settled, and writes back what it did and learned so the next run inherits it. The next run — minutes or a week later, same agent or a different tool — picks up with all of it. No re-briefing, no pasted context, no rediscovery. Point any MCP-capable host at it and the tools show up in about five minutes.
▸ whoami
{
"actor": { "handle": "claude-code", "kind": "agent" },
"mode": "loop",
"inbox": 0,
"open_tasks": [
{ "seq": 42, "title": "Wire the overdue sweeper", "status": "ready" }
],
"since_last_seen": { "new_activity": 3 },
"hint": "claim the next ready task"
}The first call of every run. Each agent gets its identity, the unblocked work that is now no one else's, what changed since it was last here, and a hint — the durable shared memory that lets a run a week later pick up as if it had never left.
Keep reading.
The ones that actually come up.
What is AI agent memory?
It's what an AI agent knows that survives past the moment it's reasoning. Its in-session working memory is the context window, which is wiped when the run ends, so durable memory has to live outside the session: the plan and work state, the decisions that were settled, the knowledge that was learned, and the history of what happened — kept somewhere every run can read. Recall of past text is one part of that, not the whole of it.
Isn't a vector store enough to give an agent memory?
A vector store gives an agent recall — it retrieves fragments of past text that look similar to a query. That's useful, but it's only one kind of memory. It can't represent that a task is claimed, that a decision is settled and shouldn't be reopened, or that a result was verified, because those are structured states, not prose to fuzzy-match. And a vector store is usually private to one agent's history. Working memory you can act on needs structure, trust, and sharing on top of recall.
Where should an agent's memory actually live?
Outside any single session, in a durable store every run and every agent can query — not in the context window (wiped each run) and not in a markdown file or the prompt (goes stale the moment a second agent edits it, and can't be claimed or verified). In practice that's a database with a typed contract: tasks with state, an append-only decision log, and a searchable knowledge base, reachable through one interface every agent shares.
How is this different from multi-agent coordination?
They're two sides of the same shared state. Memory is what the work knows over time — settled decisions, learned knowledge, finished work. Coordination is how live agents avoid colliding right now — atomic claims, handoffs. Both need the same durable, shared store underneath; remembering and not-colliding are what that store buys you. Ledgenter is that store, so the same workspace serves both.
Do I need this if I only run one agent?
Often the moment your work outlives one session, yes — even with a single agent. The "other agent" that needs the memory is frequently just next week's run of the same agent, which starts blank and has to pick up where this one stopped. If everything genuinely fits in one short session and never recurs, you don't need durable memory. The need appears the instant a run has to remember something the last run knew.