Alvia compared with other approaches

This page compares Alvia with the other ways to give an application or agent memory: what each does well, where it stops and what Alvia adds. It ends with where Alvia fits beside the systems you already run. Facts about other products come from their own documentation, as of October 2026.

For the problems these approaches address, see Why memory for AI is hard.

Approach	What it keeps	When a fact changes	Fits
Claude Code memory, Codex AGENTS.md	Instructions and notes in files the agent loads	A person or the agent edits the file	A developer’s or a team’s coding agent
Provider conversation state and memory	A conversation’s items, or text files the model writes	The model or your code edits a file; a transcript grows	Continuity in a conversation; one agent’s notes
A database of conversations	Every message	A new row is added	The record of what was said
A vector database or RAG	Passages and their embeddings	Your pipeline decides	Documents that change rarely
A framework’s memory module	Items in a store you host, or the framework’s platform	Your code, prompt or threshold decides	Teams that already run the framework and its database
Another memory platform	Facts extracted from what you send, often with a graph	Each platform has its own policy; compare them	Evaluate against your own scenario
Alvia	Facts formed from what you send, each with its versions	Alvia classifies the new fact when it arrives	Facts about users and work that change across sessions

Why not Claude Code’s memory

What it does well. Claude Code loads CLAUDE.md files that people write, at the user, project, local and managed-organization levels, and an auto memory that Claude writes for itself, stored per repository on the developer’s machine. A project CLAUDE.md lives in Git, so the team reviews it like code. Anthropic describes both as “context, not enforced configuration.”

Where it stops. It serves the coding agent, not your application’s users. Auto memory stays on one machine. A changed decision is an edit: someone has to find the old line and replace it. What loads depends on where the agent works, not on what it asks: CLAUDE.md files in the working directory and above load in full at the start of every session, while those in subdirectories and rules scoped to paths load when Claude works with matching files. Auto memory loads the first 200 lines or 25 KB of its index, MEMORY.md, at the start of a session, and Claude reads its other notes when it needs them.

What Alvia adds. Decisions shared by people, repositories and agents through MCP or the REST API. A changed decision becomes the memory’s next version, and the agent asks a question and gets the decisions that answer it. The two work together: a line in CLAUDE.md can tell the agent when to ask Alvia. See Memory for coding agents.

Why not Codex’s AGENTS.md or memories

What it does well. Codex reads AGENTS.md before any work, from your global file down to the current directory, with closer files taking precedence. It is versioned with the code. Codex memories, off by default, distill earlier chats into local files.

Where it stops. OpenAI calls memories “a helpful recall layer, not … the only source for rules that must always apply.” AGENTS.md is capped at 32 KiB by default and rebuilt on every run. Both serve one developer’s agent, not your application’s users.

What Alvia adds. The same as for Claude Code: shared, queried decisions whose changes are recorded. Keep durable rules in AGENTS.md.

Why not the model provider’s conversation state or memory

What it does well. OpenAI’s Responses and Conversations APIs keep a conversation on the server: Responses chains turns and keeps them for 30 days by default, and a Conversation is durable and reusable across sessions and devices. Anthropic’s memory tool lets Claude create and edit files that your application stores.

Managed Agents memory stores, in beta, keep versioned text files that the agent reads and edits. A dream, in research preview, consolidates a store and past sessions into a new store.

Where it stops. A conversation object holds a transcript, keyed by conversation, not facts about a user across conversations. With the memory tool, “memory lives entirely in your application”: you implement storage, path safety, size limits and expiry. In a memory store, a changed fact is an edit the agent makes to a file. When it writes the new fact without editing the old one, the two sit side by side until a later edit or a dream reconciles them. Each is tied to one provider’s API.

Memory stores and Alvia differ in who resolves how a new fact relates to the old, and when. In a memory store, the agent decides as it edits, or a dream consolidates later into a new store that you review. Alvia classifies each new fact when it arrives, records the date it was stated and keeps a contradiction as two linked memories for your application to settle.

What Alvia adds. Facts about each user across every conversation and every model provider, with the relationship between old and new facts classified by the service when each fact arrives.

Why not store conversations in a database

What it does well. A table of messages is complete and yours. It is the record of what was said, and you need it for audit and support anyway.

Where it stops. A log records what was said; a prompt needs the facts that apply now. To use the log in a prompt you either load all of it, which outgrows the context window, or search it, which is the next question.

What Alvia adds. Keep the table. Send each conversation to Alvia with Import conversations, and read the facts that formed from it.

Why not a vector database or a RAG pipeline

What it does well. Similarity search with metadata filters, and deletion by ID, by filter or by namespace. Pinecone, for example, recommends one namespace per tenant. For documents that change rarely, such as manuals and policies, it is the right tool.

Where it stops. It returns what is similar, including a fact that has since been replaced. Deciding what to store, merging repeats, detecting that a new record replaces an old one, dating each fact and carrying a deletion to every derived record are left to your pipeline. Adding a timestamp and sorting by newest picks the record sent last, which is not always the fact true now: a backfill sends old facts late, and a timestamp cannot tell whether two records describe the same thing.

What Alvia adds. The relationship between a new fact and what is already held, classified when the fact arrives. Pair it with document search: search for manuals and policies, Alvia for the facts that change.

Why not a framework’s memory module

What it does well. LangGraph keeps long-term memory in a namespaced Store with put, search and delete. On a LangSmith deployment, LangChain’s server provides a built-in store backed by Postgres, so you do not run one yourself. LangMem adds a background manager that extracts, consolidates and updates memories in it. CrewAI asks a model to keep, update, delete or insert when a new record resembles an old one, and weighs recency in recall. LlamaIndex flushes short-term memory into long-term blocks. Apart from a LangSmith deployment, they run in your process, on storage you choose.

Where it stops. You host and operate the store, unless the framework’s platform hosts it, and the update policy is your prompt or threshold, which you tune and test. The memory works inside one framework.

What Alvia adds. A hosted service with one update policy, callable from any framework or language over REST or MCP. You can call it from a framework’s tool.

Why not another memory platform

Other services take different approaches:

Zep and its open-source engine Graphiti record when each fact was true and when Zep learned it, and invalidate a changed fact rather than delete it.
Mem0 extracts facts with a model, scopes them by user, agent, app and run, and adds memories without overwriting earlier ones. Its platform’s temporal reasoning ranks memories whose event dates match the query.
Letta keeps each agent’s memory as files in a Git repository that the agent edits itself as it learns, and that persist across conversations and models. A background process can review recent conversations and update the memory.
Supermemory records update, extend and derive relationships, and an update replaces the old fact for search and retrieval.

Alvia classifies each new fact when it arrives and keeps every version of a memory, each with when it was stated, when Alvia recorded it, how the change was classified and why. Your application reads a memory’s history, versions and relationships through the API, and the dashboard shows the same history with a graph of how memories connect.

Compare platforms on your own scenario, not on a feature list:

Who resolves a change, and when. At write time by the service, at read time or by the agent
History. Whether earlier facts are kept and whether you can read them. Alvia keeps every version of a memory and returns its history, versions and relationships through the API
Time. Whether each fact keeps when it was stated, when it was recorded and when a later fact replaced it
Scope. How users, teams and tenants are separated
Deletion. What forgetting removes and how to erase it all
Hosting. Managed, self-hosted or open source, and where the data lives
What a read returns. Records, a generated answer or both

Test each with a changed fact, a contradiction, a backfill with old dates and a deletion. See Evaluate Alvia.

Why not build it yourself

A prototype that stores messages and returns the closest matches is a small project. Memory that stays correct as facts change is a different engineering problem. To match what Alvia does, a team has to design, build, tune and operate each of these:

extracting facts from text, and evaluating the prompt that does it
detecting repeats, replacements, refinements and contradictions, and tuning the thresholds
keeping versions, and the date each fact was stated, through backfills that arrive out of order
resolving relative dates on the day they were said
scoping every write and read, and comparing new facts only within a scope
ranking current facts above replaced ones, with decay and feedback
fitting what you retrieve to a context budget, and caching generated answers
carrying a deletion to every index, summary and cache
screening sensitive information before it becomes memory
queues, retries, rate limits and backfill throttling
testing it all again whenever you change models

Build it when memory is the product you sell.

Plan your integration

Plan for three things when you add Alvia to your stack:

Reads are a network call. Start the context read alongside your other lookups, with a timeout, and give your application a path that answers without it. A miss is a normal result.
Writes return immediately. A write returns 202, and its memories form in the background. Use the current interaction’s state until they are readable.
You control retention. Deleting a project erases all the text sent to it. Remove what must not reach Alvia before sending it.

See Production checklist and Security.

Where Alvia fits

Alvia sits beside the systems you already run. Keep each kind of data where it fits best:

Static documents. Keep manuals and policies that rarely change in a search engine or RAG pipeline, and use Alvia for the facts that change.
Authoritative values. Read plans, balances and limits from your database; Alvia holds what users said and decided.
A single session. Within one conversation, resend the history or use the provider’s conversation state; Alvia carries facts across sessions.
Your own coding agent. Keep one developer’s rules in CLAUDE.md or AGENTS.md, and add Alvia for decisions that change and are shared.
A few fixed settings. Keep them in a profile row in your database, added to the prompt, and use Alvia for the preferences that change.
Data that must stay in your systems. Keep it there, and send Alvia only the facts it may hold. See Security.