“Memory” gets used as one word for at least five different things AI agents need, and mixing them up is why so many “give the agent memory” projects under-deliver. A longer context window solves a different problem than a vector database, which solves a different problem than an approval workflow. Knowing which kind of memory a task actually needs is the difference between an agent that recalls and one that just repeats.
The working taxonomy
Episodic memory is the record of specific past events — this conversation, this session, this ticket. It answers “what happened last time we talked.” Most chat products’ “memory” feature is episodic: it remembers your name, your preferences, the thread from yesterday. It’s useful and it’s also the shallowest kind — it doesn’t tell an agent whether what happened last time was correct, only that it happened.
Semantic memory is general knowledge — facts, definitions, how a system works. A model’s training data is semantic memory, and so is a well-organized internal wiki. It answers “what is true in general,” not “what did we specifically decide here.”
Procedural memory is knowledge of how to do something — the steps, the conventions, the expected shape of the output. In agent systems this often shows up as a skill definition or a prompt template: not the answer, but the reliable way to produce one.
Structured memory is any of the above stored as typed, queryable records instead of free text — fields, relationships, and schemas rather than a paragraph an agent has to re-parse every time. Structure is what makes memory retrievable by task instead of only by keyword search, and it’s what lets a system detect when two records conflict instead of silently holding both.
Decision memory is the one most agent architectures skip entirely: a governed record of what the organization specifically chose, why, what it rejected, who approved it, and whether it still holds. It’s structured, like the category above, but it adds something none of the others have — an approval gate. Nothing becomes decision memory until a human signs off on it.
Why the first three aren’t enough for organizational work
Episodic, semantic, and procedural memory can make an agent fluent. They can’t make it aligned. An agent can remember your last five conversations (episodic), know how databases generally work (semantic), and know the standard shape of a migration script (procedural) — and still ship a migration that violates a constraint your team decided on in a meeting eight months ago, because none of those three memory types store organizational decisions, only facts and patterns.
This is the exact gap we describe in why AI coding agents ignore your team’s standards: the agent isn’t confused about how to code. It’s missing the one memory type that would tell it what your organization specifically decided, as opposed to what’s generally true or generally done.
Decision memory, broken into four object types
In practice, decision memory isn’t one blob — it’s four related, structured object types:
| Object | Answers | Example |
|---|---|---|
| Decision | What was chosen, and why | “We standardize on JSON for machine artifacts” |
| Rule | What must or must not happen | “Never store artifacts in Excel” |
| Skill | How a class of work is done | “Define schema, validate, store an example” |
| Authorization | Who may do what | “Agent may write to the repo; external upload needs approval” |
This is what makes decision memory structured rather than a pile of notes — each object has a schema, a status, an owner, and links to the others. A rule without a link to the decision behind it is just an assertion nobody can evaluate when circumstances change.
The approval gate is the part that’s easy to skip
It’s tempting to let an agent write directly into structured memory once you have the schema — after all, storing a record is a mechanical task. Resist it. The value of decision memory over a database of agent-generated notes is that a human decided it’s true. Agents can propose candidate decisions, rules, and skills; a human reviews and approves before anything becomes memory other agents rely on. Skip that gate and you’ve built a fast way to propagate one agent’s mistake to every other agent that queries it.
If you’re deciding what kind of memory to build first, start with the type your organization is actually missing — for most teams that’s decision memory, not another vector store. See the full model in what Decision Memory is.
One team. One workflow. One memory loop.
Test Decision Memory with a single agent workflow in 2–4 weeks.