OwlPath: Ontology-Based Code Retrieval Cuts Agent Tokens 29%

Last updated: July 31, 2026

Coding agents have a retrieval problem that context windows cannot solve. A ~100K token budget means the agent only ever sees a slice of the repository, and today's retrieval treats code as plain text: substring match and embedding similarity, which miss the relations that actually matter for a bug fix.

A new paper, OwlPath (arXiv 2607.27249, submitted July 28), takes a different route. Instead of retrieving text, it encodes source code into an OWL2 ontology and answers structural queries with SPARQL property paths. The result: multi-hop relations like subclass chains, transitive callers, and interface implementations are fetched in a single query, with the paper reporting 2.06x recall on offline retrieval and a 28.8% reduction in tokens consumed on SWE-bench Pro instances.

What OwlPath actually is#

OwlPath is a retrieval layer, not a new model. It sits on top of CodeGraph, an open-source code intelligence platform, and exposes a unified CLI for structural code retrieval. It parses repositories with tree-sitter, so it covers Python, JavaScript, TypeScript, Go, and other languages, then encodes language-specific semantics into one unified OWL2 ontology.

Two complementary modules do the work:

• A transitive-closure engine. It resolves all structurally linked symbols through single SPARQL property-path queries. Where string matching and embeddings find symbols by name or text similarity, property paths traverse the actual graph: if B extends A and C calls B, one query returns the whole chain. The paper reports 69-80% accuracy on transitive-caller and interface-implementation tasks on a 37-question structural benchmark, where keyword retrieval landed at 4.4% recall.

• The OWL Software Knowledge Map (OWL-SKM). A precomputed, compact ~3KB summary holding module trees, core APIs, and issue-related symbols. It is designed to point the agent at the right modules on the first query, before any expensive search, so the agent spends its context budget on code instead of on navigation.

The numbers, attributed to the paper#

The agent evaluation is small and should be read as such: over 18 matched SWE-bench Pro instances, the paper reports a 68.4% strict-apply rate for OwlPath versus 66.7% for the CodeGraph baseline, cutting token usage by 28.8% and runtime by 39.5%. A 1.7 percentage point gain on tiny sample sizes is suggestive, not definitive.

The retrieval evaluations are the stronger signal. Over 67 offline instances, recall improves 2.06x (0.464 versus 0.226) and hit rate reaches 88.1% compared to 59.7% for CodeGraph. On the structural benchmark, recall climbs from 4.4% to 28.8%. The pattern is consistent: when the question is "what code is structurally connected to this symbol", an actual graph beats text similarity by a wide margin.

Why it matters#

It is a context-engineering play, and that lane is hot. Yesterday's ablation study on context files (Do Context Files Help Coding Agents?) found that what you feed an agent matters more than raw tokens. OwlPath is the same thesis applied to retrieval mechanics: cut the noise by resolving structure explicitly, and the agent's 100K budget goes further. That is also the bet behind Codenib's repository context and the context-reduction patterns we have catalogued - only OwlPath achieves it with a query planner rather than a summarizer.

Graph retrieval complements embeddings; it does not replace them. Embedding search answers "what text is similar to this". Property paths answer "what is structurally connected to this". A bug that lives in an interface implementation reached through a transitive caller is invisible to the first question and trivial for the second. The interesting production pattern is a hybrid: embeddings for recall, ontology queries for the structural hops, and the 3KB SKM as a cheap routing header. That is exactly the architecture we described for codebase knowledge graphs - this paper is the first concrete evaluation of the query side of it.

The retrieval gains are where the economics live. On the paper's numbers, the 28.8% token cut and 39.5% runtime cut on agent runs are bigger than the accuracy delta. For teams paying per token on long agent tasks, retrieval that resolves a dependency chain in one query instead of five turns is a cost optimization, not just a quality one. It pairs with the cost economics of agentic coding: the cheapest tokens are the ones never generated because the right file arrived first.

My take#

Three things stand out.

First, the honesty of the evaluation matters. An 18-instance agent eval with a 1.7pp delta would normally be a footnote, and the paper's own retrieval numbers are what make the claim credible. The lesson for anyone building agent tooling: measure retrieval separately from end-to-end agent success, because the first is where you learn what works. That is the same discipline we pushed after SWE-NFI and the baseline-receipts argument: an eval that cannot localize the failure tells you nothing.

Second, expect ontology-style retrieval to appear inside agent frameworks quietly. It is not a consumer feature; it is plumbing. But the "3KB summary to route the first query" pattern is directly portable - any team can precompute a module map and hand it to the agent as a routing document before the first search, and today's context-file formats are the natural carrier.

Third, this is another data point that the binding constraint on coding agents is no longer the model. It is the repository access layer. Same-batch papers today cover context files, non-functional improvement quality, and now structural retrieval - all attacking the same gap from different sides. If you are building on top of coding agents, that is the layer worth owning.

The one-line summary: give the agent a graph, not a pile of text, and both its accuracy and its bill improve.

FAQ#

What is OwlPath?#

OwlPath (arXiv 2607.27249) is a retrieval layer for coding agents, not a new model. It sits on top of the open-source CodeGraph platform, parses repositories with tree-sitter, encodes the code into a unified OWL2 ontology, and answers structural queries such as subclass chains, transitive callers and interface implementations with SPARQL property paths.

How much does OwlPath improve retrieval and token usage?#

Over 67 offline instances, recall improves 2.06x (0.464 versus 0.226) and hit rate reaches 88.1% versus 59.7% for CodeGraph. On 18 matched SWE-bench Pro instances, the paper reports a 68.4% strict-apply rate versus 66.7%, with 28.8% fewer tokens and 39.5% less runtime. The agent sample is small, so the accuracy delta is suggestive, not definitive.

What is the OWL Software Knowledge Map?#

The OWL-SKM is a precomputed, compact summary of about 3KB holding module trees, core APIs and issue-related symbols. It points the agent at the right modules on its first query, so more of the context budget goes to code instead of navigation.

Does ontology-based retrieval replace embedding search?#

No. Embedding search answers what text is similar, while property paths answer what is structurally connected. The post argues the useful production pattern is a hybrid: embeddings for recall, ontology queries for structural hops, and the small knowledge map as a cheap routing header.

Continue Reading#

• Do Context Files Help Coding Agents?
• Codebase Knowledge Graphs for AI Coding Agents
• Codenib: Repository Context for Coding Agents
• Agent Context Reduction Patterns
• SWE-NFI: The Benchmark That Catches What Coding Agents Miss

Sources#

• OwlPath: Lossless Knowledge Compression for LLM Bug Repair - arXiv