Semantic, episodic, procedural: the types of AI memory

Ask most people what AI memory is and they will describe a chat assistant remembering their name. That is real, but it is one thin slice of a much older idea. Cognitive scientists have split human long-term memory into three kinds for decades, and the same three map cleanly onto what an AI needs to give good answers.

The three are semantic, episodic, and procedural. Once you see them, you notice that almost every AI memory feature on the market covers the first one shallowly and ignores the other two. That gap is the whole story.

Semantic memory: what is true

Semantic memory is your store of facts and concepts, knowledge detached from when you learned it. You know the capital of France without recalling the moment you learned it. For an AI, semantic memory is the stable structure of your situation.

For a team that means: what the company is, what products it builds, which teams and projects are in flight, who owns what. It is the background that does not change hour to hour. When an AI knows your product is a billing platform and not a social app, that is semantic memory doing its job.

This is the layer most AI memory features gesture at, and even then only for one person. They might remember you prefer TypeScript. They do not hold the shared, structured facts of your whole team.

Episodic memory: what happened

Episodic memory is your record of specific events, tied to time and place. The meeting on Tuesday, the decision you reversed last month, the bug you shipped and fixed. It is autobiographical, ordered, particular.

For an AI, this is the layer almost nothing captures, and it is the one teams miss most. The fact that your product handles billing is semantic. The decision, made three weeks ago, to drop the annual plan is episodic. A good answer often needs both: the standing fact plus the event that changed it.

Without episodic memory, an AI answers from a frozen snapshot. It tells you the plan as it was, not as it is, because nothing recorded what happened in between. This is why a running record of activity and decisions matters so much, and why we treat it as core, see AI memory vs shared context.

Procedural memory: how things are done

Procedural memory is skill and habit, the knowledge of how to do something that you do not consciously recite. Riding a bike. Touch typing. For a team, procedural memory is your conventions: how you name branches, how you structure a PR, the review process, the house style, the way decisions get made.

An AI with procedural memory does not just know the facts and the history, it acts the way your team acts. It follows the conventions without being re-told each time. A rules file like a CLAUDE.md is an early, manual stab at procedural memory, one tool, one repo, hand-maintained. It is a start, but it does not travel or stay current.

The three types, side by side

Type	Answers	Team example	Usually captured?
Semantic	What is true	The company, products, projects, ownership	Partly, per user
Episodic	What happened	Decisions made, work shipped, with timing	Rarely
Procedural	How it is done	Conventions, process, house style	Manually, per tool

The pattern jumps out. Single-tool memory gives you a shallow, personal version of semantic memory, skips episodic almost entirely, and leaves procedural to a static rules file. The richest, most valuable layers are the ones it misses.

Why teams need all three, shared

Here is the part that single-tool memory cannot do by design: it is per-user. Your assistant remembering your preferences never becomes your teammate's assistant knowing the same things. We dig into why in per-user AI memory doesn't compound into team knowledge.

A team needs the three types shared and readable by every tool:

• Shared semantic memory: one structured picture of the company, products, teams, and projects.
• Shared episodic memory: a running record of activity and decisions, so every tool sees what happened, not a stale snapshot.
• Shared procedural memory: the conventions everyone follows, available to every tool, not buried in one repo's rules file.

That combination is shared context for AI tools, and it is what context engineering for teams is really assembling.

How BaseThread maps to the three

BaseThread is structured around exactly these layers. The context graph, the company, products, teams, projects, and you, is the shared semantic memory: the stable structure of what is true. The activity and decisions streams are the shared episodic memory: a time-ordered record of what happened and what the team settled, with tasks as the forward view. Conventions and preferences carried in that graph and read at session start act as procedural memory, so tools follow the way your team works.

Every AI tool reads the relevant slice over MCP, through the local Mac app or the remote endpoint, and writes activity, decisions, and tasks back as work happens. Integrations distill context from tools like Notion and HubSpot into the graph, the signal, not a dump. Three types of memory, shared across the team, kept current by the work.

Related reading

AI memory vs shared context: the difference

AI memory vs shared context: memory is personal and locked to one tool, shared context is team-wide and read by every tool. Here is how to tell them apart.

What is context engineering for teams?

Context engineering is the discipline of getting the right information in front of a model. For teams it means doing it once, shared, so every tool answers well.

Per-user AI memory doesn't compound into team knowledge

Per-user AI memory can't add up to team knowledge. Here is the structural reason ten people's personal memories never become one shared team brain, and what does.

What is shared context for AI tools? (2026 guide)

Shared context for AI tools is the company, project, and decision background every AI reads automatically, so your whole team's tools stop guessing.