OpenClaw Agent Memory in 2026: AMP, Engram, and the 3 Patterns That Actually Work

Why Agent Memory Is the Bottleneck

LLMs are stateless. Every call is a fresh shot — no memory of the last message, no memory of yesterday's task, no memory of who the user is unless you stuff it into the prompt. That works for chat. It breaks the moment you want an agent that does something useful over time: a CRM that remembers contacts, an inbox handler that knows which threads it already triaged, a daily briefing that builds on yesterday's notes.

The naive workaround is to dump everything into the context window. That fails for three predictable reasons: context limits cap you somewhere between 100k and 1M tokens, every token costs money on every call, and the model gets worse at long contexts faster than the marketing claims. Without persistent memory, the agent repeats work, re-asks the user the same questions, and loses any sense of progress. Memory is what turns “chat with steps” into an agent.

Pattern 1: File-Based Memory

The shape: A folder next to your agent — usually memory/, dreams/, or wiki/ — with one JSON or Markdown file per session, per topic, or per day. The agent appends on write and tails the last N entries on read.

When it wins: Solo dev. Single-agent setup. Append-only logs where you mostly care about the last few entries plus a long tail you occasionally grep. Personal tools where the “query” is “what did I say to this contact last week.” You can read the memory by opening files in your editor — that alone makes debugging an order of magnitude faster than any database-backed pattern.

Sample folder structure:

agent/
  memory/
    contacts/
      anna-chen.md
      marco-rossi.md
    sessions/
      2026-05-22-morning.md
      2026-05-21-evening.md
    wiki/
      preferences.md
      project-status.md

The Personal CRM template in the CrewClaw library uses exactly this pattern. One Markdown file per contact, appended on each interaction, tailed when you ask “what's the latest on Anna.” The Daily Briefing template ships the same pattern but indexed by date instead of contact.

Pattern 2: SQLite or Postgres Memory

The shape: A real database with tables for the entities your agent reasons about — messages, threads, tasks, contacts. Reads are SQL queries, writes are inserts and updates. SQLite for single-process agents, Postgres when more than one agent needs the same memory.

When it wins: You need structured memory — “show me every task assigned to this contact this month,” “count unhandled threads by sender,” “list all sessions that ended in an error.” Multi-agent setups where two or three agents need to see the same state. Audit trails where you genuinely want to know what the agent did and when. SQL is the right tool for any memory question that includes the word “count,” “group,” or “since.”

Sample schema:

CREATE TABLE threads (id TEXT PRIMARY KEY, subject TEXT, sender TEXT, last_seen_at TIMESTAMP, status TEXT);
CREATE TABLE messages (id TEXT PRIMARY KEY, thread_id TEXT, role TEXT, body TEXT, created_at TIMESTAMP);
CREATE TABLE tasks (id TEXT PRIMARY KEY, thread_id TEXT, summary TEXT, due_at TIMESTAMP, done_at TIMESTAMP);
CREATE INDEX idx_threads_status_last_seen ON threads(status, last_seen_at);

The Inbox Zero template uses SQLite for thread tracking — it needs to know which messages it has already triaged and which need a second pass, and that question is much cleaner in SQL than in a folder of Markdown. The Project Manager (Orion) template uses the same backing store for task state across multiple coordinated agents.

Pattern 3: Vector Store Plus Hybrid (Engram-Style)

The shape: A vector database for semantic recall — “find the past notes most similar to this question” — paired with a relational layer for structured metadata. Engram is one packaged take on this pattern; pgvector with Postgres is the do-it-yourself version. The hybrid layer is what saves it from the failure modes of pure-vector recall.

When it wins: Long-context recall where the question and the relevant memory do not share keywords. Semantic search across a big corpus — research notes, past customer threads, ingested documentation. Multi-modal memory where you store transcripts, images, and structured records side by side. Anything where “remember the conversation about pricing tiers from last quarter” needs to actually find that conversation without you knowing the date.

The Newsletter Writer template uses this pattern for source recall — it ingests articles, tweets, and notes throughout the week and retrieves the most relevant chunks when it drafts the next issue. Pure vector would surface near-duplicates; the relational layer keeps it honest by filtering on freshness and source type.

On AMP: The Agent Memory Protocol thread that landed on r/openclaw this week proposes a layer on top of MCP that standardizes how agents read and write to a memory store. The pitch is that memory becomes a portable resource — the same way MCP made tools portable across clients. It is still a draft spec. The shape is interesting because most agent frameworks today reinvent their own memory API; a common protocol would let you swap backends without rewriting the agent.

Hybrid versus pure vector: Pure vector retrieval has two well-known failure modes — it pulls semantically similar but factually wrong chunks, and it ignores structure that would have made the answer trivial (“tasks due this week” is a SQL query, not a similarity search). The hybrid pattern uses the relational layer for any question that can be answered by metadata, and falls back to vector only for the semantic tail. That single rule cuts retrieval errors more than any embedding-model upgrade.

The AMP and MCP Angle

AMP is worth understanding even if you do not adopt it today. MCP — the Model Context Protocol — solved a real problem: every agent framework used to invent its own tool-calling API, which meant connecting an agent to a new tool was bespoke work each time. MCP made tools portable. An AMP-shaped layer would do the same thing for memory: an agent declares which memory it wants to read or write, and the framework brokers that call to whatever backend (Engram, pgvector, Qdrant, file system) the user has configured.

The honest read: AMP is early. The spec might change. No major framework has adopted it as of May 2026 — the OpenClaw thread is a proposal, not a release. The reason to care now is positioning, not production use. If you build your next agent with a clean separation between “the memory API the agent calls” and “the backend the API talks to,” you can swap to an AMP-compliant backend later without rewriting the agent. That is the cheap version of future-proofing.

The Memory Pattern Decision Tree

1. First agent, solo dev, want it shipped today? → File-based. Open an editor, create memory/, ship.
2. Need counts, time-ranges, joins, or audit? → SQLite — or Postgres if more than one agent reads it.
3. Multi-agent setup with shared task state? → Postgres. SQLite locks become painful with parallel writers.
4. Long-context recall over a corpus you cannot keyword-search? → Hybrid vector — Engram or pgvector plus relational.
5. Building for portability across frameworks? → Keep the memory call site isolated and watch AMP, but pick a working backend today.

The cheapest mistake is overbuilding memory before the agent has earned it. Most agents that fail in week two fail because the builder spent the first week on a vector store the agent never needed. Ship file-based, upgrade when the queries you cannot answer pile up.

CrewClaw Templates That Ship With Memory Pre-Wired

Five templates in the CrewClaw library cover the three patterns end-to-end. Each one ships with the memory layer already wired into the generated package — no separate setup step.

All five are listed alongside the rest of the library at crewclaw.com/agents. Each one downloads as a runnable package — memory schema, embedding pipeline, or folder layout already in place.

FAQ