Recall Makes Agent Memory Boring: Search the Chats You Already Have, Don’t Invent a Second Brain

Most agent-memory products start from the assumption that developers need another brain. Recall starts from a better assumption: developers already have the memory, it is just scattered across chat histories they cannot search well. Cursor sessions, Claude Code JSONL files, Codex CLI rollouts, pi conversations — the answers are often already on disk. The missing feature is not consciousness. It is search.

Recall is a local Go CLI and MCP server from Pratik Gajjar that indexes existing coding-agent transcripts without modifying the source data. Its v0.1.1 release landed on June 1, 2026, and the Hacker News launch appeared June 3. During research, the repository had 2 stars, 0 forks, and 0 open issues. Again, this is not a traction story. The useful signal is architectural: a read-only, disposable SQLite FTS5 index over the conversations you already paid to generate may be a better default than yet another “persistent memory” system asking to become the new source of truth.

That modesty is the product’s strength.

Search first, mythology later

Recall reads native storage for Cursor, Claude Code, Codex CLI, and pi. The project says it does not move, copy, or modify the source data. Instead, it builds a local index under ~/.recall/, with a SQLite schema containing sessions metadata plus a messages_fts full-text table over role, timestamp, and message excerpts trimmed to about 1.5 KB per message. Search uses SQLite FTS5 with BM25 ranking and a small recency lift. If the index gets stale or suspicious, delete it and rebuild.

That is boring architecture in the best possible way. The example recall doctor output in the project brief shows one local machine with 2,597 indexed sessions: 1,514 from Cursor, 25 from Claude, and 1,058 from Codex, producing a 69.5 MiB index.sqlite. Those numbers are the actual story. Developers are already accumulating thousands of agent interactions across tools. The industry keeps pitching memory as a future feature; the messy archive is already here.

Recall’s supported paths make the point concrete. Claude Code sessions live under ~/.claude/projects/<sanitized-cwd>/*.jsonl. Codex stores rollout files under ~/.codex/sessions/YYYY/MM/DD/rollout-*.jsonl. Cursor has workspace state in state.vscdb. pi has sessions under ~/.pi/agent/sessions/<sanitized-cwd>/*.jsonl. A useful memory layer does not need to invent a persona or a graph before it can answer, “What did we decide about the auth migration last Tuesday?” It can start by indexing those files and returning the relevant transcript.

The MCP mode exposes recall_search, recall_transcript, recall_sessions, and recall_related. Claude Code integration is a one-liner: claude mcp add recall -- recall mcp. That makes the tool operationally interesting. A coding agent with transcript search can recover context after a reset, cite an old session, and continue work without asking the human to manually grep their own history.

The best memory is cited memory

The obvious competitor category is heavier persistent memory. AgentMemory, cited in the research brief, reports more than 20,871 GitHub stars and positions itself as long-term memory for coding agents. Codebase Memory MCP reports 2,918 stars and focuses on code intelligence with “158 languages” and very fast queries. Those projects may be useful. But Recall attacks a narrower problem with fewer moving parts: local transcript search, scoped by source, repo, date range, or session id.

That constraint matters because agent memory has a provenance problem. A model that “remembers” a decision without citing where it came from is just a more confident model. In engineering work, context is not enough; context needs lineage. Was that architecture decision from the final review or from an abandoned debugging branch? Did the agent find the latest migration plan or a stale proposal from two weeks ago? Was the remembered workaround superseded by a patch release?

Recall’s transcript-first design gives teams a better habit: make the agent cite the session it used. If Claude Code searches old chats before acting, it should say which session, which repo, and which date shaped the action. That does not make the memory correct, but it makes it inspectable. Human reviewers can click back into the transcript and decide whether the agent is reviving useful context or zombie assumptions.

This is also where lexical search beats a lot of fancier machinery for day-one use. SQLite FTS5 will miss paraphrases that embeddings might catch. It will struggle with concepts that never share words. But it is transparent, local, cheap, and debuggable. Developers understand why a BM25-ranked result matched. They can inspect the excerpt. They can rebuild the index. For many teams, “find the prior conversation where we discussed this repo and hand me the transcript” is enough leverage without introducing a vector database, a hosted service, or a new retention policy.

Local-first is not automatically safe

Recall’s local-first posture is the right privacy default. Coding-agent transcripts often contain source snippets, stack traces, customer references, architecture diagrams in prose, accidental secrets, internal URLs, and half-formed opinions nobody meant to preserve. Shipping that corpus to a hosted memory product is not a UX decision; it is a data-governance decision. A rebuildable index on the developer’s machine lowers the blast radius.

It does not eliminate it. ~/.recall/index.sqlite is still a sensitive database. Teams should exclude it from cloud backup if their policy requires that. They should treat it like source-adjacent data, not like a harmless cache. If laptops are managed, decide whether local agent-memory indexes are allowed, where they live, and how they are wiped. If agents are allowed to query the index through MCP, scope search by repo when possible and avoid giving every project an all-history memory hose.

The more subtle risk is stale context. Transcript search can rehydrate bad decisions as efficiently as good ones. If an old session contains a failed debugging path, a deprecated API choice, or a temporary security exception, an agent may retrieve it and act as if it is institutional knowledge. This is where process beats product. Mark superseded decisions in docs. Keep durable choices in versioned architecture records. Teach agents to ask whether a retrieved memory is current before applying it. Memory without freshness checks is just technical debt with better recall.

There is also a secrets angle the industry keeps underplaying. “The tool only reads local transcripts” sounds safe until you remember how many developers paste tokens, connection strings, or customer identifiers into chats during a fire. A search tool makes those mistakes easier to find, including by an agent. That is useful during incident response and dangerous during routine automation. If Recall becomes part of a team workflow, pair it with secret scanning and a norm that agents should not quote or reuse credentials found in old sessions.

The practical recommendation is straightforward. Use Recall as a search layer, not an oracle. Keep it local. Scope by repository. Ask the agent to cite the transcript. Treat the index as sensitive. Prefer it for recovering prior decisions, commands, and debugging trails, not for establishing policy. If a remembered fact matters, promote it into a durable project file where humans can review it.

The bigger market read is that agent memory should start boring. The ecosystem does not need every coding assistant to grow an autobiographical second brain before it can be useful. It needs provenance, locality, and cheap retrieval from the artifacts developers already created. Recall is early, tiny, and v0.1 by its own admission, with incremental indexing, MCP server support, and a pi extension working while a filesystem watcher and TUI are still planned. That is fine. The product is valuable precisely because it does less than the category usually promises.

If source article disappeared tomorrow, the idea would still stand: the first serious memory layer for coding agents should be read-only, local, repo-scoped, rebuildable, and cited. Everything beyond that has to earn its complexity. Search the chats you already have before inventing a second brain. The cape can wait.

Sources: pratikgajjar/recall, Recall v0.1.1 release metadata, HN launch item, rohitg00/agentmemory, DeusData/codebase-memory-mcp, SQLite FTS5 documentation