Memory

Memory lets your assistants remember things between conversations, so you don’t have to repeat yourself. For example, your support assistant can remember that “Brightway Logistics is an enterprise account: send their tickets to Tier 2”, or that a customer prefers email, and use it the next time it matters.

You can write memories yourself, and assistants can save what they learn as they work. When an assistant answers, it looks up the memories that relate to the question and uses them.

Memory is different from an assistant’s rules: rules apply to every answer, memories are looked up only when they are relevant.

Add a memory

1. Open Memory in the sidebar and click Add memory. To add one for a single assistant, open that assistant’s Memory tab instead.
2. Under What should your agents remember?, write it in a sentence.
3. Optionally add Tags to group it, like refunds or shipping.
4. Under Advanced, pick the Kind: a Fact (a short thing to remember) or a Document (a longer text, with Where it came from for a link to the original). For a fact, pick How long to keep it. An assistant looks up both before it answers: from a document it uses the passages that relate to the question, not the whole text. What you add here is read by assistants whose memory is Shared by all agents.
5. Click Save memory.

A new memory can be found a moment after you save it.

How long a memory is kept

Short-term notes are not simply thrown away: every hour the important ones are rewritten as long-term facts by an AI model, and the rest retire when they expire.

An assistant’s memory settings

On an autonomous assistant, the Memory section decides what it remembers and where.

Whose memory

What it saves

• Facts it learns: after each conversation, the assistant picks out up to five lasting facts and saves each as a long-term memory.
• Whole conversations: each exchange is saved as it was said.
• Only when asked: nothing is saved on its own; the assistant saves something only when the person asks it to remember it.

Whatever you choose, the assistant can also save a memory on purpose while it works.

Never save. Write rules, one per line, such as “card numbers, passwords, home addresses”. Before anything is saved, the assistant removes what the rules cover. If nothing is left, nothing is saved, and if the check cannot be made, nothing is saved either.

How long it keeps memories. Until deleted, or for a number of days. After that a memory stops being used and shown. Changing the number also applies to what the assistant already saved.

Memory account. By default memories are kept in almyty. You can also keep them in an outside memory service your organization set up on the Memory page’s Storage tab, or connect an account for this one assistant with Add a memory account, without changing anything for the rest of the organization.

Keep memories in another service

almyty’s own memory is the default and does everything on this page. You can also keep an assistant’s memories in an outside memory service:

If a service cannot do something, almyty falls back to its own memory or says so plainly, so memory never silently stops working. You can also mirror memories to a second service, and the two are kept in step automatically.

Nothing is lost

Changing a memory does not overwrite it: the new version is saved and the old one is closed. Expiring and tidying also close memories rather than erase them. So you can always see not just what is true now, but what an assistant knew at any moment in the past.

Related

• Autonomous agents: turn on memory for an assistant
• Connect a provider: the provider used to index memories for search

For developers

Tiers. The API stores a tier on each memory: short (optional TTL, swept when it expires), project, long (no expiry) and shared (cross-agent workspace knowledge, no expiry). An hourly consolidation job distils ageing short-term rows into long-term facts with an LLM, and a TTL sweeper retires expired short rows.

Modes. memory (facts, preferences and observations) and document (source documents, chunked and versioned for retrieval). A document written in one piece is kept whole for reading and split into chunks that are embedded and searched; search returns the matching chunks, never the whole document, and deleting the document deletes its chunks. An agent’s recall searches both modes in the scope its memory settings pick; with an outside memory account, facts come from that account and documents from almyty-native.

Retrieval is hybrid search: vector similarity (pgvector, cosine) blended with Postgres full-text search, then filtered by scope, tier, tags and validity. Embeddings are made per scope with the organization’s own providers (OpenAI text-embedding-3-small preferred, Mistral mistral-embed next, and a deterministic fallback when neither is configured), asynchronously. Each memory records the model that embedded it; vector search only compares vectors from the same model, and falls back to full-text search across models.

Bi-temporal history. Memory tracks valid time (when it is true) and transaction time (when it was written). Updates write a new current row and close the old one; expiry and consolidation close rows rather than delete them, so an as-of query reconstructs what an agent knew at any past moment.

Scopes. Every memory belongs to a scope (user, workspace, project, collab or agent) and every query filters on it; the scope is the isolation boundary. A user scope is one member’s (or one visitor’s), an agent scope one agent’s own.

Backends and sync. A per-scope router can point a scope at a different store; only almyty-native (Postgres + pgvector) has bi-temporal history, TTL and hybrid search. Operations a backend does not support fall back to almyty-native or return a clean error. A scope can mirror to a second backend: every write is mirrored best-effort, and a scheduled reconciliation job keeps the two in step (last write wins).

Agent memory settings on the server. Every setting is applied by the server on each run. An organization memory account is used with the organization’s credential; an agent’s own account is used as the run, so its connection’s scope applies (a private connection only for an agent private to the same owner, a team one only for that team’s agents). The agent saves on purpose with its store_memory tool; what a run saves after it ends is a memory_save step on the run, with its cost. In an outside account, memories past their keep period are deleted through that service’s API about once an hour.

Access from your tools. The MCP control plane exposes memory_put, memory_search, memory_supersede and more; see Control almyty via MCP. Memory is also available over REST in the API reference.