Architecting an Agentic OS: Implementing Multi-Tiered Semantic Memory and Row-Level Security for Claude Code

In the current landscape of LLM-based coding agents, a significant bottleneck persists: the "memory tax." While tools like Claude Code offer unprecedented capabilities in codebase manipulation and terminal execution, their out-of-the-box (OOTB) memory architecture is fundamentally ephemeral. Without a robust persistence layer, every new session incurs a cognitive overhead where developers must re-explain architectural decisions, pricing models, and project preferences.

This post outlines the engineering blueprint for transforming a standard coding agent into an Agentic Operating System by implementing a multi-tiered memory architecture inspired by G-Brain, Hermes, and Memsearch, utilizing PGLite and PGVector for local-first, high-fidelity retrieval.

The Failure Modes of Native Agent Memory

To build a superior system, we must first deconstruct why standard implementations—specifically Claude Code’s auto_memory function—fail in production environments. We can categorize these failures into three critical vectors: Storage, Injection, and Recall.

1. Sparse Storage

Claude Code utilizes an auto_memory feature that relies on the agent's internal judgment to write updates to a memory.md file. In practice, this is highly unreliable. Because the agent only captures what it deems "important" during its turn-taking, the resulting index is sparse and lacks longitudinal depth. After months of usage, an unmanaged memory.md might contain only a handful of disconnected entries, failing to capture the evolution of a project's requirements.

2. Contextual Injection Deficits

Effective agentic workflows require more than just a large context window; they require curated context. Standard injection usually involves loading a static claude.md or a basic memory.md. This lacks the "frozen snapshot" pattern—a method of injecting a highly dense, capped set of recent, high-value facts (e.g., user.md, daily_log.md) at the start of every session to prevent context rot and token bloat.

3. Primitive Recall Mechanisms

Native recall is often limited to keyword matching or manual session resumption via Conversation IDs. This lacks semantic depth. If a user asks about "payment processing," an agent without vector-based retrieval will fail to retrieve discussions regarding "Stripe" or "LemonSqueezy" unless those exact strings are present in the immediate context window.

The Proposed Architecture: A Four-Pillar Memory System

Our implementation synthesizes proven patterns from several open-source frameworks to create a robust, verifiable memory layer.

Pillar I: Verifiable Citations (The G-Brain Pattern)

Drawing inspiration from Gary Tan’s G-Brain, the system does not merely return information; it returns provenance. Every retrieved memory chunk is paired with its metadata: the specific file source, the exact conversational context, and a timestamp. This allows the agent to admit uncertainty ("I cannot find a definitive decision on this") rather than hallucinating, which is critical for team-based decision-making.

Pillar II: The Frozen Snapshot (The Hermes Pattern)

To solve the injection problem, we implement the Hermes agent pattern. At the start of every session, the system executes a hook that injects a curated, capped amount of context. This includes:

• user.md: Permanent user preferences and persona constraints.
• memory.md: A distilled, high-density summary of durable project facts.
• Daily Logs: A snapshot of the most recent work completed in the current session cycle.

By capping this injection, we prevent "context bloat," ensuring that the agent's reasoning capabilities remain sharp and token usage remains efficient.

Pillar III: Hybrid Semantic Retrieval (The Memsearch Pattern)

We implement a hybrid search strategy that combines Vector Similarity Search with Keyword Matching. By chunking conversations into embeddings, the system can perform semantic queries. This enables "meaning-based" retrieval—where a query about "billing infrastructure" successfully triggers the retrieval of chunks containing "subscription logic" and "StCI integration," even without lexical overlap.

Pillar IV: Scoped Multi-Tenancy (Row-Level Security)

For enterprise or team use, memory must be isolated. We implement a scoped access model where every memory entry is tagged with an ownership attribute (system, team, client, or private). Using PostgreSQL Row-Level Security (RLS), we ensure that a developer assigned to "Client A" cannot query the vector embeddings or metadata associated with "Client B."

Technical Implementation: PGLite and PGVector

While frameworks like Memsearch are powerful, they often introduce heavy external dependencies. For our Agentic OS, we transitioned to PGLite (a WASM-based, local-first PostgreSQL) paired with PGVector.

This choice was driven by three engineering requirements:

1. Zero External Dependencies: The entire memory engine runs locally on the developer's machine, ensuring low latency and privacy.
2. Cross-Platform Compatibility: PGLite eliminates the complex dependency chains that make Memsearch difficult to deploy on Windows environments.
3. Scalable Scoping: By using a full PostgreSQL implementation (moving to a hosted Railway instance for teams), we can leverage native RLS to enforce strict data boundaries across different user scopes.

The Data Pipeline: Stop Hooks and Re-ranking

The lifecycle of a memory follows a rigorous pipeline triggered by Stop Hooks after every LLM turn:

1. Evaluation: The agent evaluates the current turn: Is this a durable fact, a preference change, or an environmental update?
2. Short-Term Update: If significant, the system updates the memory.md file (the "short-term" layer) and checks for duplicates or overrides of existing facts.
3. Long-Term Embedding: The turn is chunked, embedded via an embedding model, and upserted into the PGLite/PGVector database.
4. Three-Tier Retrieval: When a query is issued:
   • Tier 1: Search the immediate context window (Short-term).
   • Tier 2: Perform hybrid vector/keyword search against the PGVector store.
   • Tier 3 (Re-ranking): The top $N$ results are passed through a re-ranker to synthesize an answer that cites specific lines and dates from the retrieved chunks.

Conclusion

Building an Agentic OS requires moving beyond treating LLMs as stateless functions and instead treating them as stateful entities with structured, verifiable, and scoped memory. By combining the precision of G-Brain's citations, the efficiency of Hermes' snapshots, and the robust storage capabilities of PGLite/PGVector, we can bridge the gap between a simple coding assistant and a true autonomous agentic partner.