Memory

The Memory toolkit gives an agent, pipeline or conversation a small key-value store it can write to and search across turns — separate from the conversation’s own chat history. It’s listed under the other category in the toolkit type picker.

Note

This is a different feature from Settings › Memory’s Long-term Memory section, which recalls facts about you automatically, before a turn starts, across every conversation — with no tool call involved. The Memory toolkit here is a real, attachable tool the model calls itself, mid-turn, against its own key-value store.

Prerequisites

• No credential: the form does not ask for one, and memories are kept in the platform’s vector store. An administrator must have turned on indexing, with the vector store, and set the memory embedding model (worker.runtime.memoryEmbeddingModel); without it the Memory type is hidden from the picker with that reason.
• No vendor account is needed — the store lives inside your project.

Connect the toolkit

1. Open the toolkit type picker

   In the left navigation, open Toolkits, then select New. Filter the type picker by the other category, or search for “Memory”.

2. Save

   Name the toolkit and select Create. Attach it to an agent, pipeline or conversation the same way as any other toolkit.

Available tools

Available tools (4)

The category of a tool decides when a run needs human approval to call it. See Runtime safety.

Tool	Category
Delete memory	delete
Get memory	read
Manage memory	write
Search memory	read

Common issues

Note

Memories are stored in the platform’s vector store, scoped to your project and to the toolkit itself (the Namespace is only a label inside the toolkit, so two toolkits never share memories even with the same namespace), and search_memory ranks them by how close they are to the query. Memories saved under the retired Python worker (rows in a pgvector database) were not carried over.

Note

A memory holds up to 16 KiB of content and 8 KiB of metadata, a key is at most 256 bytes, and a namespace holds up to 10,000 memories and versions; search_memory returns at most 50 results.

Note

Memory scope. Personal (the default): each person has a private memory, and nobody else can read, search or delete it. Project: one memory shared by everyone in the project. Both: the agent chooses per memory, personal unless it says project. Anything saved to project memory is read back by every later conversation in the project as a fact, so in Both mode the agent is told to save there only when the person asked and never to copy personal memories or text that came from a web page, a document or a tool. If an agent reads untrusted content, prefer Personal only. A scheduled run acts as the person who owns the schedule and uses that person’s personal memory. Personal memory is available only in a private conversation that only you are in; in a shared or public conversation, or in a toolkit run outside a conversation, the agent says so and project memory still works. This is checked on every call. Memories are kept per project, and the platform, not the agent, keeps one person’s personal memory from another: it is enforced where the memories are stored.

Note

Saving to an existing key keeps the old value as history instead of overwriting it. get_memory and search_memory return the current value; they also accept as_of (an RFC 3339 timestamp, to see what was true then) and include_history. delete_memory removes every version. A key keeps at most 20 versions. Deleting the toolkit deletes all of its memories, including every person’s personal ones; a person who leaves the project, or is deleted, has their personal memories deleted too (retried until it succeeds).

Note

The store is scoped to whatever key you give it — an agent must be instructed (or coded, in a pipeline) to use consistent keys, or writes and reads won’t line up. There is no automatic per-user or per-conversation partitioning.