AI Agent Memory: Types, Architecture & How to Build It (2026)

The problem: a language model forgets everything between calls. Whatever your agent "remembers" (the customer's plan, the fix that worked last time, the fact that they asked to be emailed, not called) has to be stored outside the model and put back into the prompt at the right moment. That store, and the rules for writing to it and reading from it, is the agent's memory.

We build SynapCores, and the SQL examples use it; every example ran on SynapCores 2.4.3. The types, the loop and the failure modes apply to any stack.

What is AI agent memory?

AI agent memory is the information an agent can use beyond the current prompt, and the machinery that keeps it current. In practice it is two things:

1. A store that survives between calls and sessions, scoped to a user, an account or a team of agents.
2. A loop that writes to it after each turn and recalls from it before the next one.

The model never "learns" from the conversation. Memory is retrieval: the agent, or the code around it, finds the right memories and adds them to the prompt.

Types of AI agent memory

Two distinctions do most of the work. Episodic vs semantic decides whether a write appends or replaces, and corruption is almost always a semantic-memory problem: appending an episode can't make the store wrong, replacing a fact can. Short-term vs long-term decides what goes in the prompt (a budget problem) and what goes in the store (a correctness problem). For a beginner-friendly walk through both, see how to make a chatbot remember previous conversations.

The memory loop (architecture)

Whatever the framework or database, agent memory runs the same loop:

 turn ends ──► 1. EXTRACT facts / episodes
                   │
                   ▼
              2. WRITE RULE: new? duplicate? replaces an old fact? conflict?
                   │
                   ▼
              3. STORE with identity, time, source and confidence
                   │
 next turn ◄── 5. USE: put the recalled memories in the prompt
                   ▲
              4. RECALL: current state first, then the most relevant facts
                 and episodes (meaning × recency × importance)

1. Extract. An LLM or a rule turns the conversation into short statements: "moved from Azure to AWS", "prefers email".
2. Write rule. Decide whether each statement is new, a duplicate, an update to an existing fact, or a conflict to review. This is the step that keeps memory correct.
3. Store. Keep each memory with the identity it belongs to, when it was said, when it became true, where it came from, and how confident you are.
4. Recall. Before the model answers, fetch the current values of the attributes that matter, then the facts and episodes most related to the new message, weighted by recency and importance.
5. Use. Put them in the prompt in a compact, labelled form so the model can tell a current fact from an old episode.

Frameworks such as Mem0 and LangGraph's long-term store handle some or all of these steps for you, each in its own way. The questions to ask of any of them are the same: what is the write rule, and how does recall tell a current fact from a stale one?

How to build AI agent memory in SQL

SynapCores gives you two levels. MEMORY_STORE / MEMORY_RECALL are a flat semantic store: one namespace, one similarity search. CREATE MEMORY is a managed memory object that keeps episodes, facts, current state, validity intervals and provenance for each identity, and runs the write rule for you. Both are plain SQL, so any agent framework, an MCP client or a REST call can use them.

Step 1: Store and recall by meaning (the flat store)

SELECT MEMORY_STORE('customer_4821',
  'Oct 3: asked for a refund on order 1182; we promised it within 5 to 10 business days.',
  json_object('kind', 'interaction', 'channel', 'email')) AS id;

SELECT content, similarity
FROM MEMORY_RECALL('customer_4821', 'Has my refund gone through yet?', 3);

With three memories stored for this customer, the refund promise comes back first at similarity 0.64; the next match scored 0.25. This is the right tool for episodic recall. On its own it has no notion of "current value", which is what the next step adds.

Step 2: A memory object with current state, history and provenance

CREATE MEMORY support_memory IDENTITY customer_id;

One statement creates the object and five ordinary tables you can SELECT from: episodes, facts, current state, provenance and relationships. IDENTITY names the field that scopes every read and write, so one customer's memory never leaks into another's.

Step 3: Remember, including facts that replace old ones

REMEMBER support_memory FOR customer_id = 4821
  'We run the app on Azure and use Postgres 15.';

REMEMBER support_memory FOR customer_id = 4821
  'We finished moving the app from Azure to AWS last week.'
  WITH (attribute = 'cloud_provider', value = 'AWS');

REMEMBER support_memory FOR customer_id = 4821
  'Please email me, I never pick up the phone.'
  WITH (attribute = 'contact_channel', value = 'email');

Each REMEMBER stores the raw episode first, then derives facts and state from it. Stating the attribute and value outright, as in the last two statements, makes the state change certain instead of depending on extraction. Every claim also carries an authority (source_type), from system_of_record down to agent_inference, which is how a verified record beats something the agent guessed.

Step 4: Ask for the current value, not the most similar sentence

CURRENT support_memory FOR customer_id = 4821 ATTRIBUTE cloud_provider;

On 2.4.3 this returns status ok with value AWS, authority user_statement, confidence 0.85 and the time it became valid. For a customer with nothing recorded it returns not_found with a null value, and when two claims can't be separated by authority, time or confidence it returns conflict with both, instead of picking one. CURRENT is a state lookup, never a similarity search, so the older "we run on Azure" episode can't come back as the answer.

Step 5: Recall everything relevant for the prompt, and trace any fact

RECALL support_memory FOR customer_id = 4821 ABOUT 'which cloud are they on';

TRACE support_memory FOR customer_id = 4821 ATTRIBUTE cloud_provider;

RECALL returns the current state (cloud_provider: AWS, contact_channel: email) separately from the related facts and episodes, so the prompt can label which is which. TRACE returns where a value came from: the source episode verbatim ("We finished moving the app from Azure to AWS last week."), when it was recorded, how it was extracted and what it superseded. That is the audit trail you need when an agent says something surprising.

Step 6: Give an agent the memory, so it can't forget to use it

CREATE AGENT support_bot
PERSONA 'default'
TASK 'Answer the customer''s question.'
WITH (memory_object = 'support_memory', memory_identity = '4821');

The agent is created on 2.4.3 as shown. Per the SQL reference, its runtime recalls from the memory object before inference and remembers after each turn, and the identity is fixed in the definition, so the model can't read another customer's memory. The same operations are available over REST (/v1/memory/*) and as MCP tools for agents built elsewhere.

Keep memory correct: the write rule

Most agent-memory bugs are write bugs: a new fact stored next to the old one, a fact merged into the wrong customer, a guess stored as if it were verified. Four rules prevent most of them:

• Separate episodes from facts. Only facts need a replace rule.
• Use fixed attributes where you can. cloud_provider = AWS needs no model to update; free text does.
• Gate free-text replacements. Replace an old memory only when the new one is closely related and a contradiction check is confident; send near-misses to review. The chatbot memory guide measures this rule on real examples, and recipe 036 runs it in one SQL statement.
• Keep history and provenance. Never delete without a pointer to what replaced it, so a bad replacement can be undone and explained.

The same checks apply to answers as well as memories; see how to check that an AI answer is backed by your documents.

AI agent memory recipes

Each recipe is runnable SQL on the free Community Edition, and each links back here.

Long-term memory and recall

• Give any AI agent long-term memory (in SQL)
• Recall agent memory by meaning and recency
• Episodic and semantic memory for an agent
• Semantic deduplication of agent memories
• Agentic memory graph for an AI assistant

Keeping memory correct

• Catch contradictions on write, in one SQL query
• Self-consistent agent memory: refuse to remember a contradiction

Conversation memory

• Conversation memory with a rolling summary
• Conversation memory with structured facts
• Conversation memory for a voice agent
• Caller memory and personalization for returning callers

Shared memory and full agents

• Shared memory for multi-agent systems (blackboard pattern)
• Build a personal assistant agent (memory + tools + RAG)
• The backend for a coding agent: memory, code search, impact graph and audit
• Build a voice support agent (memory + routing + RAG)

Choosing where memory lives

For a comparison of databases for agent workloads, see the best databases for AI agents and AI apps in 2026.

A checklist before you ship agent memory

• Scope every memory to an identity (user, account, tenant), and test that one can't read another's.
• Split episodes (append) from facts (replace), and use fixed attributes where you can.
• Store the source, the time and the confidence of every fact.
• Recall the current state separately from similar-sounding history.
• Gate replacements, and send what the gate can't decide to review.
• Measure recall and replacement on your own conversations before trusting any threshold, including ours.