Most coding agents have one memory layer: whatever is currently in the context window. That single layer is ephemeral, compactable, and gone the moment the session ends. Building serious engineering workflows on top of it is the equivalent of hiring a contractor who takes no notes and starts fresh every Monday.
The full picture is four layers. Each stores a different kind of information, persists over a different timescale, and fails in a different way when it's absent. Most teams are missing at least two.
The four layers
| Layer | What it stores | Timescale | Fails without it |
|---|---|---|---|
| In-context | Everything in the current window | Current turn | Nothing works at all |
| Session | What happened earlier this session | Current session | Agent loses thread mid-task |
| Long-term | Decisions, preferences, history across sessions | Persistent | Agent re-discovers everything from scratch |
| Structural | What the codebase actually is, from parsing | Persistent until code changes | Agent reasons from wrong architectural facts |
These are not alternatives. Each handles something the others cannot. Skipping any one produces a specific failure mode the remaining three cannot compensate for.
Four memory layers of a coding agent
Layer 1: in-context memory
Everything currently in the context window: system prompt, conversation history, file contents, tool results, the current user message. The only layer every coding agent has by default, and it has three hard constraints.
It has a fixed ceiling. Context windows are large but finite. A session that reads many source files, accumulates many tool results, and runs across many turns will eventually fill.
It compacts under pressure. When context fills, agents compact automatically: older tool outputs are cleared first, then earlier exchanges are summarised. The architectural understanding built up twenty turns ago, the file reads, the grep results, the blast radius an agent carefully established, all of that is exactly the kind of content that gets cleared first. The agent continues reasoning from the summary, which is lossy by definition.
It resets at the session boundary. When the session ends, in-context memory is gone. Whatever the agent learned, whatever was established, whatever decisions were reached: none of it carries over unless another layer captured it.
In-context memory is necessary but not sufficient. It is the working memory of a coding agent, not the complete picture.
Layer 2: session memory
Session memory persists across turns within a single session but not across sessions. The purpose is to survive compaction: when the context window fills and older content gets cleared, session memory keeps that content retrievable without it needing to stay in the window at full fidelity.
This is implemented via lifecycle hooks into the agent session, capturing state before compaction fires, so findings from three hours ago remain accessible even after the raw content has been summarised out.
Without session memory, a long session that spans a full day of work becomes progressively amnesiac. The agent at turn 80 cannot rely on what it established at turn 20 if nothing was done to preserve it. With session memory, earlier findings are recoverable even after compaction.
Session memory is bounded by the session. It does not survive the session boundary. That is what layer 3 is for.
Layer 3: long-term memory
Long-term memory persists across sessions. Decisions made last week, architectural patterns the team has agreed on, user preferences stated in prior conversations, approaches that were tried and rejected, resolved issues whose resolution remains relevant. This knowledge does not exist in the codebase. It exists in what was said and decided, and it needs somewhere to live between sessions.
The typical implementation is a persistent knowledge graph combining semantic retrieval with structured graph traversal. At session start, relevant prior context surfaces automatically. At session end, the session's activity syncs into the permanent store. The agent arrives at each new session knowing what the team decided, not just what the code says.
Without long-term memory, a coding agent starts each session blank. It re-asks questions the team already answered. It proposes approaches that were previously discussed and rejected. It treats every session as the first one, regardless of how many have come before.
Long-term memory does not know what the codebase is. It knows what agents and users have said about it, stored from prior interactions. That distinction is the entry point for layer 4.
Layer 4: structural memory
Structural memory is different from the first three in a fundamental way: it is not derived from experience. It does not accumulate from what agents and users have said. It is computed directly from the code by a parser.
Enola generates this layer. Running generate_snapshot on a codebase produces a fact graph: every module, symbol, route, storage table, import edge, and call edge, extracted by real language parsers from the actual source. impact_analysis, explore, find_path, traverse: all query that graph and return deterministic results. The same commit, the same query, the same answer, every time.
Structural memory answers questions the other three layers cannot. Not what an agent said a module depended on in a prior session. Not what was in the files the agent read last turn. What the parser found in the actual code, computed exhaustively across the full graph rather than inferred from a sample.
This distinction matters because layers 1, 2, and 3 all reason from whatever inputs they were given. If the agent built its understanding of the codebase from a sample of files that missed some callers, session memory and long-term memory faithfully preserve what the agent established, including its gaps. Structural memory is the only layer that does not inherit the agent's blind spots, because it was never derived from the agent's reading of the code in the first place.
How the four layers fail together
The failure modes are specific and cumulative.
Missing layer 2 (session memory). The agent loses the thread mid-task. A long refactor session leaves the agent reasoning from a compacted summary of what it found four hours ago rather than the actual findings. Decisions made early in the session conflict with what the agent believes it decided.
Missing layer 3 (long-term memory). Every session is a clean slate. A new joiner asks the agent about the auth module and it explains from scratch, with no memory of the prior sessions where the team established what the module does, what it must not do, and why certain decisions were made. Each sprint starts as if the prior ones did not happen.
Missing layer 4 (structural memory). The agent reasons from an approximate picture of the codebase. Its blast radius estimates are incomplete. It missed callers that reference a type only through its methods, not by name. Its refactor plan is correct given what it found, but what it found was a sample, not the full graph. The plan ships, something breaks three layers away, and the post-mortem surfaces the dependency the agent did not know about.
Missing layers 3 and 4 together, the most common configuration in production today, means the agent starts each session blank and reasons from an incomplete structural picture. A capable reasoner with no institutional memory and no accurate map.
What a full stack looks like
| Layer | What provides it | What it gives the agent |
|---|---|---|
| In-context | The model's context window | Active working memory |
| Session | Lifecycle hooks, session-scoped memory store (e.g. Cognee) | Compaction-resistant session state |
| Long-term | Persistent knowledge graph (e.g. Cognee) | Cross-session decisions, preferences, history |
| Structural | Enola dependency graph | Deterministic codebase facts from parsing |
Enola is the structural layer. The setup is a one-time operation:
curl -fsSL https://raw.githubusercontent.com/enola-labs/enola/main/install.sh | sh
Add to CLAUDE.md:
For architecture, dependency, or impact questions: use Enola MCP tools (explore, impact_analysis, find_path).
One snapshot, persistent until the code changes, incrementally updated on each commit. Every session starts with accurate structural facts before the first tool call, regardless of what was or was not established in prior sessions.
Layers 3 and 4 are what most teams are missing. Structural memory is the faster one to add: one command, no schema design, no data ingestion pipeline. It already knows the code. For the layer this replaces in a live session, see the Claude Code context loop; for what it saves once accurate structure is in place before the first tool call, see the token economics of a coding agent.
FAQ
What are the different types of memory in an AI coding agent?
Coding agent memory has four layers: in-context memory (what is currently in the active window, reset at session end), session memory (what persists across turns within one session, surviving compaction), long-term memory (decisions, preferences, and history persisted across sessions via a knowledge graph), and structural memory (a deterministic dependency graph of the codebase built by parsing the code, not derived from agent experience). Most agents only have the first layer by default.
What is the difference between in-context memory and long-term memory in an AI agent?
In-context memory is everything currently in the model's active window, cleared at session end and partially cleared during compaction within long sessions. Long-term memory persists across sessions, storing decisions, preferences, and interaction history in a knowledge graph that surfaces relevant prior context at the start of future sessions. Long-term memory requires a dedicated tool and is not present in a standard coding agent setup.
Why is structural memory different from other types of agent memory?
Structural memory is the only layer not derived from agent experience. In-context, session, and long-term memory all store what agents and users have said, found, or decided. Structural memory is computed from the codebase directly by a parser, producing a deterministic dependency graph that reflects what the code actually is rather than what an agent inferred about it. It does not accumulate errors from agent misreadings and returns the same result for the same commit regardless of what any prior session said about the code.
What happens when a coding agent is missing long-term and structural memory?
Without long-term memory, every session starts blank: the agent has no knowledge of prior decisions, established patterns, or team preferences. Without structural memory, the agent reasons from an incomplete or probabilistic picture of the codebase. Missing both means the agent has neither institutional knowledge nor an accurate structural map, which is the most common configuration in production today.
enola is open source under Apache 2.0 — free, local, no data leaves your machine.
curl -fsSL https://raw.githubusercontent.com/enola-labs/enola/main/install.sh | sh