AI Agent Memory in Practice: 4 Layers We Run in Production

Agent memory is everything that lets an AI agent use information from outside its current conversation: who the customer is, what was decided last week, what went wrong the last time it tried something similar. Google Ads data shows searches for the term roughly quadrupling over the past year, and most of what ranks explains memory types from a framework’s point of view.

This is the view from operations. We run four memory layers for our own agents at Bamboo Tech Studio. Each one covers a specific way agents forget, and each has its own way of failing quietly.

Layer 1: the shared wiki (what the whole company knows)

Our company runs on an LLM Wiki: an Obsidian vault in git that agents read and maintain. Clients, projects, servers, decisions, standards, the task register. It is the memory every agent and every person shares.

What it solves: an agent picking up a client thread knows the last decision, the open tasks and the system it runs on without anyone briefing it.

What to watch for: a single shared “hot cache” file of recent context. When several sessions write to the same file, any of them can overwrite it wholesale, and one person’s context silently disappears. Our rule: every operator has their own hot cache and log; everyone reads all of them and writes only their own.

Layer 2: lessons the agent wrote itself

Each machine running Claude Code keeps a small memory folder: one Markdown file per lesson, with the rule, why it exists and how to apply it. A few examples:

Agents do not know today’s date. Inject it on every message (why this matters for WhatsApp agents).
Zero rows can mean “dropped”, not “absent”. Confirm at the source.
A provider’s “received” is not acceptance.
Click the page before you ship it.

What it solves: the same mistake not happening twice. This is the highest-value memory we have, and it is just text files.

How it can fail: this kind of memory lives per machine and per operator. A lesson learned on one laptop does not reach an agent running on a server. That is a distribution problem, and adding another database would not fix it.

Layer 3: recall over past sessions

We use memsearch, a plugin that summarises every turn of every Claude Code session into a daily Markdown file and indexes those files for search. Since June 13 it has written 106 daily files. Search is hybrid: dense vectors plus BM25 keyword search, merged with reciprocal rank fusion, and every hit carries an anchor back to the original transcript.

What it solves: “what did we decide about X three weeks ago, and why?”

What to watch for:

Transcripts that expire. Claude Code deleted session transcripts after 30 days by default, so older work can disappear before anyone notices. Daily summaries in Markdown are what make that history recoverable, and we set retention to 365 days.
Upgrades that change the index format. A point release of a plugin can pull in a new major version of its vector store, with an incompatible on-disk format. When the summaries are Markdown and the index is derived, the fix is to move the old index aside and rebuild it, with nothing lost.

Layer 4: a memory service for conversational agents

Our longer-running assistants use Honcho, a memory service that stores messages, derives facts about each person and retrieves them with embeddings in Postgres with pgvector.

What it solves: an assistant that remembers a person’s preferences and context across weeks of conversations, which is the closest thing to what most people picture when they hear “agent memory”.

What to watch for, in the service and in the assistant around it:

Hybrid recall that is not hybrid. If embeddings are switched off in the configuration, semantic retrieval quietly falls back to something weaker, and it can look like it works for weeks. Confirm embeddings are on before trusting recall.
A full memory that still says “saved”. An assistant’s own built-in memory, separate from the memory service, can have a small cap. At about 2,200 characters it is full after five or six entries, and the model keeps telling the user it is saving things while the saves fail. The fix is a larger cap, always-on rules in a separate file, and reading writes back.
Memory on the wrong machine. Memory that only one machine can reach helps nobody. If the service moves to a laptop, every place that still points at its old address breaks, and when the laptop drops off the network the memory goes with it. Ours runs on a server every agent can reach.

Why we refused a fifth layer

We evaluated another popular agent-memory project and said no. Our verdict at the time, when we were already running four: five memory systems is strictly worse than three. Each layer is another place for facts to drift apart, another index to keep in sync and another silent failure mode. The hard problems in agent memory are distribution (getting lessons to every agent) and verification (knowing a write landed), and a new store solves neither.

The rules that keep memory honest

Markdown in git is the truth; every index is derived. If you cannot delete an index and rebuild it from files, it is not memory, it is a liability.
Pair semantic search with full-text search. Pure vector search misses exact product names, IDs and error codes, which are precisely what people search for.
Use one embedding model per system. Vector spaces are model-specific, so changing the model means re-embedding the whole corpus. We use Qwen3-Embedding-8B through the API of Tessera, an inference service we work with. It outputs 4,096 dimensions and supports truncation, and we store 1,536 because pgvector’s HNSW index on the standard vector type tops out at 2,000 dimensions.
Verify writes at the destination. “Saved” from the model means nothing. Read it back.
Watch retention defaults. A setting nobody chose can delete the history you are counting on.
Do not build memory you will not feed. A memory layer with no process writing to it is worse than none, because people trust it.

How to choose for your own agents

Rules, decisions and lessons: plain files the agent reads at the start of every session. No embeddings needed.
What happened in past work: summaries in Markdown plus a hybrid index you can rebuild.
Facts about a specific customer or user: a memory service with embeddings, scoped per person, with writes you can verify.
Your product knowledge for customer-facing answers: retrieval over your own content. That is what ChatWise does for support: it indexes a business’s pages and documents into a vector collection per site and answers from them, handing off to a human when the answer is not there.

If you are designing memory for an agent that has to work in production, we can help. It is part of every AI agent we build.

Frequently asked questions

What is agent memory?

Agent memory is whatever lets an AI agent use information from outside its current conversation: facts about the user, decisions made last week, lessons from past mistakes, or the content of earlier sessions. It can be plain files the agent reads, a searchable index of past conversations, or a dedicated memory service that stores and retrieves facts with embeddings.

What types of memory do AI agents need?

In practice we see four jobs: shared knowledge the whole team relies on, lessons an agent learned from its own mistakes, recall of what happened in past sessions, and memory about a specific person or customer. Each has different owners, lifetimes and failure modes, which is why one system rarely covers all four well.

Do I need a vector database for agent memory?

Not for everything. Rules, decisions and lessons work better as plain Markdown files the agent reads directly. Vector search pays off for recall over large volumes of past conversations, and even there it should be combined with full-text search, because pure semantic search misses exact product names and error codes.

Why does agent memory fail?

Most agent memory failures are silent: a memory store that fills up while the model keeps saying it has saved, a hybrid search that quietly falls back because embeddings are switched off, transcripts deleted by a default retention setting. The fix is to treat every index as rebuildable from a source of truth and to verify writes at the destination.

Which embedding model and dimensions should I use for agent memory?

Use one embedding model across a system, because changing it forces you to re-embed everything. We use Qwen3-Embedding-8B, which outputs 4,096 dimensions but supports truncation; we store 1,536 dimensions in pgvector because its HNSW index on the standard vector type is limited to 2,000.