Agent Memory: A Plain-English Guide

My AI assistant remembers more about my life than most of my friends.

She knows my partner's name. She knows I'm writing a book about the Voynich Manuscript, and she knows the clients that keep giving me trouble at work, and that I have an annoying habit of starting projects on Sunday and abandoning them by Wednesday. She remembers all of that across totally separate conversations, on different days, weeks apart.

None of that is the model. The model she runs on is brand new every time it gets called. It has no idea who I am. It has no idea who you are either. The remembering is happening somewhere else, in a layer that sits in between us.

That layer is called agent memory, and it's the most important and least talked-about piece of consumer AI right now. Once you understand how it works, you stop being confused about why your AI forgot what you were working on the other day, and you start being able to evaluate AI products for what they actually do.

This is the long version of that explanation, written for people who don't write code. By the end you'll know how AI agent memory actually works, how the major providers differ, and how to set up persistent memory for your own AI in an afternoon. For the architectural side of how agents themselves are built, see our companion guide to personal AI agents. I'll use my own setup as the running example to help show some real-world uses as we go.

Why AI Forgets You by Default

Large language models are stateless. That sounds like a programming term, but it just means they don't carry anything from one conversation to the next.

Every time you talk to ChatGPT or Claude, you're talking to someone who just woke up with full knowledge of the English language and the entire internet up to some date in the past, but zero knowledge of you. The next message you send, they're awake again, no idea you ever met before. The only thing they "see" is whatever's in the prompt window right now. When the conversation ends, that window is wiped.

There's a wrinkle worth pausing on. Most modern AI tools (ChatGPT, Claude, and Zo included) can search through your past sessions while you talk to them. Ask Claude "what did we decide about the homepage last week" and it can find that old conversation and pull from it. That feels like memory, and for small asks it gets the job done. It isn't the same thing.

Session search finds old conversations. Memory maintains durable facts. The difference shows up the moment you want your AI to remember something you said in passing two months ago across forty conversations, or to know that an old fact is no longer true. Search will give you the conversation. Memory will give you the answer.

For your AI to actually remember you, three things have to happen:

1. Notice what is worth remembering during your conversation.
2. Save it somewhere that survives the conversation ending.
3. Slip it back into the prompt window when you talk to the AI again, so the model can act like it remembers you.

That pipeline is what people mean when they say "agent memory." It isn't magic and it isn't the model getting smarter. It's a separate piece of software remembering on the model's behalf.

What AI Agent Memory Actually Has to Do

Every memory system, billion-dollar startup or hobby project, has to handle four jobs. Knowing the four jobs lets you ask the right question of any product that claims to do this.

When I say one product is "better" than another, I mean it does these four jobs more cleanly for whatever you're trying to do. There's no universal winner.

The Three Approaches: Vector Search, Knowledge Graphs, and Hierarchical Memory

Almost every memory system uses one of three core techniques. Most products combine two or three of them. Once you understand each one, the marketing pages start making sense.

1. Vector search and the thing called RAG

This is the workhorse. RAG stands for "retrieval augmented generation." Don't let the acronym scare you. It just means: before the AI answers, go look up relevant background and stick it into the prompt. That's it.

Vector search is the most popular way to do that lookup. Every sentence the system saves gets translated into a long list of numbers called an embedding. Think of an embedding as the meaning of a sentence expressed as a coordinate in a very high-dimensional space. Sentences with similar meanings end up close together, even if they share no words.

So "I'm vegetarian" lands near "I don't eat meat" and "no animal products please," and far from "I love a great steakhouse." That's the magic trick. You can find related memories without matching exact words.

When you ask a new question, that question gets translated into a coordinate in the same space, and the database returns the closest saved memories. They get pulled into the prompt and the AI uses them to answer.

Vector search is great for fuzzy recall. It's what makes an AI feel like it kind of remembers you. It also has limits. It doesn't understand time, so a memory from last week and one from three years ago feel equally relevant if their meaning is similar. It doesn't understand identity, so "my brother" and "Mike" might not connect. And it can be fooled by surface similarity, retrieving something that uses the same words but means something different.

2. Knowledge graphs

A knowledge graph stores information as a network of things and the connections between them. Instead of saving "Jordan likes Stumptown coffee," a graph stores:

• Jordan (a person)
• Stumptown (a brand)
• Coffee (a category)
• Jordan → prefers → Stumptown
• Stumptown → is_a → Coffee
• This preference → first observed on → March 10, 2026

Now the AI can reason about relationships, not just similarity. Ask "what should I get Jordan for his birthday" and a graph-based system can walk from Jordan to preferences to brands to gift ideas, even if your question doesn't sound anything like the original memory.

Graphs are the right tool when relationships and changes over time matter, but the cost is complexity. Building a clean graph means extracting entities and relationships from messy conversation, and that extraction is itself an AI task that fails in subtle ways. A graph with bad data is worse than no graph because it gives you false confidence.

3. Hierarchical memory, or "the AI manages its own memory"

This third approach treats the prompt window like RAM and a larger archive like a hard drive. The AI itself decides what to "page in" when it needs something, and what to evict when the active workspace is full. The original idea came from a research paper called MemGPT, which is now the foundation of Letta.

The pitch is flexibility. Rather than a fixed pipeline deciding what to save, the model reads, writes, and edits its own memory while it works. Older context drops to the archive. Critical context stays loaded. The model can choose to bring something back when it senses it might matter.

This is the most "alive" feeling of the three. It's also the most expensive, because every memory operation can add another model call. And it depends entirely on the model making good editorial choices. If the model evicts something it shouldn't have, that memory is gone unless you have a safety net.

Most production systems combine all three. A modern memory product is usually some mix of vector search for fuzzy recall, graph structure for relationships, and either fixed or AI-driven curation for what to write down.

AI Memory Providers Compared: Supermemory, Mem0, Zep, Letta, Cognee, Memori, Honcho

There's now a healthy market of memory products and they don't all do the same thing. Here's how the major ones differ.

Supermemory

Supermemory is the one I use every day, so I'm starting here. Disclosure: I have no relationship with the company beyond being a happy user.

The CLI is dead simple

There are commands for saving/remembering, searching, listing, profile retrieval, and forgetting. Everything an agent needs to manage and retrieve memories.

Quick translation if any of this sounds technical. A CLI ("command-line interface") is just a way to control software by typing direct instructions instead of clicking around in an app. The "terminal" is the window where those instructions get typed. The important part for non-developers: you don't have to touch a terminal for any of this. Your AI does. I'm just describing what's happening under the hood.

What it ingests, and how

Most memory products want you (or your agent) to type discrete facts into them, one at a time. Supermemory takes a much wider input surface. The same API and CLI handle individual memories ("remember that I switched to Phoenix in March 2026"), full message threads from a conversation, and raw files: PDFs, web pages, images, audio, video. You hand it the source. It extracts the memories on the way in. Connectors for Notion, Slack, Google Drive, S3, and Gmail keep data flowing without you having to pre-process anything.

The first time my AI assistant pulled a useful fact out of a Google Doc I had saved months earlier, I stopped trying to be careful about what I "remembered" versus "saved."

The graph is the mental model

Supermemory describes itself as "a living knowledge graph where memories connect to other memories." Every memory is a node. Edges between them come in three flavors: Updates (a new fact contradicts an old one), Extends (new details enrich an existing fact), and Derives (an inference surfaces from a pattern). When you ask the agent a question, retrieval walks the graph instead of just returning the closest semantic match. That's why it can answer things that no single saved memory contained verbatim.

Memory is also split into containers (one per user, project, or workspace) and you can scope retrieval to one. A "container" in Supermemory's world is just a labeled bucket of memories. Think of it more like a folder with a label on the front.

Memories age and forget like you do

This is the part that surprised me most. Supermemory tracks which version of a fact is current, so superseded information gets demoted without being deleted. Time-bounded facts (an exam, a meeting, a deadline) decay after their relevance expires. Episodic memories fade unless something marks them significant. None of this is configured by hand. The system manages the lifecycle, and you stop accumulating stale facts that the agent confidently surfaces months later.

What it's not focused on

Shared team memory or strict relationship modeling. If you need a graph of who-knows-whom in a 10,000-employee company with audit trails, you want something else. If you want a memory layer for one person or a small team that just works, it's the cleanest option I've used.

I'd put Supermemory at the top of the list for personal AI assistants, solo developers, creators, and small teams.

Install my exact Supermemory setup using this Skill from the official Zo Skills hub.

Mem0

Mem0 is the pragmatist's pick if Supermemory doesn't fit. It's the most "API-shaped" of the bunch. You call add() to save and search() to retrieve, and Mem0 handles the rest behind a hosted vector + graph + reranker stack you don't manage.

How it decides what to keep

add() runs a two-phase pipeline. An LLM reads the message, pulls out key facts, decisions, or preferences, then conflict-resolves the result against existing memories so the latest information wins. You can flip the infer flag to skip extraction and store the raw text, but the default is the curated path. This is where Mem0 differs from Letta: there's an extraction LLM running alongside your agent, not the agent itself making memory edits.

How it scopes memory

Memory is layered into Conversation, Session, User, and Organizational tiers, routed via three identifiers: user_id for lasting personalization, agent_id for an individual agent's view, and run_id for short-term session context that expires automatically. That's the part that makes it work for chatbots, support agents, and sales assistants where each customer needs their own memory layer without the others bleeding in.

Compliance is a real selling point

Mem0 is SOC 2 and HIPAA compliant on the hosted plan, with self-host modes for Kubernetes, private cloud, or fully air-gapped, all on the same API. That matters more than feature parity if you're shipping into healthcare, finance, or anything that has to pass procurement at a real company.

Pick Mem0 if you're building a chatbot, support agent, or sales assistant where personalization needs to "just work" at scale.

Zep

Zep is built for cases where relationships and time really matter. Underneath, it's powered by Graphiti, Zep's open-source bi-temporal context graph framework.

Time is a first-class citizen

Every fact in Zep's graph carries validity intervals: when the fact was true in the world, and when Zep learned about it. When information changes ("Jordan lives in Phoenix" superseding "Jordan lives in Brooklyn"), the old fact is invalidated, not deleted. You can query what the agent believed about you at any point in time, not just what it believes now. That's the part most vector-only systems can't do without bolting on extra logic.

Three building blocks

The graph is composed of Episodes (the raw stream of ingested events), Entity nodes (people, products, policies, with summaries that evolve over time), and Edges (typed relationships between entities, each with their own validity windows). Retrieval is a hybrid of semantic embeddings, BM25 keyword search, and graph traversal.

Zep is the answer when your agent needs to reason about complex changing situations: a sales agent tracking a deal across three stakeholders and six months, a support agent picking up a ticket from another rep, a clinical assistant tracking how a patient's situation evolves. The conceptual model is heavier than Mem0's. You have to think about graph structure up front.

Letta

Letta, formerly MemGPT, isn't just a memory layer. It's an agent runtime built on the OS-style memory hierarchy that paper popularized. The model itself manages its own memory tiers using tools you give it.

Two-tier memory

Memory splits into in-context (system instructions, persistent "memory blocks" that always stay loaded, plus the active conversation) and out-of-context (older chat history evicted from the window, plus a vector-backed archival store). Memory blocks are visible on every turn with no retrieval step, which is how the agent "remembers" your name without searching.

The agent runs its own memory

This is the part that makes Letta different. The model edits its own memory using tools: memory_replace and memory_insert for the always-visible blocks, archival_memory_insert and archival_memory_search for the long-term store, conversation_search for past chats. There's no separate memory service deciding what to keep. The agent decides on every turn.

Pick Letta when you want maximum flexibility, transparent memory operations, and you trust the model to be a good editor of its own memory. The cost is the cost. Memory operations can add model calls, so token spend climbs. If you're doing serious agent work and want memory to be a programmable layer rather than a black box, it's the best of its kind.

Cognee

Cognee is the BYO-everything option. Pick your graph database, pick your vector store, point it at PDFs or a SQL warehouse, and Cognee builds a knowledge graph and a vector index side by side.

Two operations, lots of plumbing

The headline API is two calls. .remember() runs the full pipeline: ingestion, chunking, entity extraction, graph building, and an enrichment pass. .recall() auto-routes the query to the best retrieval strategy. The lower-level building blocks (add, cognify, memify, search) are still there if you want to compose your own flow.

Bring your own graph and vector

Cognee plugs into Neo4j, Kuzu, FalkorDB, or Memgraph for the graph side, and LanceDB, Qdrant, PGVector, Pinecone, Redis, or Turbopuffer for vectors. It ingests 38+ data types including PDFs, spreadsheets, audio files, and SQL databases as sources, which is what makes it interesting for teams sitting on a pile of unstructured documents.

The right user for Cognee is a team with a lot of messy internal documents (contracts, research papers, internal wikis) that wants the agent to actually reason across them, not just retrieve a passage that sounds similar to the question. Setup is heavier than the managed clouds. The payoff is much better answers on the questions where it matters.

Memori

Memori is the one to look at if your data can't go anywhere. Its sales pitch is that the memory store is whatever database you already run, with bring-your-own-database treated as a first-class deployment mode rather than an enterprise upsell.

Memory as classified records

Memori captures each chat turn and classifies it into structured categories: facts, preferences, rules, and summaries. It tracks attributes, events, people, relationships, and skills across entity, process, and session levels. The mental model is closer to "structured CRM for an agent" than "vector blob with similarity search."

Where the data lives is the point

Memori never moves, stores, or indexes data outside your chosen environment unless you explicitly opt into Memori Cloud. Retention is configurable per namespace or per user.

If you're at a regulated company or building a multi-tenant SaaS where each customer needs their memory completely isolated, Memori is the cleanest path. Otherwise the others will be a faster path to a working agent.

Honcho

Honcho, from Plastic Labs, takes a different angle than the rest. Where the others mostly think of memory as "save and retrieve facts," Honcho thinks of memory as "build a model of every peer in the system."

Peers, not users and assistants

Honcho's data model is Workspaces → Peers → Sessions → Messages. A Peer is any entity that persists but changes over time: users, agents, even non-human objects. Sessions can have multiple peers in them, and each peer can be queried for its own perspective on what happened. The user/assistant binary is gone. Everyone is a peer.

A background worker keeps refining

A worker called the "deriver" runs continuously between turns. It generates representations of each peer, summaries, peer cards, and runs "dreaming" tasks that refine Honcho's understanding asynchronously. By the time you call .chat() against a peer's profile, the representation has been getting sharpened in the background since the last interaction.

Pick Honcho when the value is in the assistant becoming attuned to a specific person (or to multiple peers in a system that talk to each other), not just remembering what they said. It pairs well with the more storage-flavored options if you want both.

At a glance

Local-First AI Memory: Run It on Your Own Machine

While the cloud providers were getting funded, a quieter movement built local-first alternatives that store memory entirely on your own machine. No API calls, no monthly bill, no data leaving your hardware.

A surprising amount of this wave is built on SQLite, the same database that powers your phone, your browser bookmarks, and most desktop apps. SQLite is a single file. That turns out to be a perfectly fine container for an entire memory system.

A few projects worth knowing:

• sqlite-vec turns SQLite into a vector database. It's small, runs across all the major desktop and mobile platforms, and is the foundation a lot of other local-first projects build on.
• memweave stores memories as plain markdown files on disk and indexes them into a local SQLite database with both keyword and vector search. The mental model is "your notes are the memory, the index is just an accelerator." You can edit your AI's memory by opening a markdown file in a text editor.
• Lucid is a CLI-first unified memory layer that runs embeddings locally using transformers.js. Storage is SQLite. Nothing leaves your machine.
• claude-mem is built specifically for persistent memory across Claude Code sessions, so coding agents can recall what they did before instead of starting over each time.
• OpenClaw does the same thing for personal assistants: a small local index of your markdown knowledge stored as a single SQLite file.

The shared design pattern is markdown files plus SQLite plus local embedding models plus a small index. No vector database server, no cloud account, no recurring cost. The tradeoff is that you're responsible for backups, sync between devices, and the compute to generate embeddings.

For a lot of personal use cases, that tradeoff is exactly the right one. If you have a laptop and a hard drive and you want an AI that remembers you without any of your conversations leaving your machine, this stack is genuinely possible now.

Run Any AI Memory System on Zo Computer

Out of the box, Zo doesn't ship with a memory layer. What it ships with is a real Linux server you own, with persistent storage and an AI agent that can run any command on it. That's actually the better starting point, because you're not stuck picking between the cloud providers and the local-first stacks. You can run any of them on your Zo, or several at once.

• Cloud providers (Supermemory, Mem0, Zep, Letta, Cognee, Memori, Honcho). They all expose either an API or an SDK. (An SDK, "software development kit," is a packaged library that makes a service's API easier to use from a specific programming language like Python or JavaScript. The API is the raw set of commands. The SDK is the friendly wrapper around them.) Drop your API key into Settings > Advanced, write a Skill so your agent knows when and how to use it, done.
• Local-first stacks (sqlite-vec, memweave, Lucid, claude-mem, OpenClaw). These are designed to live on a Linux machine you own. Your Zo is a Linux machine you own. You can install any of them on your Zo the same way you'd install them on a laptop, except you don't need a laptop running 24/7 for the memory to work. Same pattern: install, wrap with a Skill, talk to your agent like normal.

The Skill is the connective tissue in either case. It tells your agent when to save, how to phrase a search, which container or namespace to write to, what to do when a fact is stale. The provider is interchangeable. The Skill makes the experience consistent.

This is why the "cloud vs local-first" debate is, on Zo, mostly a non-issue. You can try a cloud provider, get a feel for it, then swap to a local-first stack if privacy starts to matter more than convenience, all without leaving the platform. You can also run two or three at once if you want different memory layers for different parts of your life.

How the Supermemory Skill on Zo works

Since I keep mentioning my own setup, here's the actual integration. On Zo, Supermemory is wired in as a Skill. A Skill on Zo is a folder of instructions, scripts, and triggers that the agent loads when relevant. It's the same pattern Zo uses for custom integrations with any other service. The Supermemory Skill teaches my Zo how to use the Supermemory CLI: when to save a memory, how to phrase a search, which container to write to, how to update an old fact instead of creating a duplicate.

In practice it looks like this. When I tell my agent something worth remembering ("I'm pivoting the novel from first to third person"), the Skill triggers, the agent runs supermemory remember from the shell with the right phrasing, and the fact is saved. When I start a new conversation and ask about the novel, the Skill triggers again, the agent runs a search, and the relevant context flows back into the prompt window before the model answers. The model itself never has to know about the memory layer. The Skill mediates everything.

That's the part that makes memory feel native instead of bolted on. The Skill is the interface, the CLI is the rails, the storage is Supermemory's cloud, and the agent doesn't have to think about any of it.

One caveat specific to Zo: at the moment, Zo doesn't have a hooks system the way some other harnesses do (the kind where memory writes can fire on a strict trigger, like "after every assistant response"). Zo's memory writes happen because the Skill prompts the agent to do them, not because a hook forces them. Hooks are on the roadmap, and once they land they'll make memory capture even more reliable. In practice, the Skill-driven approach already covers most of the cases that matter.

How to Pick a Memory System Without Overthinking It

The decision usually comes down to four questions. Answer them in order and you'll have a short list.

Who are the memories for?

Solo user, small team, or a multi-tenant product with thousands of users? Solo and small team is where Supermemory and the local-first stack shine. Multi-tenant pushes you toward Mem0, Zep, or Memori, all of which have built-in user scoping.

Do relationships and time matter?

If the agent needs to reason about who-is-who, what-changed-when, what-supersedes-what, you want a graph-backed system like Zep or Cognee. If the value is the assistant building a real model of one person, look at Honcho. If you mostly need fuzzy recall, vector-based systems like Supermemory are simpler.

Who controls memory writes?

For a fixed, predictable extraction pipeline, Supermemory or Mem0. For the model itself actively managing its own memory in real time, Letta.

Where does your data have to live?

If your data can't leave your machine, go local-first. If it can't leave your VPC, look at Memori, self-hosted Zep, or self-hosted Cognee. If you have no constraints and want the fastest path to a working agent, the managed clouds win.

The most useful thing about understanding all of this is you stop being mystified by AI products. You can ask the right question of any "AI assistant" pitch: who it's for, how it remembers, where the memory lives, who controls what gets written down. Those four questions tell you more than any feature list.

When you've picked a system you want to try, see pricing to find the Zo plan that fits.

Frequently Asked Questions

Your Zo runs any memory layer you want. Get started with Zo Computer.