How it works
Memory is fully automatic:- You keep working. Ask questions, correct answers, and give thumbs up / thumbs down feedback in the web app or Slack the same way you always have.
- The agent reviews idle threads in the background. A few hours after a thread goes quiet, an LLM reads it and decides whether anything durable was learned — an explicit correction, a business definition you taught it, a preference for how you like answers presented, or a failure it recovered from.
- Useful learnings become memories. If the thread contained something worth remembering, one small memory is saved. If it didn’t, nothing is saved.
- A daily curation pass keeps the corpus clean. Duplicate memories are merged, memories replaced by newer corrections are superseded, and memories about explores or fields that no longer exist are retired.
What agents learn from
Memory is drawn from the everyday things you already do with the agent:- The questions you ask. Recurring conventions (“revenue means net after refunds”) get remembered so you don’t have to restate them.
- Corrections you make. When you tell the agent it used the wrong metric, filter, or table, the correction is captured so the same mistake stops recurring.
- Feedback you leave. Thumbs down with a written note is the strongest signal. The clearer the note, the better the future memory.
- Preferences you state. “Always give me a table” or “prefer bar charts for categorical breakdowns” become defaults for your future conversations.
Memories are scoped to you
Each memory belongs to the person whose thread it came from, and it is only ever used in that person’s own conversations with the agent. Two people asking the same question can legitimately see different data because of user attributes and row-level access, so a memory learned from your thread is never injected into someone else’s answer. Practically, this means:- Memories from your web threads are used only for you.
- In a shared Slack thread, memories are attributed to the thread’s owner and used for that owner’s turns.
- Reading a memory requires the same access as reading the thread it came from.
Citations
When the agent uses a memory to inform an answer, it cites it inline:- In the web app, the citation renders as a small chip next to the sentence it supports. Clicking the chip opens a read-only page showing the memory’s contents and where it came from.
- In Slack, citations render as native Slack citation elements linking to the same memory page.

Admin visibility
Organization admins get a memories tab that lists memories across users and agents, with:- The memory’s content and provenance (source thread, or the memories it was consolidated from).
- Its status — active, superseded, or retired.
- Its scope label —
userfor personal preferences and corrections,projectfor memories that look like general project knowledge and are candidates for promotion into shared context.
What is not included in memory
A few things are deliberately kept out:- Preview projects are excluded, so throwaway environments don’t pollute memory.
- Content from external MCP tools can never be turned into a durable memory.
- Point-in-time values (specific numbers, dated results) are not remembered — only durable conventions, definitions, preferences, and failure recoveries.
- One-off requests are not turned into standing preferences. A preference needs standing-instruction phrasing (“always”, “from now on”, “I prefer”) or to recur across the thread before it becomes a memory.
Memory vs. project context
Memory and project context both improve future agent answers based on what happens in chat, but they solve different problems and apply in different ways.
If you also want to hand the agent context upfront (a glossary, fiscal calendar, internal definitions) without waiting for either loop, use knowledge documents.
Use memory for in-the-moment course corrections that stick to you, project context to improve every agent in the project at the source, and knowledge documents when you can hand the agent the answer upfront.