How to give your agent memory that survives sessions and clients
Two standing rules, a scope choice, and a habit of saving decisions give any agent memory that outlives the session and the client it ran in.

Memory that survives sessions is a store outside the agent's context window, owned by your organization. The agent searches it at the start of a task and writes to it after significant work. On CoreSpeed it is reached through the memory__* tools on the same MCP server as your apps. Replace the client or the agent; the facts remain.
What does the agent need to do each session?
Two habits. Search memory before planning, with two or three short queries: the task topic, the project name, the user's preferences. Save durable facts after significant work, one fact per memory__remember call.
CoreSpeed already tells every client this. On each MCP initialize the server sends instructions that ask the agent to search at the start of a non-trivial task and to save after significant work, plus a short index of the caller's pinned memories. Pinning means "surface this at the start of every session". Putting the same two rules in your project's instruction file makes the habit explicit for that project and lets you add what to search for.
## Memory
- At the start of a non-trivial task, call `memory__search_memory` with two
or three short queries before planning. Say which memory shaped the plan.
- After significant work, save durable decisions and conventions with
`memory__remember`. Use `scope: "shared"` for anything the team should know.
How do you set it up?
- Connect CoreSpeed. Give your agent the line
set up https://corespeed.io/SKILL.md. It fetches the skill, adds the MCP server at user scope, signs you in and asks which apps to connect. The server ishttps://api.corespeed.io/mcp; per-client steps are on the MCP page. - Add the two standing rules above to the instruction file your client reads:
CLAUDE.mdfor Claude Code,AGENTS.mdfor Codex. - Decide the scope of each write.
privateis the default and only you can read it.sharedmust be asked for explicitly and is readable by every agent in the organization. - Save the right things. A preference, a product decision, a named relationship, an operating constraint. Keep each memory short; a memory of 1,200 characters or fewer comes back whole in search results, and longer ones come back as the excerpt that matched.
- Pin the few memories every session should begin with. They appear in the index the server sends on initialize.
- Correct by archiving, where memory maintenance has reached your organization.
memory__archive_memorytakes a stale memory out of search and names its replacement withsuperseded_by. Nothing is deleted, andmemory__restore_memorybrings it back. - Look at it. Dashboard → Memory lists memories, searches them, draws the link graph, and deletes content.
| Scope | Example | Who reads it |
|---|---|---|
private (default) | "I write PR descriptions under 200 words." | you, from any client |
shared | "Billing exports go to the finance page in Notion." | every agent in the organization |
Three things do not belong in memory: a transcript archive, a secret, and application data. Memory is context, not policy; it tells the agent what is true and does not stop a write. If a rule must be enforced, put it in an approval policy.
Why does a correction need an archive?
A shared memory is read by every agent in the organization. A correction saved next to a stale fact does not stop the old one from being retrieved, so both come back and the agent has to guess. Archiving retires the old one, and the superseded_by field points a reader of the old id at the new one.
A teammate's memory changes through a proposal. memory__update_memory and memory__archive_memory on it take a reason and answer status: "proposed". The author, or an org admin, merges or rejects it in Dashboard → Memory → Proposals, like a pull request. An agent can propose and never merge. A proposal is pinned to the memory's version; if the memory changes first, the proposal is recorded outdated. Three prior versions are kept, and pending proposals expire after 30 days. This maintenance set is rolling out organization by organization; until yours has it, the archive and proposal tools are absent from tools/list.
How does retrieval work, and what does it cost?
memory__search_memory is one call with no knobs. Underneath, retrieval is hybrid: exact and relaxed lexical matching, entity aliases, and vector similarity, fused into one ranking. A result is bounded; if the matches would exceed what a client can receive, the lowest-ranked rows are dropped and omitted: N says how many. The top hit is always returned. Read any memory in full by id with memory__get_memory.
The engine behind it is open source as Lore, and the LongMemEval post describes how retrieval recall at 10 stayed at 0.99 while the end-to-end score moved with the evidence budget and the reader.
Memory operations cost 0 credits per call. Storage quotas protect the shared service: 200 MB on the Free plan and 2 GB on Pro. The boundary between members is enforced in Postgres by row-level security; caller identity comes from auth, and an agent cannot supply a different user id. Details are on the memory page.
FAQ
Is the conversation carried over to the next client? No. Memory holds facts, preferences and decisions the agent chose to save. The transcript stays in the client that produced it.
Can a teammate's agent read my private memories? No. Private memories are readable by the member who created them. Shared memories are readable by every agent in the organization.
Can memory stop my agent from doing something? No. Memory is context. Use Smart Approval to gate a write.
How do I remove everything? memory__clear_all_memory after explicit confirmation, or delete from Dashboard → Memory. Turning the memory capability off hides the tools and keeps the data.