The Claude Code context loop.

The loop, as Anthropic documents it

Claude Code runs an agentic loop: gather context, take action, verify, repeat — looping and course-correcting until the task is done. The model decides what each step needs based on what it learned from the previous one. A question about the codebase might only need the gather-context phase, and a refactor cycles through all three repeatedly.

Five categories of built-in tools power this:

For a typical request — "fix the failing tests" — Claude runs the suite, reads the failure, searches for relevant files, reads those files, edits, and re-runs. Two of those six steps are pure context-gathering, done with Search and File operations: grep for something, read what comes back, repeat until the picture is clear enough to act on.

That's the phase this post is about.

What "gather context" actually produces

Search and Read are general-purpose tools. They don't know your architecture going in. They discover it, one grep and one file read at a time, for every task, in every session. What that discovery produces isn't a computation over the codebase — it's a sample of it, with Claude filling in the rest by pattern-matching on what the sample looked like.

That's a fundamentally different kind of answer from a deterministic architectural model, which guarantees accuracy and avoids hallucinations.

Claude Code, by design, uses general primitives like Search and File operations — correctly scoped as general primitives, not as a dependency-graph engine. The consequence is that a question like "what does this module transitively depend on" gets a different answer depending on which files got sampled and in what order, because the underlying process is approximate retrieval, not exhaustive computation. Ask it twice, in two different sessions, and there's no guarantee the two answers match. Not because the code changed, but because nothing about the discovery process was fixed to begin with.

Why the picture doesn't hold steady

Three mechanics make context-gathering approximate within and across sessions.

Compaction clears older tool output first

As context fills, Claude Code compacts automatically: it clears older tool outputs before summarising the conversation. Anthropic's own docs note that detailed instructions and outputs from early in a conversation can get lost this way. The grep results and file reads an agent used twenty turns ago to build its mental model of your codebase fall into that category. The architectural understanding built earlier in a long session can disappear just when it's needed later, without the agent realising it's now reasoning from missing context instead of what it actually learned.

Sessions start with a fresh context window

Each new session has no conversation history from previous sessions. The approximation an agent built last time you used Claude Code on this repo is gone, and the next session builds a new approximation, with no guarantee it will reach the same answer. CLAUDE.md persists your written instructions and conventions; auto memory persists some learnings. Neither persists a dependency graph. There's no built-in mechanism for "remember what depends on what in this codebase" — only "remember what I told you" and "remember what you noticed."

Subagents start clean

Subagents get their own fresh context, isolated from the main conversation, returning only a summary when done. That isolation is useful for long sessions, but it means a subagent delegated to "investigate the auth module" builds its own independent approximation, which may not match its parent's conclusion.

In short: the one phase of the loop with no fixed procedure is also the one the loop's own memory model is structurally inclined to discard and rebuild differently each time.

Code intelligence gets you one hop. Most real questions need more.

The Code intelligence category — jump to definition, find references, see type errors — is the built-in tool that most closely matches what a dependency graph does. It's also the clearest place to be precise about the difference: code intelligence answers "where is this defined?" and "what directly references this?" one hop at a time.

It doesn't answer "if I change this, what's the full transitive blast radius, grouped by hop distance, including callers that only ever invoke a method without naming the type directly?" That's a multi-hop, whole-graph question. Code intelligence wasn't built to answer it, and grep can't either. Grep finds string matches, not semantic dependency edges, so it undercounts in the same way a one-hop tool does — just with more noise.

Where a graph MCP server changes the shape of the loop

Enola runs as an MCP server, which puts it in the same extension layer as any other connected service Claude Code can call. Once it's running, the loop changes in five concrete ways.

The gather-context phase stops being approximate

Instead of search → read → search → read building up an approximation, Claude Code calls explore or impact_analysis against a graph computed deterministically from a real parser. The same answer every time, against the same commit, instead of a result that depends on which files got sampled this time.

The answer survives compaction better because it's already compact

A query_facts or impact_analysis response is a structured, bounded payload — not numerous raw file contents accumulated over a dozen tool calls. There's simply less of it for compaction to need to clear, and what's left isn't a partial sample missing an unknown chunk of the picture.

The graph persists across session boundaries

Enola's snapshot lives in .enola/ on disk, incremental and re-readable any time. It doesn't depend on conversation memory at all. Pair it with a line in CLAUDE.md:

For architecture, dependency, or impact questions, use the Enola MCP tools.
(explore, impact_analysis, find_path) instead of searching the codebase manually.

Every fresh session now starts with access to the same structural facts, computed once and deterministically.

Subagents stop building conflicting approximations

Give a subagent the same MCP connection, and it queries the same graph its parent does — the same facts, not an assumption that may or may not agree with the first.

Plan mode gets a faster research phase

Claude Code's own guidance recommends separating research from coding: explore the codebase first, then implement. explore and impact_analysis are built for exactly that research step, finishing it in tool calls instead of file-by-file reading.

FAQ

What are the phases of Claude Code's agentic loop?

Claude Code's documented agentic loop has three phases: gather context, take action, and verify results, which repeat and blend together until a task is complete. A simple question might only require gathering context; a refactor can cycle through all three phases repeatedly, with Claude deciding what each step needs based on what it learned from the previous one.

What happens when Claude Code's context window fills up?

Claude Code compacts automatically: it clears older tool outputs first, then summarises the conversation if more space is needed. Anthropic's own docs note that detailed instructions from early in a session can get lost this way. Search results and file reads used to build up an understanding of a codebase's structure fall into that same category of early tool output — candidates for removal — while the user's original requests and key code snippets are prioritised for retention.

Does Claude Code remember a codebase's architecture between sessions?

Not by default. Each new Claude Code session starts with a fresh context window and no conversation history from prior sessions. CLAUDE.md persists written instructions and conventions, and auto memory persists some learnings, but neither stores a dependency graph of the codebase. That has to be rediscovered through search and file reads each session unless an external tool maintains it.

Is gathering context by searching and reading files a deterministic process?

No. Search-based context gathering produces an approximation based on which files were sampled and in what order, with Claude filling gaps by pattern-matching once it runs out of files to check. Asking the same architectural question in two different Claude Code sessions does not guarantee the same answer, even when the codebase hasn't changed, because the discovery process itself isn't a fixed computation. An architectural graph built by parsing the code, rather than sampling it through search, returns the same result every time it's queried against the same commit.

What's the difference between Claude Code's code intelligence tools and a dependency graph MCP server?

Claude Code's built-in code intelligence tools (jump to definition, find references) answer one-hop questions about a single symbol and require a code intelligence plugin. A dependency graph MCP server like Enola answers multi-hop, whole-codebase questions — such as the full transitive blast radius of changing a module grouped by hop distance — which neither code intelligence nor grep-based search is built to compute.

curl -fsSL https://raw.githubusercontent.com/enola-labs/enola/main/install.sh | sh