Context Engine manifesto
The interface between coding agents and codebases is broken.
Files are a storage format. Code is a graph. Giving agents better text tools does not close that gap.
Imagine being given a whiteboard and a large stack of paper with a project's source code printed on it, then being asked to implement a feature or fix a bug. You know little about the project. You have worked with some of its dependencies before, but the project uses newer versions. I doubt you would be very productive. Yet this is exactly how we ask AI coding agents to work.
You can add an index listing every word used on every page, but it will not make your job much easier; it will mostly make the stack taller. You can add more stacks containing the documentation for the project's dependencies, but there is no guarantee that it is complete or current. None of this will make you much more productive, because the problem is not the amount of paper. The problem is that paper is the wrong format for working with a codebase.
We fill an agent's context with raw text from files. Files are the storage format, but the codebase an agent needs to understand is a directed graph of symbols. Those symbols have structure, identities, and boundaries that are not defined by arbitrary line ranges. They have relationships to other symbols and contracts that are often defined in other files. All this information is encoded in the text, but only implicitly, so the agent has to reconstruct it. Dependency symbols are not external to this graph. They are an integral part of the codebase the agent must reason about, and the contracts of the exact versions in use matter.
Better tools cannot fix a broken interface. As long as they still operate on raw text, the problem is unfixable. We have to fix the interface itself.
Luckily, the legacy coding era left us deterministic tools built to work with code: language servers and Tree-sitter. Language servers resolve symbol identities, definitions, references, types, and APIs. Tree-sitter recovers the syntax and structure of code across many languages.
But these tools were designed as backends for IDE features used by humans. Simply exposing their native operations and output to an agent does not fix the interface. It can give the agent more tools to choose from, more output to process, and more decisions unrelated to the actual task. We should keep the underlying machinery, but redesign the interface above it for a different user: the coding agent. That interface should be organized around coding workflows, not around the tools that implement them.
That is why I built Context Engine. It was built from day one as a language-agnostic interface between agents and codebases, and it avoids language-specific heuristics almost completely. The only exceptions are JS/TS callbacks passed as function arguments and React hooks — hello ;)
It allows agents to navigate the semantic graph of even a huge codebase and selectively fetch the parts of symbols they need for the task, keeping the redundant noise out of context. It makes symbol contracts visible instead of forcing agents to spend their reasoning budget inferring them. Here are the workflows we have built Context Engine around.
Codebase Exploration
Filling an agent's context with the entire contents of a file when it only needs the API defined there is sheer barbarism. This is not just about wasting tokens. It is context pollution, and context pollution degrades reasoning performance.
Why include module-level and symbol documentation when it is unrelated to the question the agent is answering? Why make the agent read fat function bodies full of implementation details when it only needs a signature and annotations/decorators?
Context Engine's outlinetool is built for exactly this workflow. Given a file, it returns data structures with their fields, interfaces, signatures, and the symbol hierarchy, while providing an interface for selectively fetching any hidden detail the agent needs. It strips away redundant information and provides a complete, pollution-free view of the file's structural API. Any hidden detail the agent needs remains selectively accessible through the returned handles.
Handles are another part of the interface. They identify symbols structurally rather than by their current file positions. Add several lines of comments above a symbol and its line number changes, but the symbol itself does not. Its handle remains valid.
An agent can pass that handle to extract to fetch selected parts of the symbol or to show_usage to find its usages without calling outlineagain. Handles survive body edits, comment changes, reformatting, line shifts, and moves that preserve the symbol hierarchy. A handle is invalidated only when the symbol's signature or hierarchy changes.
This means agents can continue using outline results throughout an editing session instead of rebuilding their view of the file after every change.
Finally, agents need an easy-to-use way to explore dependency APIs. Documentation is not the source of truth: it can be incomplete or outdated. The source code of the version your project actually uses is.
Instead of guessing an API or relying on training data, an agent can use jump on any symbol visible in the code and choose the view it needs — either the full implementation or the API only. Whether the symbol is defined in another package of a huge monorepo or in an external dependency, jump follows the codebase graph and returns exactly the requested information.
It does not matter whether the model was trained on the exact dependency version pinned by your project. The answer is one tool call away in the dependency's source code.
Debugging
I use debugging here as shorthand for any task that requires an agent to explore implementation details rather than just inspect an API.
These tasks usually begin in one of two places: with a symbol name — or a guess at one — without knowing where it is defined, or with a file and line number from a failing test, error, or linter warning.
For the first case, Context Engine provides grep_definition. It searches symbol definitions by exact name or glob. An agent can, for example, find all data structures and functions matching *config*, while narrowing the search by symbol kind and setting the results limit. When the workflow starts with a known file and line, line_context finds the smallest complete symbol containing that line and shows its hierarchy.
In both cases, the agent gets semantic context instead of false-positive text matches or an arbitrary window of nearby lines. grep_definition returns the APIs of the matching symbols together with handles. The agent can pass a handle to extract to read the full definition or to show_usage to see where and how the symbol is used.
line_context returns the full implementation of the symbol containing the line. The agent does not have to guess how many lines to read — a range that is too wide pollutes its context, while one that is too narrow leads to repeated reads of the same code.
As you may have noticed in the first animation, Context Engine tools that show complete implementations — including extract, line_context, jump in implementation mode, and several others you have not heard about yet — can augment the source with inlay hints. These show resolved types and parameter names at function call sites.
type_annotated is the default view because agents read code far more often than they edit it. When an agent needs the exact source, tools that support source-output modes can return plain_text or both. The both mode provides the annotated code for reasoning and the original source for editing.
Seeing resolved contracts makes mistakes caused by guessed types and APIs less likely. It also leaves more of the agent's reasoning budget for the task itself.
The jump and show_usage tools introduced in the Codebase Exploration section are a perfect fit for debugging too. Starting with a line from a failing test, an agent can call line_context, jump to the function under test, and then jump again to a function called from its body, where the bug may be hiding. That takes exactly three tool calls, regardless of the size of the codebase or where those symbols are defined.
The agent does not pollute its context with unrelated symbols from the same files, guess where definitions might be, or consume false positives from grep results. And show_usage shines when the agent needs to see the exact blast radius before refactoring a symbol.
Consequences of Fixing the Interface
Fixing the interface has several consequences. Token savings are one of them, but they are not the product category.
First, the size of the codebase becomes much less important. The amount of context an agent consumes can follow the path it takes through the codebase graph instead of the total amount of source around that path. It can navigate between symbols across a huge monorepo, its packages, and external dependencies without loading every file it passes through. This matters especially for enterprises — and for agentic companies trying to serve them.
Second, the agent's context remains useful for longer. Every unrelated function body, irrelevant documentation block, and false-positive search result occupies space that could have been used for the task. Keeping that noise out leaves more room for reasoning, delays compaction, and allows the agent to complete more work — and potentially more tasks — within the same session.
There is also the direct token saving. Context Engine lets the agent fetch a file's API without its implementations, one symbol without the rest of the file, documentation without code, code without documentation, or the exact source of a dependency symbol. It does not load a large block and summarize it afterward. It avoids loading the irrelevant code in the first place.
Resolved contracts save tokens further downstream. When the agent can see types, parameter names, exact dependency APIs, and real usages, it has less to guess. Fewer guesses mean fewer incorrect edits and fewer write-test-rewrite loops.
These benefits recur every time an agent has to acquire the codebase again: at the beginning of a session, after context compaction, when a subagent starts, or when several agents work in parallel. Context Engine makes that reacquisition cheaper because the codebase is available as a compact structural map with exact evidence behind it.
These are not separate optimizations. They are consequences of giving agents an interface to code instead of files. Context Engine is the semantic layer that provides that interface. Token savings are simply one visible result of fixing it.
Postscript
I built Context Engine in 2025 and had it working as an MCP server by December. A public release still required a website, installers, license validation, and the rest of the release infrastructure.
In January 2026, I switched my attention to my current deep-tech project: a math-to-silicon synthesis engine. I used Context Engine as an internal tool on that project until July, when I returned to finish Context Engine for a public release. Both projects are written in Rust. During those six months, I rarely saw agents struggle with the borrow checker or lifetimes, and I did not see them hallucinate a dependency API even once. That experience convinced me to finish the remaining work and release Context Engine as a free Community Preview.
Context Engine has been language-agnostic from day one. It bundles 324 Tree-sitter grammars — the complete set supported by Neovim — and needs only a configured language server to add project-resolved semantic information. I have personally validated it with Rust, Python, Go, TypeScript, and Markdown. Support for the other bundled languages should still be considered experimental.
The MCP server is a thin wrapper around an embeddable Rust core, with C/C++ used only by the compiled Tree-sitter grammars. If you are building agentic tooling and are interested in integrating Context Engine directly through its Rust API, email me at integrations@context-engine.app. Context Engine is already fast through MCP, while direct integration removes the protocol layer entirely.
Context Engine will remain free throughout the Community Preview while I decide what comes next. You can get a free API key and try it on a codebase you know well. I would be glad to hear what works, what does not, and where it breaks in the Context Engine MCP repository.