AI agent memory: how an agent remembers between sessions

An AI agent has no memory of its own. Between runs, everything it knew is gone unless something outside the model wrote it down. Persistent memory means storing state externally and loading it at the start of each run. The hard part is not storing it. The hard part is knowing the state you loaded is the state you saved.

Written by the FacturIQ team. Last updated 2026-09-07. Every claim about FacturIQ here is checkable against the public route table and the public witness log.

Why an AI agent forgets

A language model is stateless. Each call receives a prompt and returns text; nothing survives the call. What looks like memory in a chat interface is the full conversation being re-sent every turn. When the session ends, or the context window fills, that history is gone. An agent that runs on Monday and again on Tuesday is, from the model's point of view, two unrelated strangers.

So agent memory is always the same shape: write state somewhere durable, read it back at the start of the next run, and put it in the prompt. The differences between approaches are what "somewhere" is, and how much you can trust what comes back.

The four approaches, and what each costs you

These are not exclusive. A common production shape is a vector store for recall plus a small sealed state file for the things that must be exactly right: what the agent decided, what it already did, what it must not repeat.

The failure nobody plans for

Storage is the easy half. The half that bites is a memory that comes back wrong and looks fine. A truncated write, a half-finished sync, a second session that overwrote the first, an editor that reformatted the file, a restore from the wrong backup. The agent loads it, believes it, and acts on it. Nothing raises an error, because nothing was checking.

This is a measurement problem, not a storage problem. The fix is a fingerprint. Hash the content when you save it. Hash it again when you load it. Compare. If the two differ, the agent stops instead of acting on a memory that is not its own.

A memory store you cannot audit is a memory store you are trusting on faith. The check costs one request and one hash.

Verifying memory on wake, in practice

The pattern is three steps at the start of every run, before any work:

1. Re-hash the local copy. SHA-256 of the bytes you were handed.
2. Ask whether it matches what was sealed. One request; the answer is match, mismatch, or unknown.
3. Branch on the answer. match: proceed. mismatch: stop and report; do not act. unknown: nothing was sealed under that label yet, so this is the first run.

HASH=$(shasum -a 256 memory/journal.md | cut -d' ' -f1)
curl -s "https://api.facturiq.com/v1/vault/journal/verify?hash=$HASH" \
  -H "authorization: Bearer $FACTURIQ_KEY"
# {"label":"journal","verdict":"match","version":7,...}

Writing the new version back uses compare-and-swap, so a second session that started from an older copy is refused instead of silently winning:

curl -s -X PUT https://api.facturiq.com/v1/vault/journal \
  -H "authorization: Bearer $FACTURIQ_KEY" \
  -H "x-vault-expected-prev: $HASH" \
  --data-binary @memory/journal.md

Every version is hashed into an append-only chain, a Merkle checkpoint over that chain is signed every five minutes, and an independent witness running outside our infrastructure countersigns each head. That means the answer to "was this memory altered?" is arithmetic that anyone can redo, not a promise from the service holding the data.

Using it from MCP

If the agent speaks Model Context Protocol, the same memory is available as tools without writing HTTP calls. Point the client at https://api.facturiq.com/mcp and it gains vault_get, vault_put, vault_verify and seal. There is a read-only profile at /mcp/read that refuses every write before touching storage, which is what you connect an unattended reading phase to.

When this is the wrong tool

If what you need is semantic recall over thousands of documents, use a vector store; sealed memory answers "is this exactly what I saved?", not "what do I know about X?". If your agent runs once and never returns, it has no memory problem to solve. And if nobody will ever need to check what the agent knew, a plain file is honestly fine, and free.

Questions people ask