Skip to main content
Memory gives an agent knowledge that lasts across sessions. Each memory is a short text document at a path such as /conventions/testing.md, with a one-line summary. There are two kinds of memory store: Store contents never go into the prompt up front. A session sees each attached store’s name and description, and the agent browses, searches, and reads a memory only when it helps the task. What a session costs doesn’t grow with how much the agent has learned. The samples assume the rl client from Client setup.

Before you begin

  • Reading memory needs any role that can read Managed Agents. Creating stores and memories needs create permission, editing needs update, and deleting or redacting needs delete. Organization developers and admins have all of them. See Organizations and roles.
  • You need an agent. Learned memory starts once the agent’s first session starts. See Agents.

How learned memory works

  1. When a session finishes, Recursion writes a short report of what it was for, what worked, what failed, and any reusable tactic. Most sessions teach nothing, and their report says so.
  2. When enough useful reports are waiting, or on the regular schedule, a learning run reviews them and applies a small set of changes: it adds memories, refines existing ones, merges duplicates, and retires ones that no longer hold.
  3. The next session of the agent can use the updated memory.
Learning always runs automatically; there’s nothing to switch on. You choose the model it uses. A learning run is an ordinary session, so you can read its reasoning and see what it spent.

Learning states

See what an agent learned

  1. In the sidebar, click Memory. The table lists every agent with its Memories count, Learning status, and Last updated time.
  2. Click an agent. You can also open an agent and choose its Memory tab.
  3. On Memories, search, filter by Topic, or sort by Recently updated or Alphabetical. Click a memory to read it and its History.
  4. On Activity, open an update to see Why it ran, Reports read, the sessions it Learned from, and What the memory update did.
listAgentMemories returns current memories without their content, 50 per page by default and up to 100, plus topics from the whole collection. Pass topic, sort (updated or alphabetical), limit, and cursor to narrow and page. listAgentMemorySummaries returns the same summary for every agent at once. To follow learning runs, call listAgentMemoryActivity for one agent, or listReflections for the organization, filtered by agent_id, status, or triggered_by. getReflection returns one run with the sessions it read, the counts it added, updated, merged, and retired, and driver_session_id, the session that ran it.

Choose the memory model

Learning uses the agent’s model unless you set another one.
  1. Open the agent’s memory, as above.
  2. Under Memory model, choose a model. Choose Same as agent to go back to the agent’s model.
Send "memory_model_ref": null to inherit the agent’s model again. The model must be a provider/model id from listModels (see Agents). The change applies to the next learning run. Read the setting with getAgentLearning.

Create a curated store

A curated store holds reference material you write, such as release policy or team conventions. Scope it to one agent with agent_id, or leave agent_id out to make a workspace store any agent’s automation can attach. The description is shown to every agent the store is attached to, so write it as what the agent would be looking for.
Curated stores are created and edited through the API. The console’s Memory screen shows each agent’s learned memory.
The response is 201 with the store:
slug stays the same when you rename the store. origin is curated for stores you create and reflection for an agent’s learned memory.

Add memories

Keep each memory small and focused. The path is how agents find things, so group related memories under a shared prefix.
Memories in curated stores are added through the API.
path, summary, and content are all required. Create never overwrites: a path that already exists is refused, so change it with updateMemory instead. A retried create can’t destroy content.

Browse and read a store

listMemories lists one level of a store, like a directory: memories and memory_prefix entries that stand for the paths beneath them, with a count. Content isn’t included. path_prefix matches whole path segments, so /releases/ returns /releases/versioning.md and never /releases-old/notes.md.
Read by id with getMemory after a create or a search. Both reads return the full content and its content_sha256.

Update a memory safely

Pass the content_sha256 you read. If someone changed the memory since, the update is refused with 409 content_sha256_mismatch instead of overwriting their change. A different path renames the memory. Omitted fields stay as they are.
The response is the updated memory with a new head_version_id. deleteMemory removes a memory from every read path, returns 204, records the deletion in history, and frees the path for reuse.

Attach curated stores to sessions

Curated stores reach sessions through an automation’s run defaults. Every session the automation starts gets the stores in runDefaults.memoryStores, next to the agent’s learned memory. See Automations.
  • The store must be active, and either a workspace store or one scoped to the automation’s agent.
  • access is read_only or read_write. Sessions browse, search, and read attached stores the same way with either.
  • instructions is shown to the agent beside the store’s name and description, up to 4,096 characters.
In the transcript, agents use three memory tools: list_memories to browse a store, search_memories to find memories by content, and read_memory to read one in full.

Manage stores

Archive and delete apply to curated stores only. An agent’s learned memory can’t be archived, deleted, or edited by hand; its history is still readable, and you can shape it by choosing the memory model.

Review, restore, and redact versions

Every create, update, rename, delete, and retirement writes an immutable version. Versions belong to the store, so history survives a deleted memory. Each version records who wrote it (author_kind is session, api, reflection, or admin), and a learning run’s versions also carry a rationale and the evidence_session_ids behind the change.
You can’t redact the version that is a memory’s current content. To remove a leaked secret, write or restore a clean version first, then redact the old one. Redaction can’t be undone, and a redacted version can’t be restored. Versions are kept for 30 days. The recent versions of a live memory are kept regardless of age.

Write memory that helps

  • One idea per memory. Small documents are cheaper for the agent to read and easier to keep current.
  • Paths are the index. Use folders such as /releases/ and /testing/ so an agent can browse to the right place.
  • Summaries are for people and search. Say what the memory tells the agent in one line.
  • Store descriptions route the agent. Describe when to look in the store, not just what’s in it.
  • Keep secrets out. Memory is text agents read. Put credentials in vaults.

What can go wrong

For every error code, see Errors.

Limits

See Limits for every other limit.

Next steps

Automations

Attach curated stores to every run.

Agents

Configure the agent whose sessions it learns from.

Files

Give sessions input files and download deliverables.

Skills

Package procedures agents follow every time.