The engine that gives our agents the whole repository
Our code-intelligence engine maps syntax and usage, ranks context around a change, and blends exact with semantic retrieval.
- IndustryDeveloper tooling
- EngagementInternal engine, built for our own agents
- StatusIn use on our own work, still being extended
Built for our own agents first
This is not a client project. It is the part of our own toolchain that decides what an agent gets to see before it touches anything. It indexes a project once, keeps that index current as files are saved, and answers structural questions about the code: what is defined where, what uses it, what a file pulls in and what pulls the file in.
The constraint that shaped everything is the reasoning budget. An answer that is technically complete but too large to read is worse than a smaller answer that fits, so every response is trimmed to a fixed budget while staying valid structured output, and a file comes back as its signatures with the bodies left out. The point is to reserve the budget for the work.
The problem was ours
No client asked for this. It came out of watching our own agents work on large codebases with the wrong picture of them.
An open file is not a codebase
An agent asked to change a function could see the function and the file around it. What called it, what it called in turn, and which parts of the project would notice the change all sat outside the frame. The change was reasoned about in isolation, and reviewed the same way.
Reading a whole project to find one thing
Without a map, finding the right place means opening files and discarding them. Every discarded file has already been paid for out of the same budget the actual work needs, and on a large repository that cost arrives before any useful thinking starts.
One kind of search was never enough
An exact name search misses code that does the same job under a different name. A meaning based search misses the exact identifier someone just typed. Choosing one of them made the tool wrong in a different way each time.
What we built
An index that understands structure, a retrieval layer that blends three ways of looking, and hard limits on what any single answer is allowed to cost.
A structural map of what is declared where
The engine parses source into syntax trees and pulls out what is declared in each file, so a project can be described by its shape.
- Functions, classes, methods, interfaces, types, enums, structs, traits and implementations are extracted across ten languages
- A file can be returned as its signatures alone, without bodies, so an agent sees the shape of a file it has not read
- A project map carries the language, line count and symbol count of every file, and collapses to the top level when a tree is too large to be useful
Three ways of looking, merged into one ranking
Keyword search, literal name matching and semantic similarity each answer a different kind of question, so the engine runs all three over one index and fuses their results into a single ranking.
- Full text keyword search, substring name matching and vector similarity run together on every query
- The three rankings are combined with reciprocal rank fusion, which compares positions in each list, so three incomparable sets of scores need no hand tuned weights
- How widely a symbol is referenced across the project nudges the ranking, so load bearing code surfaces ahead of code nothing calls
What depends on this, not only where it lives
Alongside definitions, the engine records where names are used, both calls and type references, and which files import which. That turns a lookup into a question about consequences.
- A usage graph answers what depends on this beside where this is defined
- Imports run in both directions: what a file pulls in, and, approximately, which files across the project pull it in
- A window of recent history sits next to the map, so what changed lately comes back with the answer
Bounded answers, on the machine the code is already on
Two rules shaped the delivery side. An answer has to fit the space the caller has for it, and none of the code should have to leave the machine to be understood.
- Every response is trimmed to fit a fixed budget while staying valid structured output, so a broad query cannot flood the caller's context
- The whole index is a single database file on the developer's own machine, with vector search running in process, and no code is uploaded anywhere
- A save is picked up by a file watcher and re-indexed within half a second, while a file whose content has not changed is recognised by hash and skipped
What changed in our work
This is an internal tool, so the honest report is what it changed about the way we work. There is no benchmark behind it and we do not publish one.
Whole repository
What a review starts from
A review or a refactor begins with the shape of the project: what the change touches, what uses it, and what pulls it in. The open file stopped being the boundary of what could be reasoned about.
Budget on the work
Where the reasoning goes
Signatures instead of bodies, and answers trimmed to fit, mean less of the available context is spent opening files that turn out not to matter. The gain is in what never has to be read.
Stays on the machine
Why we can point it at client code
One index file on the developer's own machine, with search running in process. Credential files, private keys and certificate material are excluded from indexing, and the index is readable only by its owner.
Do your tools see your codebase, or just the file that is open?
Tell us how your team works with a large repository today and where the context runs out. We will tell you what is worth building and what is not.
Discuss your project