Compare ways to give an AI agent durable memory

Before comparing feature lists, decide where memory should live. If the agent belongs entirely inside one chat product, that product’s built-in personalization may be enough. If you are building an application, you may need explicit identifiers, programmatic reads and writes, export or deletion paths, and retrieval over your own sources. If the agent runtime itself is the product boundary, a runtime with integrated memory can reduce orchestration work.

Also separate retrieval from authority. A memory system can return a relevant preference, prior decision, or policy passage; it does not prove that the information is current or that the caller may act on it. Authentication, authorization, source-of-truth checks, and tool permissions remain part of the surrounding application whichever memory approach you choose.

A self-assembled stack gives a team direct control over its schema and infrastructure choices. An embedding model converts text into vectors, a vector-capable database stores and searches those vectors alongside metadata, and object storage can retain original files. PostgreSQL with pgvector is one example, but the pattern also works with dedicated vector services and different object stores. The components are interchangeable only to the extent that your formats, models, and migration work make them so.

The component documentation does not provide a complete agent-memory policy. The application still defines stable identities, chunking, write selection, source synchronization, retention, deletion, and re-embedding when a model changes. It also determines how tenant or entity filters are enforced. That responsibility can be desirable for a team with strong data-platform expertise or a requirement to keep every layer inside its own environment; it is still engineering work that should be planned and tested.

• Best fit: teams that need direct database control, custom retrieval behavior, or deployment inside an existing data boundary.
• Main responsibility: design and operate the memory semantics that sit above the storage, embedding, and retrieval components.

Mem0’s managed platform extracts memories from messages and documents, then scopes them to users, agents, applications, and runs. Its APIs support reads, writes, filters, deletion, and structured export using those identifiers. That makes entity-aware scope a capability shared by more than one memory product, not a distinction Aether should claim by itself. Teams should compare the exact identifier model and authorization integration against their own account structure.

Mem0 also publishes an open-source engine. In that deployment model, a team can choose and operate the language model, embedder, vector store, history store, API, and related infrastructure. The managed platform and open-source engine therefore carry different ownership tradeoffs. Evaluate the one you would actually deploy rather than treating Mem0 as a single hosted-only or self-hosted-only architecture.

Letta is broader than a neutral memory database: it is a stateful-agent runtime. In the current Agent SDK documentation, an agent’s memory is represented as Markdown files in a Git-backed repository projected through MemFS. System memory is placed in context on each turn, while other memory can be read when needed. That model suits teams that want the runtime and its memory behavior to be designed together.

Memory is per agent by default, and repositories can also be shared. Letta documents memory moving with an agent between models and computers, plus self-hosted use of a team’s own Git remote. This is a different abstraction from passing an entity identifier to an external memory API. Avoid mixing these current Agent SDK claims with Letta’s legacy V1 blocks, recall-memory, or archival-memory model when making a present-day decision.

ChatGPT memory is product personalization. OpenAI documents useful context synthesized from chats, files, and connected apps, along with controls to review, correct, clear, or delete memory; Temporary Chat does not use or create memories. That can be the right boundary when the user is working in ChatGPT. It is different from an application-defined memory backend. Separately, the OpenAI Responses and Conversations APIs can preserve multi-turn conversation state; API conversation state should not be described as the same feature as ChatGPT’s cross-chat personalization.

Claude’s user-facing memory similarly builds on prior context and can be separated by project, edited, exported, or bypassed with incognito chats. Claude Platform also offers developer memory surfaces. Its memory tool is client-side: Claude requests file-like operations, while the application executes them, chooses storage, maps paths to users or database keys, and enforces security and retention. A separate Managed Agents memory-store feature is documented as beta and uses workspace-scoped, path-addressed text stores attached to sessions.

• Best fit for product-native memory: people who want continuity inside the chat product they already use.
• Developer caution: distinguish consumer personalization, API conversation state, application-owned tool storage, and beta managed stores.

Aether is designed for teams building their own agents and applications while keeping their existing runtime. The API key establishes the tenant, an optional partition can represent a narrower boundary, and the Memory handle carries a required entity ID. The SDK then uses that scope for remember and recall operations. Lower-level document and search APIs are available when the workflow needs direct corpus control or source-grounded RAG.

The practical tradeoff is managed convention versus component control. Aether supplies the memory and retrieval surface across Python, TypeScript, Go, and .NET, while your application still owns identity mapping, authorization, what should be remembered, and how recalled information influences a response or action. Choose it when that boundary matches the system you want to operate—not because every alternative lacks scope or portability.

Run the same small proof with each serious option. Store an explicit fact, recall it in a fresh session, update it, delete it, and attempt a cross-scope read that must fail. Then ingest a source document and inspect whether the result retains enough provenance for a reviewer. Record which system owns each responsibility instead of comparing only the happy-path demo.

• Identity: Can its scope map cleanly to your tenant, workspace, user, project, or agent model?
• Control: Who owns storage, embeddings, retrieval policy, migration, retention, and deletion?
• Runtime: Must the agent move into a particular execution model, or can memory sit beneath the one you use?
• Evidence: Can the workflow distinguish an inferred memory from an authoritative source passage?
• Operations: What do you monitor, back up, export, and test when a model or schema changes?