Just a year ago, when a coding agent needed to understand a project, the strategy was fairly straightforward.
Read files.
Lots of files.
The more context that fit into the model’s window, the better.
That approach worked… until it didn’t.
Repositories grew.
Context windows grew too.
But a new problem appeared.
The agent could read the code.
It didn’t necessarily understand it.
And that’s where the most interesting shift we’re seeing this year begins.
Coding agents are moving away from relying on reading thousands of files to start querying structured knowledge.
It’s not an incremental improvement.
It’s an architectural change.
The RAG Problem for Code
The first generation of tools solved the problem using RAG.
The process looked something like this:
Repository
↓
Embeddings
↓
Vector search
↓
Relevant snippets
↓
LLM
When the agent needed to know how a class worked…
…it searched for similar files and added them to the prompt.
It was a huge improvement over sending the entire repository.
But it still had limitations.
Reading Doesn’t Mean Understanding
Imagine a fairly common question.
Where is the final price of an order actually calculated?
The answer probably involves:
-
multiple files,
-
interfaces,
-
classes,
-
dependencies,
-
indirect calls,
-
distributed logic.
Traditional RAG returns “similar” files.
But it doesn’t understand that:
-
one function calls another,
-
a symbol was renamed,
-
a module belongs to another domain,
-
two classes never appear in the same file but are intimately related.
That requires a different representation.
Enter the Knowledge Graph
Instead of asking:
“What files are similar to this?”
the agent starts asking much more interesting things.
Like:
“What functions call this?”
or
“Who owns this module?”
or
“What changes broke this dependency?”
It no longer queries text.
It queries relationships.
Repository
↓
Parser
↓
Knowledge Graph
↓
Structured query
↓
LLM
And that difference completely changes the quality of the context.
We’re Already Seeing This Evolution
What’s interesting is that this doesn’t come from a single project.
Several very different repositories are converging on the same idea.
Context7
When we wrote about Context7, the proposal seemed like simply “better documents for agents”.
But it actually does something more important.
It delivers structured and versioned information.
The agent stops guessing APIs by reading old documentation.
It queries an organized source.
ctx
ctx attacks another problem.
Months of conversations with Claude Code, Cursor, Codex, or Gemini CLI are saved as transcripts.
Until now, that was dead text.
ctx normalizes them, indexes them in SQLite, and lets you query them in milliseconds.
It doesn’t load thousands of lines again.
It retrieves exactly the knowledge needed.
codebase-memory-mcp
Probably the clearest example.
It builds a persistent knowledge graph of the repository.
Functions.
Symbols.
Dependencies.
Relationships.
All exposed through MCP.
The agent no longer needs to traverse the entire project tree.
It queries the graph directly.
Repowise
Repowise takes the idea one step further.
It doesn’t just understand the code.
It also incorporates information that normally lives outside the repository.
For example:
-
ownership,
-
hotspots,
-
Git history,
-
architecture,
-
documentation.
In other words.
It starts representing organizational knowledge.
Orqenix
And then Orqenix appears.
Its main focus isn’t the graph.
It’s the runtime.
But the same pattern appears again.
Persistent memory.
Skills.
Plugins.
Learning.
All organized as reusable knowledge.
Not as giant prompts.
They’re All Solving the Same Problem
Even though they look like different tools…
…they actually answer exactly the same question.
How do we avoid reading the same repository over and over?
The answer is starting to be:
We don’t read it.
We build a better representation.
What Does the Agent Gain?
A lot.
Fewer tokens
Instead of sending twenty files…
it queries a relationship.
More speed
A structured query takes milliseconds.
Reading hundreds of thousands of tokens doesn’t.
Better precision
The relationships between symbols survive even if the code format changes.
Real memory
The agent can remember:
-
decisions,
-
patterns,
-
architecture,
-
workflows,
-
ownership,
without rediscovering them every session.
Are We Seeing the End of RAG?
Not exactly.
We’re probably seeing its evolution.
RAG is still very useful for:
-
documentation,
-
RFCs,
-
wikis,
-
tickets,
-
specifications.
But to understand a repository…
…it’s increasingly clear that a knowledge graph offers a much richer representation.
It doesn’t replace RAG.
It complements it.
And in many cases, it surpasses it.
The Next Step
I think over the next twelve months we’re going to talk much less about context windows.
And much more about:
-
runtimes,
-
memory,
-
graphs,
-
structured knowledge,
-
MCP,
-
context engines.
The question will stop being:
How many millions of tokens does this model support?
And will become:
What does it actually know about my project before it starts reading files?
That difference is enormous.
Because an intelligent agent isn’t necessarily the one that reads the most.
It’s the one that remembers best.
The Trend
If anything taught us Context7, ctx, codebase-memory-mcp, Repowise, and Orqenix, it’s that the future of coding agents probably doesn’t lie in indefinitely expanding the context window.
It lies in building better representations of knowledge.
Humans don’t solve a problem by rereading an entire repository every morning either.
We remember relationships.
We recognize patterns.
We know where to look.
Agents are starting to do exactly the same.
And I think that change is going to be much more important than the next model with ten million more tokens of context.
Because the real goal was never to read more.
It was always to understand better.