Building a Custom Memory Layer for Claude Code

The Architecture of Persistent Memory

The author argues that Claude Code's native auto-memory is insufficient because it lacks robust recall, fails to cite sources, and provides no mechanism for team-based scoping. To solve this, the author designed a memory system based on four pillars: source citation (inspired by GBrain), frozen context injection (inspired by Hermes), semantic search (inspired by Memsearch), and multi-tenant access control.

Implementation Strategy

• Storage and Search: The system replaces standard markdown-based storage with a hybrid approach using PG Lite and PG Vector. This allows for both keyword and semantic search, enabling the agent to retrieve relevant context even when exact terminology differs.
• Context Injection: Instead of stuffing the entire history into the prompt, the system uses a 'frozen snapshot' pattern. It injects a curated, capped set of recent facts, user preferences, and daily logs into the working context at the start of every session.
• Source Attribution: The agent is configured to rerank retrieved results and synthesize answers that explicitly cite the source file, the specific line of text, and the date the decision was recorded, while explicitly stating when an answer cannot be found.
• Team Scoping: To enable shared team memory, the system uses PostgreSQL row-level security. Each memory entry is tagged by scope (system, team, client, or private), and queries are filtered based on the user's permissions to ensure data isolation.
• Back-filling History: The system includes a pipeline to process existing session history, chunking and embedding past conversations into the vector database so that the agent has access to prior project decisions immediately upon installation.

Context

The author developed this system to address the 'context rot' and lack of long-term recall inherent in standard Claude Code sessions. By moving from simple file-based storage to a vector-backed database, the system allows for meaningful retrieval of decisions made months prior. The current iteration focuses on local execution via PG Lite, with a transition to cloud-hosted PostgreSQL (via Railway) planned for team-based deployments.