Skip to Content
Platform
Core ConceptsMemory

Memory

Your agent can carry context across runs. Memory is a set of files the agent reads and writes, kept durably between tasks and private to the end user it belongs to.

How memory works

A task runs in a fresh sandbox every time, so nothing on its filesystem survives on its own. Memory is the exception: a dedicated space the agent can write notes into and read back on a later run.

The agent remembers by editing ordinary files with its normal file tools. There is nothing new to call: it writes a note, the platform stores that file durably (encrypted and versioned, on the same Files storage), and restores it the next time the agent runs.

One file, MEMORY.md, is the index. It stays short and links to focused topic files alongside it. At the start of each task the platform loads MEMORY.md into the agent’s context, so the agent always begins knowing what it has remembered and where to look for the rest.

Memory is reference context, not new instructions. The agent treats what it remembered as background it can act on, while the recipe still defines how it behaves.

Memory is personal to the end user

Memory is scoped to the end user a task runs for, within the project. When you run a runtime on behalf of a specific user (by attaching an identity such as a user_id), that user gets their own private memory: one user’s agent never reads another user’s notes, even though they share the same runtime and project.

This is what lets one agent serve many users and still feel personal to each. It remembers a user’s preferences, past decisions, and context across every session that user has.

A task that runs without an end-user identity (a one-off operational run, say) simply has no persistent memory.

What to put in memory

Memory is for durable text: preferences, decisions, notes, and small structured facts (Markdown, plain text, or JSON). Keep MEMORY.md concise, since it is what gets loaded into context; push detail into the linked topic files. Large artifacts and generated outputs belong in files, not memory.

  • Files & shares: the durable storage memory is built on, and where larger artifacts live.
  • Tasks: each task reloads the end user’s memory at the start and saves changes as it runs.
  • Organizations & projects: how end-user identity scopes memory and data per user.
Last updated on