Skip to main content
Agent memory is currently in Beta and gated by a feature flag. Contact Lightdash support to enable it for your organization.
Agent memory is how Lightdash AI agents get better the more you use them. As you ask questions, correct wrong answers, and leave feedback, the agent quietly captures what it learned from those conversations as small, durable memories that it uses in future threads. There is nothing to set up. Memory runs in the background, on a schedule, and turns on the moment the feature flag is enabled for your organization.

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.
You do not need to review anything, approve anything, or turn anything on per-agent — the agent handles it.

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.
Memory is reactive — it learns from what happens in chat. If you already know exactly what context the agent needs (a glossary, fiscal calendar conventions, definitions of internal terms), it’s faster to give it upfront through knowledge documents than to wait for memory to pick it up.

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.
Cross-user knowledge is handled separately by project context and knowledge documents — memory is the personal layer.

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.
Citations make it easy to tell which parts of an answer rest on past-thread knowledge, and to check whether a memory still holds. The read-only memory detail page showing the memory body, evidence for why it was learned, status, scope, terms, and the catalog objects it references. The memory page shows what was learned, the evidence behind it, its status and scope, and the catalog objects it references. From here you can retire a memory that no longer applies.

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 — user for personal preferences and corrections, project for memories that look like general project knowledge and are candidates for promotion into shared context.
Admins can audit what the agent has learned without that memory entering their own agent context — reading a memory never injects it into your own conversations.

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.

Frequently asked questions

Is memory per-user? Can admins see all memories? Yes — memories are private to their owner and are never injected into anyone else’s conversations. Organization admins get an audit tab that lists memories across users and agents, but reading a memory there never adds it to the admin’s own agent context. Does memory work without project context set up? Yes. Memory and project context are independent features. Memory does not require a connected GitHub or GitLab repository or any project context configuration to work. What happens when I switch the agent’s model? Nothing. Memories are stored as plain text and are model-agnostic, so switching the agent’s model does not invalidate or change existing memories. Can I correct or remove something the agent learned? Yes. Open the memory from its citation chip or the memories page and retire it — retired memories are never injected into future answers. You can reactivate a retired memory from the same page if you change your mind. What happens if memory is disabled after it has been used? Learning and injection stop immediately: no new memories are saved, and existing memories are no longer added to answers. The memories themselves are retained, so if memory is re-enabled later, they resume being used without any data loss.