Conversation memory

Conversation Memory turns every past agent conversation in a project into a searchable knowledge base. As your agents work, Kangentic builds a local, per-project index of what was said, so you (and your agents) can answer “have we solved this before?” without scrolling through old sessions. It runs entirely on-device with no API key.

What gets indexed

Kangentic indexes the structured transcript of each session - the user turns, assistant replies, thinking blocks, and tool-call summaries - and deliberately never indexes the raw terminal scrollback, which for TUI agents is mostly cursor and redraw noise. Indexing is automatic and incremental:

A session is indexed when it finishes or suspends.
An in-progress conversation is re-indexed at each turn boundary, so it becomes searchable within a second or two.
Older history is backfilled in small sweeps when you open a project, so a large history amortizes instead of blocking.

Since v0.44.0 the same index also holds each task’s own record, the commits on the project’s default branch, and, if you turn them on, task summaries and the project’s source code. The Knowledge Graph page covers those sources.

Indexing is on by default and can be turned off with the Index switch in Settings > Knowledge Graph. Off stops the sweep and hides conversation results in Quick Find and kangentic_search; tasks, backlog items, session events, and projects stay searchable. The index already built stays on disk, and the sweep picks up where it left off when you turn indexing back on.

Keyword and semantic search

Search has two layers:

Keyword search (on by default) is fast full-text matching over the indexed turns.
Semantic search adds a small local embedding model that matches by meaning rather than literal words, so a query finds relevant conversations even when the wording differs. It is on while the Knowledge Graph switch in Settings > Knowledge Graph is on, which is off by default.

When both are on, a search by meaning is hybrid: it fuses the two rankings, and a conversation that matches both ways ranks highest. Every failure path (no model yet, extension unavailable, slow embedding) degrades transparently to keyword-only and never blocks a search. A built-in relevance filter drops off-topic and gibberish semantic hits; keyword hits are always shown.

Because the degrade is silent by design, the Knowledge Graph card in Settings is where you find out it happened: a note there names the reason whenever the local model is not running. When the embedding process itself failed, the note says how it stopped (its exit code, or that it failed to start) and gives its first error line. See Semantic search falls back to keyword.

Where you use it

Conversation Memory surfaces in four places:

Quick Find Ctrl+Shift+F / Cmd+Shift+F shows a Conversations group of keyword matches alongside tasks, backlog, events, and projects. It matches words only, whatever the Knowledge Graph switch says, and its last row hands your query to the Knowledge Graph. Selecting a hit opens the read-only conversation viewer scrolled to the matched turn, or routes you to the live terminal if that session is still running.
The Knowledge Graph Ctrl+Shift+A / Cmd+Shift+A draws the index as a map and answers questions about it by meaning.
Every task detail window has a View conversation pill (speech-bubble icon, also in the kebab menu) that opens the task’s newest session in the viewer - no search needed. The pill is muted until the task has session history. When the index holds earlier conversations near the task, the window also lists them as prior work.
The kangentic_search MCP tool lets your agents recall past conversations themselves, by meaning by default or by keyword with mode: "keyword", and drill into a cited turn with kangentic_get_transcript. See the Tool reference.

The conversation viewer

The viewer is a real workspace window, not a modal: it floats on the board layer alongside task detail windows, and you can drag, resize, snap, tile, and maximize it the same way - so a past conversation can sit next to the live terminal that is continuing the work. Open viewers are part of your workspace: they persist across project switches and app restarts.

Each turn is rendered cleanly (user prompts, assistant replies, thinking blocks, and tool-call summaries) with per-message copy buttons. The header keeps two one-tap actions:

Open task jumps to the task the conversation belongs to, opening its detail window.
Copy conversation as Markdown copies the whole transcript as clean Markdown.

Both are also available from the window’s kebab menu.

Search within a conversation

An always-visible search bar sits at the top of the viewer. Type to filter the transcript to matching turns, each shown with a short snippet, and step through the hits with the prev/next controls (or Enter and Shift+Enter) while a counter tracks your position. Press Ctrl+F / Cmd+F to jump straight to the search input. Clicking a result snaps instantly to that turn with no scroll animation, so finding “where did it decide to use a worktree?” in a long session is a few keystrokes rather than a manual scroll.

Where it opens

The viewer opens positioned where you want to be, not at the top:

By default it opens at the latest message, so reopening a finished session lands on its conclusion.
If you had scrolled up in the live terminal before opening the viewer, it opens centered on the turn matching what you were looking at, so the clean transcript picks up from the same place as the raw scrollback.

Opening a conversation from a Quick Find hit instead lands on the matched turn, briefly highlighted.

Long transcripts

The viewer is built to stay smooth on very long sessions - thousands of turns, and tens of thousands of messages. Rows are virtualized and reused as you scroll, so scrolling stays fluid no matter how long the conversation is. A custom overlay scrollbar replaces the browser default: it keeps a usable thumb size on huge transcripts, shows a position bubble while you drag, and offers a jump to latest pill to snap back to the end in one click.

Since v0.36.0 there is also a hard read bound. A transcript larger than 16 MB is parsed from its most recent 16 MB only, roughly 2,800 turns, and the viewer opens with a plain notice at the top saying how much was left out. The bound exists because parsing a whole file briefly costs about twenty times what it retains, and several such parses running at once is how the app ran out of memory on a 138 MB transcript. It applies to every agent, not just the one whose transcripts happened to be biggest.

Nothing is lost to search: the conversation index walks the whole file in windows regardless, so an omitted early turn is still findable in Quick Find and by kangentic_search.

After the agent deletes its transcript

Claude Code deletes transcripts older than its cleanupPeriodDays setting. Since v0.46.0 Kangentic keeps its own copy of each parsed conversation, compressed in the project’s database, so the viewer still shows the conversation afterwards, under a banner that says the agent deleted the original file. The copy is written whatever the indexing switch says, uses no model and no network, and is deleted with the task’s session records. On one project’s 629 conversations, 4.6 GB of transcript files came to 86 MB. kangentic_get_transcript reads the same copy, and the recap that starts a deleted conversation over takes its last turns from it.

Choosing a model

When you turn the Knowledge Graph on, Kangentic downloads a small embedding model (from Hugging Face) and then runs it offline. Pick it with Search quality in Settings > Knowledge Graph:

Search quality	Model	Dimensions	Approx download	License
Best (default)	IBM’s Granite embedding English R2 (`granite-r2`)	768	~153 MB	Apache-2.0
Light	bge-small-en-v1.5 (`bge-small`)	384	~33 MB	MIT

Granite R2 replaced the bge-base and bge-large models in v0.45.0, because it ranked the right answer higher on both of the app’s measurement sets, one of docs and one of code, drawn from Kangentic’s own repository. A config that still names one of the removed models reads as Best, so the first launch after the update downloads Granite R2 and re-embeds the index in the background, and search by meaning answers by keyword alone until that finishes. The row under the choice names the model, its size, and where it runs, and a License line links the model’s license.

Embedding runs in an isolated background process so it never blocks the UI, and it is duty-cycle throttled so it paces itself and yields to any active search - even a first-run or post-model-switch backfill never pegs your CPU or GPU. A Model acceleration dropdown (Auto / GPU / CPU) picks where it runs - Auto and GPU prefer your GPU (DirectML on Windows, WebGPU elsewhere) and fall back to CPU. It was called Hardware acceleration until v0.43.0, and was renamed once Settings gained a Graphics acceleration row, since two settings you would read as the same thing is worse than one longer label. Switching models re-embeds the index in the background. Rebuild the index, in the same tab’s Index card, reads every source again if search ever misses something you know is there; see Rebuilding the index.

That process is not held open between jobs. It stays while there is anything left to embed, and is released half an hour after the last query or batch once no project has work pending; on Windows, where a long index drain grows it, a worker past 1.5 GB is released after two minutes instead. It comes back on demand, and opening the Knowledge Graph starts it ahead of your first question, so the cold start is not spent on your search. A query whose budget runs out while it is still starting falls back to keyword, the same as every other degraded path.

Privacy

The index is local and keyless. Only structured conversation turns are indexed (never raw terminal output), the index lives in each project’s database, and searching never leaves your machine. The one network access the index itself makes is the embedding-model download when you first turn the Knowledge Graph on, repeated only when you pick another model or an update replaces the one you run. Asking the Knowledge Graph a question is different: it sends the related passages to the agent you chose to answer it. See Knowledge Graph privacy and Privacy and analytics.

Settings

Indexing, the local model, and everything the Knowledge Graph adds share one tab, Settings > Knowledge Graph. It was the Memory tab through v0.43.2. The Knowledge Graph settings table walks every row, and the Configuration reference lists every knowledgeGraph.* key.