Context, compared

Nine ways teams give coding agents context, scored against what independent research says a solution has to do. Only one shape passes.

August 3, 2026 12 min read

Every team that ships with AI coding agents hits the same question: how do I give this thing the context it keeps missing? The honest answer is that most of the popular ways to do it are solving a different problem. They are good at getting the agent to see your code, your docs, your tickets. Almost none of them are built for the thing that actually goes wrong, which is the agent making a product decision, the rate limit, the identity model, the constraint a contract set, without the one fact that should have governed it.

So rather than argue for any tool, let us build a yardstick first, from independent research, and then run every common method through it. If the yardstick is neutral, the winner is not a matter of opinion.

First, what a solution has to do (from the research, not from us)

Five requirements fall out of published work across a few fields. None of them come from a vendor.

It has to select by decision-relevance, not by similarity or recency. In 2023 Liu and colleagues, in the paper "Lost in the Middle," showed that language models use information reliably at the beginning and end of a long context and much less reliably in the middle. Stuffing everything in, or ranking context by surface similarity, does not guarantee the one binding fact lands where the model will actually use it. Selection has to be about which decision governs the choice, not which text looks nearest. This is the point of an earlier piece here, that relevance, not window size, is the real bottleneck.

It has to carry the why, not just the what. Michael Polanyi's work on tacit knowledge, and Nonaka's after it, established that a recorded value loses the reasoning that produced it. A limit of forty a minute sitting in a file does not tell the agent when forty is wrong. The decision and its rationale have to travel together, which is a property documentation structurally loses.

It has to be captured at the fork, when the decision is made. Barry Boehm's software economics established a principle, argued over in its exact multipliers but not in its direction, that the cost of fixing a decision rises the later you catch it. Context supplied after the code already exists is on the expensive side of that curve, which is why a day-one guess compounds into a foundation.

It has to stay true as decisions change. Products change their minds. A snapshot goes stale, and research on both catastrophic forgetting in models and drift in retrieval indexes points the same way: whatever holds the context has to be updated deliberately, not frozen at training or ingestion time.

It has to be governed, exposing the least context needed, not the raw firehose. Wiring an agent straight into everything is itself the security problem, not the solution, which is the argument of the firehose problem. The right context has to be selectable down to least privilege.

Five requirements, none of them ours. Now the methods.

The comparison

Five families, one clean split. Here is why each family lands where it does, and, since this only works if it is fair, what each one is genuinely the right tool for.

Static injection: rules files

A CLAUDE.md, an AGENTS.md, a .cursorrules file. Mechanically, the file is pasted verbatim into the system prompt on every turn, inside a fixed token budget, with no selection. That is its strength for a narrow job: stable, always-on instructions like code style and a few hard rules. It is genuinely the right place for "use tabs, never edit generated files."

It fails the moment the file has to hold decisions. There is no selection, so everything competes for the same budget and the binding fact sits wherever it happens to sit, which "Lost in the Middle" says is often exactly where the model will underuse it. It carries the what and not the why, it is updated by hand so it goes stale, and it is all-or-nothing on exposure. A growing rules file is a junk drawer, which is why the honest move is to graduate off it.

Retrieval: RAG, code indexing, GraphRAG

Retrieval is the serious answer, and for the job it was built for, finding the most relevant passage or symbol in a large corpus, it is excellent. RAG chunks your documents, embeds them, and returns the top matches by vector similarity. Codebase indexing does the same over your repository with symbol and syntax awareness. GraphRAG adds an entity graph so retrieval can follow relationships instead of raw similarity.

They all fail the same way on decisions, and it is structural, not a tuning problem. Retrieval ranks by similarity, and the decision that should govern a choice is frequently not the most similar text to the code being written. The clause in a contract that sets your real rate limit does not look like the rate-limiting code, so similarity search does not surface it at the fork. Retrieval also returns passages, not decisions with rationale, and it is only as current as its last re-index. GraphRAG narrows the gap by encoding relationships, but a graph of your documents is still a graph of what was written down, not of the decisions that were never recorded. Use retrieval for search. Do not mistake search for judgment.

Connection: MCP and raw integrations

The Model Context Protocol is, by Anthropic's own definition, a protocol for connecting agents to tools and data sources. Raw integrations do the same thing by hand, wiring the agent to GitHub, Slack, and Jira through their APIs. This is real and useful plumbing. MCP is the right way to give an agent a clean, standard connection to a system.

But a connection is transport, not selection, and not judgment. MCP standardizes how the agent reaches your data. It does not decide which of that data is the decision that matters, it does not carry the reasoning, and pointed at raw sources it hands over the whole firehose, which is the exposure problem rather than a fix for it. Connection is necessary. It is nowhere near sufficient. It answers "how does the agent reach the data" and leaves "which fact should govern this choice" completely untouched.

Model-level: long context, fine-tuning, memory

Three attempts to put the context inside the model or its window. A bigger context window lets you paste more in, and it is great for holding one large document or file in view at once. Fine-tuning, with LoRA or full training, bakes patterns into the weights, and it is the right tool for teaching a model your house style or output format. Agent memory systems like mem0 or Letta persist and retrieve across sessions, which genuinely helps continuity within a workstream.

None of them is a home for product decisions. A long window still does not select, and it inherits "Lost in the Middle" directly, since more tokens is more middle to get lost in. Fine-tuning freezes a snapshot into weights that cannot be updated when a decision changes next week, and it is lossy about the exact value and its reason. Memory captures what happened in the loop, ordered by recency rather than by which decision is binding, and it drifts. Each is a real tool for a real job. None of those jobs is "hold the decision that governs this fork, keep it true, and surface it at the moment of the choice."

The one shape that passes

Look back at the table. Every method fails at least one requirement, and it fails structurally, because of what the method inherently is: a file cannot select, retrieval ranks by similarity, a protocol only connects, weights cannot be updated, memory is ordered by recency. The requirements do not select a tool. They select a shape, and the shape is a purpose-built layer that holds decisions with their rationale, selects them by relevance to the choice at hand, captures them at the fork, versions them as they change, and exposes them under least privilege.

That shape is what a context layer is, and it is what Brief is built to be. Brief is a product navigator: it captures the decisions your code cannot hold, the real limit a contract requires, the real way your users are identified, the real scale you run at, keeps them versioned as they change, and puts the relevant one in front of the agent at the fork, before the guess. It is not a better file, a better retriever, or a better connector. It is the category those requirements describe.

How we can say this without waving our own numbers

We did not set out to prove Brief wins. We derived, from independent research, what any solution has to do, and then checked which shape does all of it. Every cell in the nine rival rows is a claim you can verify without trusting us: a rules file cannot select, RAG ranks by similarity, MCP is a connection protocol, weights are frozen after training. Brief's row is the one line on the table that is not a structural fact but a design goal, what a context layer is built to do, and you can check whether Brief does it by using it. The conclusion still holds either way, because it is the rivals' structural failures, not our own row, that rule them out and leave only the shape of a context layer standing.

We do have our own evidence that the conforming approach also measures better, a controlled benchmark where decision compliance rose from 46 to 95 percent once the agent had the decisions. But that number is confirmation, not the argument. The argument is the table, and the table is built from other people's research.

What this does and does not claim

A few honest limits. This is a comparison of approaches, not a claim that Brief is the only possible context layer, or that a context layer is the right tool for every context problem. It is not. For finding a passage in your docs, use RAG. For connecting an agent to a system, use MCP. For teaching a model your output format, fine-tune. Each method wins the job it was built for, and the table only judges them against one job, holding the product decisions an agent needs at a fork, which is the job none of them was built for and the one a context layer exists to do. And the benchmark figure is ours and labeled as ours; the weight of the argument rests on the independent requirements, not on it.

So before you pick a way to give your agent context, ask which problem you are actually solving. If it is search, or connection, or style, the answer is on this list already. If it is the decision the agent is about to make without you, which of these was ever built to hold it?

Frequently asked questions

What is the best way to give an AI coding agent product context? It depends on which problem you mean. For searching documents use RAG, for connecting to systems use MCP, for teaching output style use fine-tuning. For holding the product decisions an agent needs at a fork, the value and the reason behind it, kept current and surfaced at the moment of the choice, none of those were built for it; that is the job of a purpose-built context or decision layer. The requirements that separate them are selecting by decision-relevance, carrying the rationale, capturing at the fork, staying current, and governed exposure.

Is RAG enough to give a coding agent context? RAG is excellent at finding the most similar passage in a corpus, but it ranks by semantic similarity, and the decision that should govern a coding choice is frequently not the most similar text to the code being written. A contract clause that sets your real rate limit does not resemble rate-limiting code, so similarity search often will not surface it at the fork. RAG also returns passages rather than decisions with rationale, and it is only as current as its last re-index. Use it for search, not for judgment.

Does MCP solve the context problem for AI agents? Not on its own. MCP, by Anthropic's definition, is a protocol for connecting agents to tools and data sources. It standardizes transport, how the agent reaches your data, but it does not decide which data is the binding decision, does not carry the reasoning, and pointed at raw sources exposes the whole firehose. Connection is necessary and MCP is a good way to do it, but selection and judgment sit above the protocol.

Can you just use a bigger context window or fine-tuning instead? Neither holds product decisions well. A bigger window does not select, and it inherits the "Lost in the Middle" effect, where models underuse information buried in a long context, so more tokens is more middle to get lost in. Fine-tuning bakes a snapshot into weights that cannot be updated when a decision changes and is lossy about exact values and their reasons. Both are strong tools for other jobs, holding a large document in view, or teaching output style, and neither is a live, updatable home for the decisions an agent needs at a fork.

How is a context layer different from a rules file like CLAUDE.md? A rules file is injected verbatim every turn with no selection, carries instructions rather than decisions-with-rationale, is updated by hand, and is all-or-nothing on exposure. A context layer such as Brief selects the relevant decision by its bearing on the choice, carries the reason with it, versions it as it changes, and exposes it under least privilege. The rules file is the right home for a few stable instructions; it is the wrong home for the growing set of product decisions that govern real choices.