What is agent memory? Shared, private, and owned by the org
Agent memory is durable, searchable state that outlives one conversation, client or agent. How it differs from a context window, and who owns it.
Agent memory is durable, searchable state that outlives one conversation, client or agent. It holds preferences, decisions, relationships and operating constraints, so a new session starts informed. The context window empties when a session ends. Memory is written and read by tools, scoped to a person or an organization, and kept until someone changes it.
memory__remember, scope "shared".
memory__search_memory for "date format" found it: dates in the API are ISO strings.How is memory different from the context window and CLAUDE.md?
Three things get called memory, and they do different jobs.
The context window is what the model sees right now: the conversation, the files it read, the tool results. It is complete and immediate, and it is gone when the session ends or the window fills.
Instruction files such as CLAUDE.md or AGENTS.md are rules you wrote in advance. They are static, live in one repository or in one user-level file on one machine, and are read by one client. They are the right place for standing rules ("search memory before you plan"). They are a poor place for facts that change.
Durable memory is state the agent writes and searches through tools. Through CoreSpeed it lives in the organization, so moving from Claude Code to Codex, or replacing the agent, does not mean rebuilding preferences, facts and decisions. The three work together: rules in the file, facts in memory, the current task in the window.
| Context window | Instruction file | Durable memory | |
|---|---|---|---|
| Lifetime | One session | Until edited | Until archived or deleted |
| Scope | One conversation | One repository or one machine, one client | A member or the whole org |
| Found by | Already present | Read at start | A search query |
| Written by | The conversation | A person | The agent, through tools |
| Maintained | Never | By hand | Versions, archive, proposals |
Who owns agent memory?
The organization does. Every write carries a scope: "private", the default, or "shared", which must be asked for explicitly. A private memory is visible to the member who saved it and their clients. A shared memory is visible to everyone in the organization, including agent principals.
The caller's identity comes from authentication. An agent cannot supply a different user id in the request to read someone else's private memories. That boundary is enforced in Postgres by row-level security, so it holds even when application code has a bug. The memory docs describe the full tool set: memory__remember, memory__search_memory, memory__get_memory, memory__update_memory, memory__delete_memory, memory__list_memory, memory__link_memories and the rest.
How does retrieval work?
memory__search_memory runs a hybrid search: exact and relaxed lexical matching, entity aliases, and vector similarity, fused into one ranking. There are no separate knobs. A query that names a person, a project or a phrase lands on lexical matches; a query that paraphrases lands on vector matches; both feed the same list.
Long memories come back as excerpts. A memory of 1,200 characters or fewer is returned whole. A longer one is excerpted, with truncated: true and full_length on the result, and for a search hit the excerpt is the passage that matched. The whole result is bounded too: the lowest-ranked rows are dropped, omitted: N says how many, and the top hit is always returned. Call memory__get_memory with the id when you need the full text.
We published how far this retrieval goes in the LongMemEval post. On LongMemEval-S, 500 questions, retrieval recall at 10 stayed 0.99 throughout, and the end-to-end score reached 94.2 with a flash-class reader. The gains came from the evidence budget, the reader model and the reader instructions. The engine, Lore, is open source at https://github.com/corespeed-io/lore.
How does the agent know when to use memory?
On every MCP initialize, the CoreSpeed server sends instructions with the session: search memory with two or three short queries at the start of a non-trivial task, and save durable facts after significant work. It also sends a short index of the caller's pinned memories. Pinning a memory means "surface this at the start of every session".
Those instructions are worth repeating in your own instruction file, so the habit holds in every client:
At the start of a non-trivial task, call memory__search_memory with two or three short queries.
After significant work, save durable decisions and conventions with memory__remember.
Ask for scope "shared" only when the whole team should see it.What belongs in memory?
A preference ("the team reviews pull requests in the morning"). A product decision ("dates in the API are ISO strings"). A named relationship ("the billing contact at the vendor is their finance lead"). An operating constraint ("nothing goes to the public channel without review").
What does not belong: a transcript archive, a secret store, application data. Memory enforces nothing. It is context, and policy lives elsewhere, in approvals, spend caps and the audit trail. A memory that says "never post about pricing" informs the agent; an approval policy that says the same thing stops the call.
Memory operations cost 0 credits per call. Storage quotas and rate limits protect the shared service: the Free plan includes 200 MB of memory and Pro includes 2 GB. See pricing.
FAQ
Is agent memory the same as RAG?
Retrieval is one part of it. Memory also means writes with a scope, ownership by an organization, maintenance (archive, versions, proposals) and recall at session start.
Can one agent read another member's private memories?
No. Scope is enforced by row-level security in the database, and the caller's identity comes from authentication, never from the request body.
What happens when a fact changes?
Where memory maintenance is rolled out, archive the old memory with superseded_by naming the new one. It leaves search and lists, nothing is deleted, and restore brings it back.
Does memory cost credits?
No. Memory operations are 0 credits per call. Plans set the storage quota.