Agent memory, explained
"Agent memory" gets used for at least three different things, and the conversations go in circles until you split them. An agent remembering what you said five minutes ago, an agent remembering what it learned last month, and a team's agents all knowing the same facts are three separate problems with three separate solutions. Here's the split, and where the current tooling lands.
We build Modem, which sits squarely in the third category, so read our framing with that in mind.
Short-term, long-term, shared
Short-term memory is the context window. It's what makes a conversation coherent, it's genuinely large now, and it has two structural limits that no amount of size fixes. It's finite, and it's private to the session. When the run ends, it's gone.
Long-term memory persists across sessions for one agent or one user. Claude's memory features, ChatGPT's memory, and the CLAUDE.md-file pattern all live here. The agent recalls your preferences, the project's conventions, the decision made last week. This is real memory, scoped to a person and their assistant.
Shared memory is the layer teams actually run into next. Your Claude Code session, a teammate's Cursor session, and the Modem agent answering questions in Slack should agree on which customers hit the export bug. Per-user memory can't deliver that, because each copy learns separately and drifts. Shared memory needs a store that lives outside every agent, that all of them read, and that something keeps current. That's the shape of a customer context graph.
Memory is not a vector store
The default implementation move is "embed everything, retrieve by similarity." That gives you search, which is not the same thing. Similarity retrieval returns text that resembles the question. Memory needs to return facts that are true, joined to the other facts they depend on.
Concretely, ask "which enterprise customers are affected by the export bug." A vector store returns the five messages most similar to that sentence, which may be five phrasings of one person's complaint. A memory built on structure returns the topic, the deduplicated list of people on it, and the accounts they belong to, because those joins were made when the data arrived, not reconstructed by similarity at query time. Embeddings are a fine retrieval layer over a memory. They aren't one.
What belongs in durable memory
Not everything, and cramming everything in recreates the noise problem one layer down. A workable filter, in the customer domain, is that a fact earns durability when it stays true between sessions and more than one future task will need it.
- Topics with their sources merged, so counts reflect every channel.
- People and accounts, resolved across identities, with plan and spend attached.
- Original quotes, because summaries decay and someone always needs the exact words.
- Outcomes, meaning what shipped and who was told, so the next session knows the loop was closed.
What doesn't belong is the raw feed. Durable memory holds the conclusions with evidence attached. The threads themselves stay in their source tools, reachable when an agent needs to drill down.
Team-shared memory in practice
The mechanics matter more than the concept. A shared memory is only alive if something maintains it, and only useful if every agent can reach it. Modem's answer is to do the maintenance automatically (it reads connected channels continuously and keeps the graph's joins current) and to expose the result over standard interfaces. Agents connect over MCP (claude mcp add --transport http modem https://mcp.modem.dev/mcp in Claude Code), scripts use the @modem-dev/cli package, and people just ask the agent in Slack. Every path reads the same graph, which is the entire point.
The tools landscape
Roughly three families, solving different scopes.
Personal memory layers (mem0, Supermemory, the built-in memory in Claude and ChatGPT) persist facts per user across sessions. Good for preferences and per-person continuity. They don't resolve customer identities or share across a team.
Agent-framework state (Letta, LangGraph checkpoints and their kin) persists an agent's own working state so long-running agents survive restarts. Infrastructure for the agent you're building, not knowledge about your customers.
Domain memory layers maintain a structured, shared store for one domain and serve it to any agent. Modem is this, for customer and product signal. The honest boundary cuts both ways. Modem won't remember your personal coding preferences, and a personal memory layer won't tell you which paying accounts hit yesterday's regression. Plenty of teams run one of each; they meet different needs and don't conflict.
If you're choosing today, the deciding question is scope. Memory for you, memory for your agent's own state, or memory your whole team's agents share. Answer that first and the category picks itself.
