# What is AI agent memory? Types, architecture, and examples

> A practical model for how agents retain useful context across turns, sessions, tools, and time.

Published: 2026-07-11
Updated: 2026-07-11
Author: Ocean Labs

AI agent memory is the system that lets an agent retain, update, and retrieve useful information beyond its current context window. It can hold recent conversation state, durable facts, past decisions, and relationships between them. A complete memory system does more than store text: it decides what remains useful as knowledge changes.

## Why an agent needs memory

A language model receives a finite context for each turn. When that context disappears, the model does not carry the experience forward by itself. Longer context windows delay the reset, but they do not decide what matters, reconcile conflicting facts, or make knowledge portable between tools.

Memory closes that gap. It lets an agent answer questions such as:

- What did this person already decide?
- Which constraint still applies?
- What changed since the last run?
- Where did this fact come from?
- Which other agent learned something relevant?

The useful unit is not simply a past message. It is context that can still guide the next action.

## The four types of AI agent memory

| Type              | What it holds                           | Typical lifetime | Example                         |
| ----------------- | --------------------------------------- | ---------------- | ------------------------------- |
| Working memory    | The active task, plan, and tool results | One run          | The files being changed now     |
| Episodic memory   | Events and observations in sequence     | Days to years    | A decision made during a launch |
| Semantic memory   | Consolidated facts and concepts         | Until revised    | The project's deployment model  |
| Procedural memory | Reusable ways of working                | Until replaced   | How releases are verified       |

Real systems often blend these types. A conversation begins as an episode. A repeated preference becomes semantic memory. A successful sequence becomes a procedure.

## The memory loop

An agent memory system has four jobs:

1. **Capture.** Record a useful event, decision, preference, or source.
2. **Organize.** Connect the new material to what is already known.
3. **Maintain.** Merge duplicates, preserve provenance, and surface contradictions.
4. **Recall.** Retrieve the smallest relevant context for the task at hand.

This is the difference between memory and an archive. An archive keeps what happened. Memory keeps what remains useful.

Recent research increasingly treats this as a data-management problem rather than a vector-search feature. The survey [Are we ready for an agent-native memory system?](https://arxiv.org/abs/2606.24775) separates representation, extraction, retrieval, and maintenance, and finds that no one architecture dominates every workload.

## Common architectures

### Conversation history

The simplest approach sends recent messages back to the model. It preserves exact wording, but grows quickly and loses older context.

### Summaries and profiles

A model compresses conversations into shorter facts or a user profile. This saves tokens, but compression can remove nuance and make the source hard to inspect.

### Vector retrieval

Memories are embedded and retrieved by semantic similarity. This works well when a question uses different words from the stored material. Similarity alone, however, does not express chronology, contradiction, or explicit relationships.

### Knowledge graphs

Facts become entities and typed relationships. Graphs support multi-hop questions and temporal reasoning, but require a maintenance policy or they accumulate duplicate and stale edges.

### Layered memory

A layered system keeps raw observations and derives a maintained semantic layer above them. This preserves the source while giving the agent a cleaner surface to recall from.

OceanDB uses this last model. Agents write an append-only log. [The Dreamer](/docs/dreamer) turns it into a readable wiki with citations and typed links. Hybrid search retrieves from the raw and consolidated layers.

## What good agent memory should provide

A useful evaluation asks more than whether retrieval returns a similar sentence.

- **Continuity:** does knowledge survive a new session or model?
- **Revision:** can the system represent that a fact changed?
- **Provenance:** can a person inspect where an answer came from?
- **Scope:** can personal, project, and team memory remain separate?
- **Portability:** can the memory leave the product whole?
- **Maintenance:** does quality improve, or does the store merely grow?
- **Control:** can a human correct or retire what the agent believes?

The right architecture follows the consequence of being wrong. A casual assistant may need a compact profile. A long-running agent making consequential decisions needs sources, history, and visible control.

## A concrete example

Suppose an agent records three observations over six months:

1. The team chose one authentication provider.
2. A migration exposed a limitation.
3. The team replaced that provider and documented why.

A flat similarity search may return all three. A maintained memory should present the current decision, preserve the earlier state as history, and cite the observations that explain the change.

That is the work agent memory exists to do: not remembering everything at once, but keeping the right past available to the present.

To see the model in practice, read [how OceanDB memory works](/docs/dreamer) or [connect an MCP agent](/docs/connect).
