Files, Databases, or Memory APIs: 6 Ways to Make AI Agents Remember Between Runs

Every scheduled agent wakes up with amnesia. When a run ends, the context window dies with it, and the next run starts blank, re-deriving everything from scratch. Agent memory is never a default: it is always a layer you deliberately add. The right layer depends on what you are losing: raw conversation history, decisions and reasoning, or durable project facts.

Here are the six that genuinely work in 2026.

1. Files on disk: memory.md, CLAUDE.md, session hooks

The simplest durable approach: the agent writes notes to a markdown file at the end of each session and reads them back at the start of the next one. Claude Code users wire this with hooks, a save step before the session ends, a restore step when a new one opens.

It wins on one machine with one agent and one project: zero infrastructure, memory as plain text you can audit. It loses the moment a second tool enters: cross-tool invisibility, write collisions, and rot when nobody maintains the file.

2. Framework session services on a real database

If you build agents in code, use your framework's session service with a real database instead of the in-memory default. Google's ADK ships DatabaseSessionService for SQLite, Postgres, or MySQL, with memory tooling for cross-session recall; LangGraph's checkpointing layer does the same job, often on Redis.

This is memory as a library, winning when you own the agent code and want persistence without a new vendor. The tradeoff: you own the schema, migrations, retrieval quality, and the ops. And "memory" here usually means session state, what happened, not the reasoning behind your decisions, which still dies unless you save it explicitly.

3. Hosted memory APIs: Mem0, Zep

Memory APIs extract facts from conversations behind add/search endpoints. Mem0 advertises 26% higher accuracy than OpenAI's memory on the LOCOMO benchmark with far fewer tokens than full-context replay (their evaluation, their marketing; weight accordingly). Zep takes a different bet: a bi-temporal knowledge graph that tracks both what was true and when it became true, so "the deploy target changed" is a first-class event rather than a contradiction to smooth over.

These win in production apps where the agent is a feature and you want memory as an API call. Two honest costs: it is a developers-only path, and extracted facts are summaries, the full reasoning chain behind a fact is usually discarded.

4. Self-hosted MCP memory servers

The MCP ecosystem spawned memory servers you run yourself. EchoVault is the cleanest example: MCP-native, exposing memory_save, memory_search, and memory_context to Claude Code, Cursor, Codex, and OpenCode against one local vault, everything as markdown on your machine. Mem0's open-source build is the other end: self-hostable, SDK-driven, with MCP integration.

This wins when your data cannot leave your hardware or you want zero subscription cost. The tradeoff: you are the sysadmin now. Local means one machine, a phone-based agent cannot reach the vault. Several of these projects are tiny teams, so check commit activity first.

5. Cloud memory services over MCP

This is the category Vilix AI sits in: a cloud-hosted memory layer every AI tool connects to over the Model Context Protocol. Connect Claude, Codex, Cursor, and your headless scheduled agents to one Vilix AI account (OAuth, or an API key as the Bearer header to the MCP endpoint), and they all share one memory. Cloud-hosted means zero infrastructure on your side.

The difference that matters is fidelity: the agent stores full conversation exchanges with save_turn and pulls relevant context with get_context, using semantic retrieval that finds what you meant, not just what you typed. Projects, tasks, and personal rules live in the same account, editable from the dashboard at app.vilix.ai or any connected AI. Conflicts follow a stated last-write-wins policy: correct something once and it becomes the truth everywhere.

The honest tradeoff is cloud-only, no self-host option. The counterweight: export everything in a portable format or wipe the account instantly, a free plan forever, and a 7-day Pro trial with no credit card (Starter $10/month or $100/year, Pro $20/month or $200/year). It wins when you run multiple AI tools or scheduled agents and refuse to operate infrastructure.

6. Session-observation capture: claude-mem

The newest entries, led by thedotmack/claude-mem, hook into the agent's session lifecycle, capture what the agent investigated, learned, completed, and queued next, compress those observations into semantic summaries, and inject the relevant ones into future sessions. Storage is local (SQLite plus Chroma), installed as a Claude Code plugin, compatible with several CLI agents.

It wins on fidelity-per-effort for coding agents: zero manual memory writes, and compressed summaries beat dumping raw transcripts into the prompt. Two caveats: compression is lossy by design, the detail that mattered can vanish inside a summarized dead end; and it is AGPL-3.0, read the license before it touches commercial work. It targets coding sessions, not a cross-tool scheduled fleet.

Quick comparison

Approach	Best for	You operate	Crosses tools	Keeps reasoning
Files + hooks	One project, one agent	Nothing (files)	No	Yes, if written
Framework session DB	Your own agent code	The database	No	Rarely
Hosted memory API	Production app features	Nothing	Via your code	As summaries
Self-hosted MCP server	Privacy, zero subscription	The server	On that machine	Varies
Cloud MCP memory	Many tools + scheduled agents	Nothing	Yes	Full exchanges
Session capture	Coding-agent fidelity	A plugin	On that machine	Compressed

FAQ

How do I make an AI agent remember context between runs?
Persist what matters outside the context window: recap files, a database-backed framework session service, a hosted memory API, a self-hosted MCP memory server, or a cloud memory service over MCP so every tool shares one account.

Why do agents forget everything between runs?
LLMs are stateless: a new run is a new context window. Framework session state dies with the process. Memory is always an explicit layer, never a default.

Is a bigger context window a substitute for memory?
No. It helps within one run, but the next run still starts empty. Memory stores once and retrieves only the relevant slice.

Local or cloud memory?
Local wins on privacy and cost; cloud wins when multiple tools or devices must reach the same memory. If your threat model forbids external storage, that decides it.

What breaks most often?
Stale memory nobody updates, retrieval returning noise, and conflicting facts from different tools with no conflict rule. Confirm a stated conflict policy before committing.

How to choose

Start from constraints, not feature lists. One agent, one machine: files. Your own code: framework session service. Memory as a product feature: hosted API. Data cannot leave the building: self-hosted MCP server. Multiple tools plus scheduled agents, no ops appetite: cloud memory over MCP. Coding agents, zero manual writes: session capture. The failure mode is not picking the wrong option; it is picking none and hoping the next run remembers.