Agent memory architecture with Claude Mem, Graphiti, and OpenViking

Bottom line

Agent memory is not one database. It is a set of policies and stores for different time horizons. Working state helps complete the current run. Episodic memory summarizes prior activity. Semantic or graph memory represents durable facts and relationships. An audit log preserves raw events for review. Combining all four into an unbounded transcript makes retrieval expensive and deletion uncertain.

Claude Mem, Graphiti, and OpenViking address different parts of this design. Claude Mem is oriented toward continuity across coding-agent sessions. Graphiti builds temporal knowledge graphs for changing entities and relationships. OpenViking presents itself as a context database designed for agents. Their overlap should not hide their different operating models.

The Letta vs Mem0 source-verified comparison applies the same layer discipline to a stateful agent runtime and a pluggable memory service, including hosted and self-hosted boundaries, privacy, pricing, and a fair pilot protocol.

Separate the memory layers

Layer	Purpose	Retention expectation	Typical failure
Working state	Complete the current task	Minutes to hours	Context overflow or lost intermediate state
Episodic memory	Recall relevant prior sessions	Days to months	Noisy summaries or irrelevant recall
Knowledge memory	Preserve validated facts and relationships	Policy-defined	Stale facts presented as current
Audit history	Reconstruct actions and decisions	Compliance-defined	Excessive sensitive-data retention

Each layer should have a separate owner and deletion behavior. An agent may retrieve from several layers, but the prompt should identify provenance and timestamp where that affects the answer.

Claude Mem: continuity for coding sessions

Claude Mem focuses on preserving context across Claude Code sessions. That is a concrete memory problem: a coding agent may need to recall what changed, which files mattered, and what decisions were made after the original context window is gone.

This can reduce repeated repository discovery, but session capture creates privacy and relevance questions. Teams should inspect what is recorded, where it is stored, how summaries are produced, and how a developer can delete or exclude sensitive material. Test whether recalled context still applies after a branch changes or a decision is reversed.

The strongest use case is bounded development continuity, not an enterprise truth store. Repository state and tests remain authoritative even when memory recalls a prior plan.

Graphiti: temporal relationships

Graphiti’s public repository describes real-time knowledge graphs for AI agents. A temporal graph is useful when facts have effective periods or relationships change. A customer works for one company and later another; a service depends on one API version and later migrates; a project owner changes.

Graph memory can answer relationship questions that flat similarity search handles poorly. It also requires entity resolution, extraction quality, graph storage, update semantics, and query design. A wrongly merged entity can contaminate many future answers.

Evaluate Graphiti with update and contradiction scenarios, not only insertion. Add a fact, supersede it, delete its source, and ask questions at several points in time. Confirm that the returned relationship includes enough provenance for review.

OpenViking: a context database boundary

OpenViking is positioned as a context database for agents, organizing resources and memory for retrieval. The architectural appeal is a dedicated boundary between the agent runtime and the growing context estate.

Because it is a newer infrastructure choice, teams should test its storage model, indexing behavior, supported resources, isolation, backup, and deletion before making it a system dependency. Determine whether the database stores raw content, derived representations, summaries, or all three. Verify how permissions propagate into retrieval.

“Agent-specific” should mean useful interfaces and observability, not weaker data governance.

Write memory before choosing a product

Define a memory record with an identifier, content, source, subject, creation time, effective time, confidence, access policy, and expiration or deletion rule. Add links to the raw event when retention permits. Decide which fields are model-generated and which are authoritative application data.

Then define write gates. A model suggestion should not silently become a durable fact. Require deterministic validation for structured application data and human review for consequential knowledge. Session summaries can be less strict, but they should be labeled as summaries rather than source truth.

Retrieval must be evaluated as a decision

Memory retrieval has at least four outcomes: useful recall, missed recall, irrelevant recall, and harmful stale recall. Build tests for all four. Include similar entities, renamed projects, revoked facts, deleted users, and instructions that should never be retrieved across tenants.

Measure precision and recall where labels are possible, but also inspect downstream behavior. A retrieved fact may be relevant yet still inappropriate to expose. Authorization must run before context reaches the model.

Retention and deletion

Store less by default. Define maximum retention for raw transcripts and tool outputs. Provide deletion by user, workspace, source, and time range. Verify deletion from indexes, graph edges, caches, backups, and derived summaries according to policy.

When a source document changes, either update the corresponding memory or mark it superseded. Avoid silent duplication where old and new versions compete in retrieval. Temporal representations can help, but they do not replace a source lifecycle.

A representative memory trial

Run a four-week test with a small group and a single workflow. In week one, collect only working state. In week two, add episodic summaries. In week three, add durable knowledge with review gates. In week four, execute deletion, contradiction, and cross-tenant isolation tests.

Track repeated discovery time, useful recall, irrelevant recall, stale recall, storage growth, retrieval latency, and user corrections. Ask users whether memory saved work or merely made the agent sound familiar.

Limitations and source notes

All three projects can change quickly. Verify current licenses, releases, storage requirements, model dependencies, and security documentation in their official repositories. Repository popularity is not evidence of retention compliance or retrieval quality. Hosted and open-source capabilities may differ.

Sources were reviewed July 11, 2026. This article proposes an architecture and evaluation method; it does not claim an independent benchmark winner.

Memory write policies

Define which events are eligible for memory before choosing extraction prompts. A completed task, accepted user correction, explicit preference, or validated application fact may qualify. Speculation, failed tool output, hidden reasoning, and sensitive data should not become durable memory by default.

Use a write pipeline with classification, redaction, validation, deduplication, and policy checks. Attach the source event and a confidence label. For important facts, require confirmation from an authoritative system or a person. A model-generated summary can be useful episodic context while remaining clearly distinct from source truth.

Rate-limit memory creation. Otherwise every agent step creates another summary that later summaries must summarize. Track the ratio of written memories to memories actually retrieved and used. Low-use memory is a storage and privacy cost.

Temporal correctness

Time is central to durable memory. Store when the source was observed, when the fact became effective, and when it stopped being valid if known. “Alice owns service A” is incomplete without a time range when ownership changes.

Graphiti’s temporal orientation is relevant here, but the application still needs authority rules. A recent chat message should not automatically override an HR or service-catalog record. Define source precedence and surface conflicts rather than selecting whichever embedding is closest.

Test questions in historical and current forms. Ask who owned the service last quarter and who owns it now. Verify that deletion or correction removes the invalid edge from future answers while preserving audit evidence only where policy permits.

Multi-tenant isolation

Memory systems amplify isolation mistakes because retrieved context may look plausible in another user’s conversation. Partition storage and indexes by tenant or enforce authorization at query time with independently tested controls. Do not rely on prompt instructions to avoid cross-tenant recall.

Build adversarial tests with similar project names and overlapping people. Attempt direct and indirect requests for another tenant’s facts. Inspect caches, summaries, graph traversals, and backup restoration procedures for the same isolation guarantee.

Administrative search also needs policy. Support staff should not receive unrestricted memory access merely because they operate the system.

Memory compaction

Long-running agents need compaction, but compaction is lossy. Preserve stable decisions, unresolved questions, commitments, and source references. Remove conversational filler and repeated observations. Keep a link to raw history only when retention policy allows it.

Compare summary versions against a fixed set of recall questions. A shorter summary is not better if it drops the constraint that prevents an unsafe action. Consider hierarchical summaries by session, project, and time period rather than repeatedly rewriting one global profile.

When the compaction model changes, evaluate old and new summaries before bulk migration. The model is part of the memory write system and should be versioned.

Observability for retrieval

For each answer, log which memory queries ran, which records returned, their scores or traversal paths, policy filters, and which items entered model context. Provide a way for users or reviewers to inspect and correct recalled memory.

Monitor empty retrievals, high retrieval volume, stale-memory use, cross-source conflicts, and user rejection. A rising correction rate may indicate extraction drift or poor expiration policy rather than a weaker generation model.

Do not expose sensitive raw memory in broad application logs. Use identifiers and controlled review tools where possible.

Backup, restore, and deletion drills

Backups can undermine deletion promises. Document retention and encryption for backups, and define when a deleted record disappears from restore points. Test restoration into an isolated environment and confirm that indexes and graph structures rebuild consistently.

Run deletion drills quarterly. Delete one user’s history, one source document, one graph entity, and one time range. Search through every retrieval interface afterward. Record exceptions that remain for legal or audit reasons.

Cost model

Memory cost includes extraction model calls, embeddings, graph updates, storage, index maintenance, retrieval, context tokens, backups, and review. More memory can increase generation cost by adding context to every run.

Track cost per useful recall and latency added per task. Apply tiered storage: recent working memory may need low latency, while archived history can be slower or unavailable to the agent. Expire records that have no continuing purpose.

Adoption questions

Before selecting Claude Mem, Graphiti, OpenViking, or another layer, verify license, deployment model, supported stores, model dependencies, export format, isolation controls, deletion APIs, observability, and upgrade path. Ask how schema changes affect existing records.

Prototype migration by exporting a small memory set and reconstructing it elsewhere. A durable memory system should not trap the only copy of user context in an opaque representation.

Document the result as a memory contract that users and operators can inspect.

Decision

Use Claude Mem when the narrow problem is coding-session continuity. Use Graphiti when changing relationships and temporal queries justify a graph. Evaluate OpenViking when a dedicated context database is the desired boundary. In every case, make memory selective, attributable, testable, and deletable. The best memory system is not the one that remembers most; it is the one that retrieves the right evidence without violating the user’s expectations.