How do I choose a memory layer for AI agents?

Choose a memory layer by six criteria: who must share it, who writes to it, how it handles stale and conflicting facts, how it ranks what it returns, how much context it adds per turn, and where the data lives. For one person in one tool with short sessions, the memory built into that tool, such as Claude Code's CLAUDE.md files and auto memory, is often enough. Once several agents, tools and teams depend on the same facts, you need memory that sits outside any one vendor's tools and a clear rule for what reaches the model on each turn. Test your shortlist on your own tasks before you commit.

What kinds of memory layer are there?

Seven categories show up in production, and each covers a different part of the problem.

Category	What it does	Fits when	Where its scope ends
Memory built into one vendor's tools	Instructions and notes for that vendor's agent	One person or team, one tool	That vendor's tools
Memory libraries and providers	API or SDK to store and recall facts	You build your own agent	Your code decides what enters the prompt
Vector databases	Similarity search over embeddings	Recall by meaning	No relationships or history by default
Graph databases	Entities and their relationships	Ownership, dependencies, timelines	Work to build the graph
Context warehouses	Company context copied into one store	Many sources, one query point	Freshness depends on sync
Connectors and enterprise search	Search live systems at query time	Finding documents across apps	Returns matches, not what the agent learned
A runtime that decides per turn	Builds the working set before each model call	Many agents, tools and teams	Adds a step to every turn

These categories combine: a runtime or a library usually sits on top of a vector or graph store. See vector vs graph databases for agent memory.

Which criteria decide the choice?

Six questions separate the options for your case.

1. Sharing scope: one person, one team, or many agents across tools. Claude Code's auto memory "is machine-local", which suits one developer.
2. Write path: which agents can write, who approves, and whether each entry keeps its source and time.
3. Freshness and conflicts: whether replaced facts are marked as superseded and disagreements shown, not resolved silently.
4. Ranking: similarity only, or also recency, importance and relationships, as in the "Generative Agents" retrieval model (Park et al., 2023).
5. Context budget: how many tokens it adds per turn. Anthropic's guidance is to find "the smallest possible set of high-signal tokens".
6. Data location: where memory is stored, how long it is kept, and whether you can self-host. For GDPR, the rules depend on your country, the data and how the agent uses it; check with your data protection officer.

When is a simple option enough?

A simple option is enough when one person uses one tool, sessions are short, and the facts the agent needs fit in a few instruction files. In that case, CLAUDE.md files or Anthropic's memory tool, which runs client-side so that "you control where and how the data is stored", need no extra system and are easy to read and fix. Anthropic's context engineering guide gives the same advice for agent design in general: "do the simplest thing that works." Move to a shared system when you see the same correction repeated across tools, agents acting on outdated facts, or teams keeping separate copies of the same knowledge. For background, see what memory for AI agents is.

Where does elephant.broker fit among these?

elephant.broker belongs in the last category: a pluggable runtime for AI agents, not a memory store. The runtime sits between your harness and your business and decides on every turn what your agent sees, using a memory provider underneath: Cognee by default, or the memory you already run. elephant.broker reports on its website 40-80% less context per task, with only verified, relevant knowledge reaching the window. That is elephant.broker's own reported result, not an independent or head-to-head test. The trade-off is an extra retrieve and rerank step on every turn. See what a pluggable runtime for AI agents is and what security teams should check.

Sources

• Claude Code documentation, How Claude remembers your project
• Anthropic, Memory tool documentation
• Anthropic, Effective context engineering for AI agents (Sep 29, 2025)
• Park et al., Generative Agents: Interactive Simulacra of Human Behavior (2023)
• elephant.broker: overview and reported results, features, architectural comparison

Product details come from each vendor's public documentation as viewed on 2026-10-23 and may have changed. Product names are trademarks of their respective owners. Cognee is the default memory provider in elephant.broker; elephant.broker is not affiliated with the other products named.