Memory
What agents remember across conversations — memory scopes (account, user, agent), how memories are retrieved into a run, and how you review them.
Updated 9/16/2026
Threads are per-conversation. Memory is what lets an agent carry a fact from one conversation into the next — the user's name, a preference, a project convention — without you re-stating it every time. A memory is a short, bounded statement of fact, preference, or instruction, distinct from a thread message.
Memory scopes
Every memory is anchored to one scope, which controls who can see it:
- Account — shared by every agent in the account. Use this for team-wide context ("we deploy on Fridays").
- User — tied to one person, visible to the agents that person invokes. Use this for personal facts ("prefers metric units").
- Agent — private to a single agent.
Account-scoped memory is the reason a fact your team's agents share can live under the account rather than being re-taught to each agent. Memory is account-scoped overall; it never crosses account boundaries. Memory must be enabled for the account before agents start remembering.
How memories get written
Memories are created two ways:
- Automatically, from a conversation. After a run finishes, an extractor pulls out bounded facts. Depending on your per-agent settings, a new memory either saves immediately or lands in a suggestions queue for review before it's kept.
- Manually, from the memory library at
/a/<account>/memory, where you can add, edit, or delete memories directly.
Updates and deletes are non-destructive within the retention window, so a bad automatic write can be rolled back. Every change is recorded in an audit trail.
How memories reach a run
At the start of a run, the dispatcher retrieves the most relevant memories for the querying agent and injects them into the prompt. Ranking is hybrid — it blends keyword match, semantic similarity, and entity match rather than relying on any single signal — and only returns memories the agent is allowed to see under the account's access rules.
Memories learned from a tool result (rather than from you or the agent itself) are treated as lower-trust: they're labelled in the prompt as data, not instructions, so a hostile data source can't quietly change the agent's behavior.
Procedures — what worked before
Facts are sentences; a procedure is the sequence of tool calls that actually worked. After a run ends well, the agent keeps a record of each turn in which it used two or more tools and every call succeeded: the task you asked for, the calls in order with their arguments, and how each one ended. No model is involved in writing it, and nothing in it is editable. Find them under Memory → Procedures.
When a later task looks like one of those (the similarity is measured on the task, not on the steps), up to three procedures ride into the run under a header that says plainly what they are: records of past runs — data, not instructions; verify before repeating. The agent decides; every call it then makes still goes through the same gates as any other.
What is not captured: a turn where any call failed (a recovery is a different thing), a turn with a single call or the same call repeated, content flagged as untrusted, and secrets — argument values whose key looks like a token or password, values shaped like an API key, and every credential the run was actually given are masked before the record is written; e-mails and phone numbers are scrubbed.
What happens next scores them: a run that succeeded after recalling one counts for it, a 👎 on the reply counts against it, and two 👎 (or a majority of down-votes) stop it from being recalled again. Once a procedure has worked three times after being recalled, it is proposed as a skill on the agent's Learning tab — you accept or reject, as with any suggestion.
Procedures belong to the agent that produced them, in the scope the conversation had: in a shared thread they carry no person; in your own thread they are yours and only you (or an admin) can delete them. The account's memory retention window applies to them; turning memory off turns them off; the agent's Memory tab has a switch to keep memory but stop remembering procedures.
Where to go next
- Personas — how an agent communicates, which also biases which memories surface.
- Threads and runs — where memories are written from and injected into.
Ask Zero
Ask a question about connect0 and get an answer grounded in the docs, with links to the sources. Signed in? Zero answers with your account in mind.