The context layer

A context layer sits between your codebase and your AI agent and decides what the agent gets to see for the question in front of it. The agent supplies the reasoning. The context layer supplies the facts, and, just as important, chooses which facts. That choosing is the whole job, and it is the job Koragraph exists to do.

The problem this sits on top of

To see why a context layer is needed at all, you have to start with a hard limit of how these models work. An AI model does not read your entire codebase when it answers a question. It can only take in a fixed amount of text at once, a working space called the context window. Everything the model considers, your question, the code it looks at, its own developing answer, has to fit inside that window. It is generous, but it is finite, and a real codebase is many times larger than it. You cannot pour the whole thing in. Something has to decide which fraction of the code goes into that limited space for each question.

This is the quiet crux of working with an AI agent on real software. The model’s reasoning may be excellent, but it can only reason about what is in front of it. Put the wrong code in the window and even perfect reasoning produces a wrong answer, because it was reasoning about the wrong thing. Put the right code in the window and an ordinary question becomes easy. The quality of the answer is decided, to a degree people consistently underestimate, before the model reasons at all, by what was selected to show it.

What an agent is, and what it lacks on its own

An agent is an AI model set up to work in steps rather than in a single reply: it can look something up, read the result, decide what to do next, make a change, check the outcome, and go again. This loop is what people mean by agentic coding, and it is genuinely capable. The model can plan, write code, and reason through a problem in a way that feels like real help.

But an agent by itself starts every request knowing nothing about your particular codebase. It holds broad knowledge of programming in general and nothing specific about the system you are actually working in, because that system was never part of what it learned. So on its own, an agent has to rediscover your codebase from scratch every time you ask it something. It opens files to see what is there, reads them to guess how they relate, opens more based on those guesses, and gradually assembles a picture, spending much of its limited window and much of your time reconstructing what the code is before it can even begin on what you asked. And the next request, it starts over, because it kept nothing.

This is the gap a context layer fills. The agent brings reasoning it already has. What it does not have is a fast, reliable way to know which parts of your specific codebase bear on the question at hand. Supply that, and the agent stops rediscovering the code and starts working on the problem.

The agent supplies the reasoning. The context layer supplies the facts and chooses which facts. Without one, an agent rediscovers your codebase from scratch on every single request.

What a context layer is

A context layer is exactly what its name says: a layer that sits between the codebase and the agent, and whose one responsibility is to answer the question, for this request, what should the agent see. It is the thing that turns a codebase far too large for the window into a small, correct selection that fits inside it. When the agent needs to understand a function before changing it, the context layer is what decides that the agent should see that function, the things that call it, the things it calls, and the type it depends on, rather than a thousand other files that have nothing to do with it.

The reason this deserves to be called a layer, a standing part of the system rather than a one-off trick, is that the selection problem is constant. Every question needs it. Every agent needs it. It is not a feature bolted onto the side of coding with AI. It is the piece that makes coding with AI on a real codebase work at all, and once you see it named, you notice that some form of it is always present. The only question is whether it is deliberate and good, or accidental and poor.

Selection is only as good as what it selects against

Here is the heart of it. A context layer chooses what the agent sees, so everything comes down to how it makes that choice, and that depends entirely on what it understands about the code.

There are, as covered elsewhere in this hub, three broad ways to find code, and they select very differently. You can select by matching text, which finds files where the words look promising. You can select by similarity, which finds files that seem to be about the right idea. Or you can select against a graph, a resolved map of how the code actually connects, which finds the files that are genuinely related to the one in question by real calls, imports, and dependencies. The first two select by resemblance. Only the third selects by connection, and connection is what a question about code almost always turns on.

This is the difference between filling the window with the files whose names looked promising and filling it with the resolved subgraph the question actually needs. When the selection is made against a graph that knows how the code connects, the agent receives the function it asked about together with its true callers, its true dependencies, and the pieces that would be affected by changing it. Nothing was chosen because it read similarly or shared a word. Every piece was chosen because a real edge ties it to the matter at hand. The window is the same size either way. What differs is whether the fraction that made it in is the right fraction.

Why this is the job Koragraph does

Koragraph is a context layer built on exactly this principle. It is a local MCP server that gives an AI coding agent a persistent, offline, multi-repository code knowledge graph to select against. It parses your repositories, resolves the real edges between the pieces, calls, imports, inheritance, and the connections that run across service boundaries, and keeps the result in a local database that persists across sessions. When the agent has a question, the context layer can answer it from that resolved structure instead of from guesses about which files look relevant.

It reaches the agent through the Model Context Protocol, the open standard introduced by Anthropic in November 2024 that lets any AI model reach external tools and data through one common interface. Because Koragraph speaks that standard, it can serve as the context layer for Claude Code, Cursor, Codex, and other MCP clients without being tied to any one of them. It exposes its abilities as a small set of tools the agent can call. explore and neighbours walk out from a starting point to its real connections. blast_radius answers what would be affected by a change. search_code and file_symbols find and list the code’s declared pieces. changes_with surfaces what tends to change alongside a given file. overview gives the shape of the whole. And recall and remember let facts worth keeping carry from one session to the next. Each of these is a way for the agent to ask the context layer a precise question and get back a precise, connected answer rather than a pile of files to sift.

Because all of this runs on the developer’s machine with no cloud dependency and no large language model of its own, no source code leaves the machine to make this selection happen. The context layer does its choosing locally, against a graph it built locally, and hands the agent the result. The privacy is not an add on. It falls out of the design.

Grounding, and why the right context is not a nicety

There is a failure that everyone who has used these models has seen: the model states something with complete confidence that is simply not true. It invents a function that does not exist, calls a real function with arguments it never takes, or assumes a connection between two parts of the code that is not there. This is often called hallucination, and it is not the model being careless. It is the model doing what it does, predicting plausible text, in the absence of the facts that would have constrained it to the truth.

The cure for it is grounding: giving the model the actual facts so that its answer is tied to what is real rather than to what is merely plausible. And grounding is precisely what a context layer provides. When the agent can see the real function, with its real signature, and the real code around it that actually connects to it, it has far less room to invent, because the truth is right there in the window, selected for it. A context layer built on a resolved graph is a grounding machine. It does not make the model more truthful by lecturing it. It makes the model more truthful by putting the relevant facts in front of it and leaving less to guess.

A model hallucinates when it has to guess. A context layer built on a resolved graph leaves less to guess, because the facts the question turns on are already in the window.

The whole picture, in one view

Every idea in this hub can now be seen from one vantage point, because the context layer is where they meet. The context window is the fixed space the layer is selecting to fill. The agent is the reasoner the layer serves, freed from rediscovering the code on every request. Grep and embeddings and the graph are three ways the layer could make its selection, of which only the graph selects by real connection. GraphRAG for code is the name for exactly this arrangement, using a graph to choose what the model reads. Blast radius is one of the sharpest questions the layer can answer, because it is a pure walk over the graph’s edges. And grounding is the effect the whole thing produces, an agent whose answers are tied to what is actually there.

Read that list again and notice the shape of it. These are not separate topics that happen to share a website. They are the parts of one machine. The window sets the constraint. The graph provides the structure. The layer does the selecting. The agent does the reasoning. Grounding is the payoff, and hallucination is what happens when the layer is missing or does its job against resemblance instead of connection. The context layer is the piece that holds all of these in their right relation, which is why it is the idea the rest of the hub was building toward.

Where this leaves you

The plain summary is this. An AI agent is a strong reasoner with no built in knowledge of your particular code and only a small window to look through. Left alone, it rediscovers your codebase from scratch on every request and guesses when it cannot see enough. A context layer changes that by standing between the codebase and the agent and deciding, for each question, which pieces of the code the agent should see. Do that selection against a resolved graph that knows how the code truly connects, and the fraction that reaches the window is the fraction the question needs, so the agent reasons about the right thing and invents far less. That is what Koragraph is, and it is why every other idea in this hub, the window, the graph, grounding, blast radius, the difference between finding by text and by meaning and by connection, was worth understanding first. They were all pieces of this one.