A Memory Profile is where you define what an agent remembers, who it belongs to, and how long it's kept.

Overview

A memory profile is one kind of memory inside a memory set — "Individual configurations to store a particular kind of memory." Each profile decides what the agent remembers, who that memory belongs to, which models extract and index it, and how long it's kept. You create profiles from a memory set's Profiles tab; the editor is organized into Profile Setup, Generation Settings, and Storage Settings.

Memory Types

Under Profile Setup, Memory Type is required and defaults to all three:

Pick the types that fit what you want the agent to carry forward. Most profiles use a combination.

What Does Scope Control?

Scope decides who a memory belongs to:

In the standalone Memory Sets area you choose User Specific or Team Specific. Use User Specific for personal assistants and Team Specific when a group should share context.

Note: You may also see a platform-provided profile scoped Project — that's a system-seeded profile, not a scope you can pick yourself when creating a profile.

How Are Memories Generated and Indexed?

Generation Settings picks the models and guidance for writing memories:

• LLM Model — the model that extracts and writes memories from conversations.

• Instructions — "Describe what information should be stored and how it should be used."

• Embedding Model — vectorizes memories so they can be matched semantically later.

• Refresh Frequency — how often the profile's memories are refreshed.

Note: Clear instructions matter here — they tell the model what's worth remembering and what to ignore.

Controlling How Long Memories Are Kept

Storage Settings governs retention. By default memories don't expire. Turn on Set Expiration Period — "Memories will be deleted after the set duration" — and set Expire After as a duration (minutes, hours, days, weeks, or months).

Note: Use an expiration period for memories that should age out (recent context) and leave it off for durable facts you want kept indefinitely.

When Are Memories Actually Written?

Extraction is a scheduled background sync, not a per-message step. When a profile is enabled, the platform registers a recurring job at the profile's Refresh Frequency; disabling or deleting the profile cancels it (deleting also removes the profile's stored memories). Each run:

• Marks the profile in-progress, then sweeps the conversations updated since the last successful run (tracked as a last-sync time on the profile), paging through them in batches.

• Skips any user who has opted out of memory, and for team-scoped profiles only processes users who are actually members of the profile's team(s).

• Rebuilds each conversation's transcript (user and agent messages, grouped per user) and hands it to the extraction model.

• On success, advances the last-sync time so the next run only looks at new activity.

So a fact a user states mid-conversation becomes a stored memory on the next refresh cycle — not instantly.

What Does the Extraction Model Actually Store?

The profile's LLM Model reads the transcript with a strict extraction prompt and returns candidate facts per enabled memory type (semantic / episodic / procedural), plus its reasoning. The prompt's rules are worth knowing because they explain what does not get remembered:

• Only statements made by the user count — facts that appear only in the assistant's messages are ignored (unless the user explicitly confirms them).

• Greetings, small talk, and speculative questions ("Should I try X?") are excluded.

• One-time requests are skipped; a preference is stored only when permanence language is present ("always", "from now on", "by default", "I prefer") — "translate this to French" is not stored, "always answer in French" is.

• Your profile Instructions are injected into this prompt as strict additional rules, which is why clear instructions directly shape what's kept.

How Are Duplicates and Contradictions Handled?

Every candidate fact goes through a memory-manager step before it's saved. The platform embeds the fact, retrieves the 5 most similar existing memories in the same profile and scope, and asks an LLM to decide the outcome:

Each stored memory is saved twice — as a readable text record and as a vector embedding (made with the profile's Embedding Model) — cross-linked, with provenance: which user's chat it came from, which agent, and which conversation. That provenance is what powers the Reference Chats link in the Memories tab.

How Is Scope Enforced When Memories Are Read?

Scope is enforced at retrieval time, per request:

• User Specific — only memories created from that user's own chats are eligible.

• Team Specific — the platform checks, at read time, that the requesting user is a member of one of the profile's teams; non-members retrieve nothing from it.

• Agent Specific — memories are shared with everyone using that agent.

Note: Per-user opt-outs are honored here too: a user who has disabled memory for a profile or set gets no reads (and no writes) from it.

How Is Expiration Enforced?

Expiry is enforced by a recurring background cleanup job, not by a filter at read time. On each pass, for every profile with Set Expiration Period on, it computes the cutoff from your Expire After duration, finds memories created before the cutoff, and deletes them from both the text and vector stores. Each cleanup is logged per profile with the number of memories removed and when.

Note: Until the cleanup pass runs, a just-expired memory may still be retrievable for a short window.