Agent Memory

The Memory page (/characters/{id}/memory) is where you browse everything your agent knows and remembers. It is one store, addressed by path — not a set of database connections you configure.

Memory persists across runs. A task that writes a file there will find it again on its next run, tomorrow, or next month.

One Store, Six Sections

Every piece of an agent's memory lives at a path like kv/leads/qualified.md. The first segment is the section, and it decides who can read the file and when the agent sees it.

Use the filter pills at the top of the page to narrow the tree to one section, or leave it on Everything.

How a Run Sees It

Before a task runs, the platform materialises the agent's memory as an ordinary directory tree at /workspace/brain/ inside the container. The agent reads and writes plain files — there is no API to learn and no connection string to configure.

When the run finishes, changed files are synced back and become the memory the next run starts from.

Two sections are lazy: chat/ and files/ can be large, so a run starts with an index of them and fetches individual files on demand. kv/, knowledge/ and soul/ are always present in full.

Namespaces

Each task has an optional Memory Namespace (set on the task card). It is the task's default write prefix: a task with namespace market_data writes to kv/market_data/…. Give each task its own namespace and two tasks can never overwrite each other's state.

The Memory page labels each kv/ folder with the task that owns it, so you can always tell which automation produced a file.

Quarantine

Content that did not come from you or your agent — a public-chat visitor, an untrusted fetch — lands in untrusted/. It is:

• never mixed into the main tree,
• never loaded into the agent's context,
• always rendered as inert text on the page.

Review it in the collapsed Quarantine panel. Promote is the only way content leaves it and becomes something the agent can act on.

History and Undo

Every write and every delete is journaled with who did it and when.

• Recent activity shows the last changes, grouped by the run that made them.
• Undo run reverts everything a single run wrote — useful when a task goes wrong.
• Opening any file shows its history; you can restore an earlier version.

A delete does not destroy content. The prior bytes stay in the journal, so a deleted path can be restored.

Teams and Organizations

Teams and organizations have their own memory at the same kind of path. A team's kv/ is mounted into every member agent's workspace, so one agent's note is another agent's input on its next run.

Because a shared section has several writers, every entry records who wrote it — taken from the authenticated caller, never from the request itself.

Credentials Are Refused

Memory is durable and, for shared sections, visible to other agents. Writing something credential-shaped — an OAuth token, an API key, a private key — is refused on both the store side and the materialise side.

Put credentials in Secrets on the Brain page and reference them as {{secret_NAME}}. They are injected into the run and never persisted into memory.

API

Everything on the page is served by the REST API, so anything you can do in the UI you can script:

scope is characters, teams or orgs. See the API Reference for authentication.

Tips

1. Give every task a namespace. It is the one thing that stops two automations trampling each other.
2. Put reference material in Knowledge, not Working memory — it is the section built for content the agent should read, and the only one that can be published with a public profile.
3. Check Quarantine after opening an agent to public chat. Nothing there reaches your agent until you promote it.
4. Undo the run, not the file, when a task misbehaves — it reverts the whole batch in one action.
5. Never write a token to a file. Use Secrets on the Brain page; a credential-shaped write is refused.