> For the complete documentation index, see [llms.txt](https://docs.hex-rays.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.hex-rays.com/add-ons/assist/concepts/memory.md).

# Memory

Assist keeps a persistent, per-binary **knowledge base** so findings survive across sessions. When you reopen a database days later, the agent can recall what was learned about it before.

![Memory in the Assist guide](https://492083732-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FFP6ibt8r6WPBHTqekG9u%2Fuploads%2Fgit-blob-0ec60a407a4c564c750f3d71eaa8a05bef0e3a08%2Fmemory-assist.png?alt=media)

## How memory is stored

* **One knowledge base per binary.** Memory is stored in a local SQLite database under `<user-ida-dir>/assist/knowledgebases/<binary-md5>`, keyed to the input file's **MD5** digest (or a hash of the `.i64`/`.idb` path when no input-file MD5 exists, such as a raw memory dump).
* [**Full-text search**](/add-ons/assist/reference/glossary.md#fts5)**, browser filtering, and SQL queries.** In the **Memory** browser (**Settings → Memory** or `/memory`), you can filter by words, categories, or `#tag` tokens; the agent can search memories by text, scope, and anchor (`recall`) or run read-only SQL queries (`idb_query`).
* **Injected into context.** When **Include memory in prompts** is enabled, Assist injects up to 6 local and 6 global accepted memories on each turn. Local memories are selected using both location anchors and search terms from your current request, and anchors are checked against the live database before injection so stale entries are suppressed.

### Two scopes and five local anchors

* **Global (`◆ Global`)** — binary-wide observations (architecture, ABI, crypto constants, threat family, protocol notes) eligible for injection on every turn.
* **Local (`⌖ Local`)** — attached to a specific location or artifact in the binary and selected when your cursor or active function matches one of five anchor types (with any remaining local slots filled by task-query search matches):
  1. **Function** — matches while inspecting that function.
  2. **Address range** — matches when the cursor falls inside the range.
  3. **Exact address** — matches at that exact effective address.
  4. **Address with radius** — matches when the cursor is within the specified byte radius of the address.
  5. **Referenced string** — matches when the current function references that string literal.

Local memories also record portable file-offset coordinates so their addresses re-resolve automatically if the database is rebased.

## How memories are created and managed

Completed chat replies do **not** create memory automatically. Memories are recorded only through explicit actions:

* **Agent memory tools (`remember`, `revise_memory`, `forget_memory`).** When the agent discovers a finding worth keeping, it calls `remember`. Agent memory writes require **Allow memory writes** to be enabled and are gated by **Share confirmed findings** in [Permissions & Privacy](/add-ons/assist/concepts/permissions-and-privacy.md#tool-capability-permissions-assist-tab) (**Ask when needed** by default). When permitted, the built-in agent can record new notes and revise or delete its own notes directly, whereas agent edits to human-authored or peer-shared memories and writes from permitted external [MCP](/add-ons/assist/reference/glossary.md#mcp) clients are queued as pending proposals for your review.
* **Create review notes (Functions window).** Choosing **Create review notes** from the Functions window's right-click menu writes seed notes for the selected functions directly without a [capability prompt card](/add-ons/assist/reference/glossary.md#capability-prompt-card) (prompting with a confirmation dialog only when multiple functions are selected). If **Allow memory writes** is disabled, the action fails and writes nothing.
* **Conversation compaction (`/compact`).** Compaction summaries are not inserted as memories automatically; when **Harvest memory during compaction** and **Allow memory writes** are enabled, the model can stage `remember` proposals while producing the summary. Once the compaction checkpoint is published, committing those staged proposals goes through the **Share confirmed findings** capability gate (prompting with a capability card if set to **Ask when needed** and not already allowed for the session).
* **Binary triage (`/fulltriage`).** When a **Triage** conversation completes and **Allow memory writes** is enabled, its grounded deterministic findings are written directly to the binary's memory without a capability prompt card (whereas propagating confirmed triage findings to linked peer databases requires **Share confirmed findings** to be **On**).
* **Direct analyst entry.** Open **Settings → Memory** (`/memory`) to browse, search, add, edit, delete, import, or export memories as JSONL, or right-click in Disassembly or Pseudocode and choose **IDA Assist → Memory** (**Add global memory**, **Add local memory**, or **Add local memory for selection**).
* **Linked databases (`propagate_memory`).** Confirmed findings shared from another open IDA session over the Assist Mesh arrive in quarantine and wait for your review before being used.

### Persistent memory settings

Under **Settings → Preferences… → Advanced → Persistent memory**, four independent checkboxes (all **enabled by default**) control how Assist uses the knowledge base:

* **Allow memory recall** — Allow model tools to retrieve stored analytical claims.
* **Allow memory writes** — Allow new claims and revisions (external proposals still require review).
* **Include memory in prompts** — Add eligible memory claims to model requests.
* **Harvest memory during compaction** — Allow compaction to propose durable claims through the memory write gate.

## Provenance badges and linked databases

In **Settings → Memory**, each memory card shows its scope badge and a provenance/review badge:

* **`NATIVE`** — an accepted memory authored locally for this binary (by you, `/fulltriage`, or the built-in agent).
* **`PENDING`** — a local proposal awaiting review (such as a `remember` call from an external MCP client or a proposed revision/deletion of a human-authored or foreign memory).
* **`INBOUND-PENDING`** — shared from a linked IDA database over the Assist Mesh and awaiting review.
* **`FOREIGN`** — an accepted memory that originated from a linked peer database.

![The Memories view, listing findings from a triage](https://492083732-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FFP6ibt8r6WPBHTqekG9u%2Fuploads%2Fgit-blob-be69dda24c8d57d31b4b99c75fa02e0140d43bc0%2Fmemory-list-assist.png?alt=media)

`PENDING` and `INBOUND-PENDING` items are held in quarantine and are **never** injected into prompts or returned by `recall` until you click **Accept**. Once accepted, provenance is preserved for attribution (and native memories cannot be overwritten by a peer), while local recall ranks accepted memories by anchor relevance, confidence, and recency. Accepting a proposal makes it eligible for recall and is distinct from recording verification status.

Outbound sharing (`propagate_memory`) is controlled by **Share confirmed findings** in **Settings → Permissions** (**Ask when needed** by default) and by **Send memories** in **Settings → Preferences… → Sharing & network** (**Confirm each send, and let the model suggest them** by default).

### Graph view

The **Graph** view of the Memory browser shows the same knowledge base as a graph. Dots are memories, diamonds are their Global or Local anchors, and squares are tags shared by several memories. Drag nodes to rearrange them, scroll to zoom, click a node to inspect it, and double-click to jump to it in IDA.

![The Graph view, with memories grouped around their Global and Local anchors](https://492083732-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FFP6ibt8r6WPBHTqekG9u%2Fuploads%2Fgit-blob-9b58634bc887a4e486a184c2ef2b3314369d81b6%2Fmemory-graph-assist.png?alt=media)

## Limitations

* **Different builds have different MD5 hashes.** Because memory is keyed to the input file's MD5, a new build of the same target — a game patch, a recompiled sample, or a new firmware revision — starts with an empty knowledge base. JSONL export/import restores memories only for the **same** binary subject (import verifies the binary hash and rejects records from a different build); to transfer findings across builds, open both databases and share findings over the Assist Mesh so their anchors can be reviewed.
* **Session transcripts vs. memory when moving folders.** Conversation transcripts are keyed to the database's path, while memory is keyed to the input file's MD5 (with an IDB-path fallback only when no MD5 exists). Moving a database folder preserves MD5-keyed memories automatically, while transcripts remain associated with the original path.
* **Forward format compatibility.** Upgrading Assist automatically backs up an older knowledge base before migrating it to the current format. Opening a knowledge base created by a newer version of Assist with an older build is refused so newer data cannot be corrupted.
* **Browser view limit.** The **Memory** browser displays up to 1,000 facts per scope (**Global** and **Local**).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.hex-rays.com/add-ons/assist/concepts/memory.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.