Why semantic call graph queries outperform traditional agent search.

The hidden cost of how agents navigate code

Before an AI coding agent can complete a task, it has to find the relevant code. In every standard agent today, that means grep, ripgrep, find, or directory listing followed by file reads. The process looks roughly like this: search for a keyword, get hundreds of matching lines, open several files to identify which one is actually relevant, discover the right file is named something different, search again, trace imports manually, and finally begin the actual task with a fraction of the context window remaining.

This is not an edge case. It is the default behavior of every major coding agent running against a real codebase today.

A typical session in a large codebase involves grepping for a likely keyword, getting 200 lines of matches, opening three or four files to figure out which one is actually relevant, realizing the right file is named something different and grepping again, then tracing imports manually before finally starting the actual task with significantly less context window left. Larger context windows do not fix this; they just delay it.

After 5 to 6 exploration turns, the context is polluted with rejected files, wrong matches, and dead-end grep results. Research shows that performance degrades by 30 percent or more when irrelevant content accumulates in the middle of the context.

The industry has been treating this as a search quality problem. Better tools, faster ripgrep, smarter regex. The problem is not the search tool. The problem is that the repository has no structural understanding of itself.

Grep is excellent for finding exact string matches, but for the exploratory tasks common in agentic work, its limitations become clear. It has no understanding of indirection or semantic meaning, and it often returns large, noisy blocks of code that pollute the context window and degrade reasoning.

Context window is a finite resource, not a buffer

The industry response to context exhaustion has largely been to expand the context window. Claude's 1M token window, Gemini's 2M token experiments, and sub-agent architectures that offload file reading to worker instances are all attempts to work around the same underlying issue.

Fitting a codebase into context does not guarantee that an LLM attends to the architecturally critical files for a given task. Larger context windows do not eliminate the need for structural navigation; they shift the failure mode from retrieval capacity to navigational salience.

For a modestly sized project with 200 files, a thorough codebase analysis can burn through 100,000 or more tokens before the agent produces a single useful answer. For larger codebases, agents hit context limits and rate limits before returning anything actionable.

The turn limit problem compounds this further. An agent that spends its early turns navigating has fewer turns available to reason, implement, and verify. Research from ETH Zurich found that context files consistently increase the number of steps required to complete tasks, with agents running more tests, reading more files, executing more grep searches, and performing more code quality checks, behavior that was often unnecessary for resolving the specific task at hand. More context loaded upfront does not help an agent finish faster. It gives the agent more to reason about before it can act.

One of the most common failure modes in agentic systems is bloated tool sets that cover too much functionality or lead to ambiguous decision points about which tool to use. Curating a minimal viable set of tools for the agent can lead to more reliable maintenance and pruning of context over long interactions.

What Atomic does differently

Atomic does not ask agents to navigate the repository. It gives the repository an understanding of itself.

When a repository is imported into Atomic, it is enriched with AST analysis, tree-sitter entity extraction, and a syntext n-gram content index. The result is a semantic graph that operates at the function, class, and token level. When an agent needs to find where the authentication library was last modified, it queries the graph directly. The answer is a structured result set, not a list of file paths to manually inspect. The agent arrives at the relevant code in a single graph traversal rather than after five or six exploratory grep turns that leave the context window full of dead ends.

Benchmark · identical prompt, identical codebase

Atomic semantic graph vs. Claude Code grep/find: identical prompt, identical codebase.

The 82 percent reduction in cache reads is the most significant number in this table. It represents how much of the codebase the agent had to touch in order to complete the task. In a standard agent session, that overhead is the tax paid for navigating a repository that does not understand its own structure. In Atomic, the graph answers the question directly.

The architecture behind the query: RDF triples and ontologies

The reason Atomic can answer questions like "who changed the authentication library" rather than simply "which files contain the authentication library" comes down to how the knowledge graph is structured internally. Atomic's graph is built on an RDF triple pattern: every relationship in the repository is stored as a subject, predicate, object statement. In the codebase, this surfaces as typed node IDs and a formal EdgeKind ontology.

A node ID in Atomic is not a raw hash. It carries its type as a namespace prefix:

file:src/auth/login.rs
change:ABC12345
goal:swift-meadow-a3f2
intent:PIMO-1
entity:src/auth/login.rs::validate_token

Edges between those nodes are typed predicates drawn from a controlled ontology:

led_to          : forward causal relationship
explored_via    : a decision was informed by this exploration
committed_via   : a decision produced this file change
verified_by     : a commitment was validated by this verification
blocked_by      : a human gate interrupted this work
failed_with     : a tool call produced this error

A query asking "who changed the authentication library" resolves as a graph traversal: find all nodes of kind file matching auth, follow committed_via edges back to change nodes, follow those to goal and intent nodes, and surface the associated identity and agent metadata. No file needs to be opened. No grep pattern needs to match. The answer is a structured subgraph retrieved directly from the triple store.

This is what makes the 82 percent reduction in cache reads possible. The agent is not reading files to infer structure. The structure was encoded into the graph at enrichment time, and every subsequent query retrieves only the nodes and edges that answer the specific question. The triple pattern also means the graph is composable: any query result is itself a valid subgraph that can be further traversed, filtered, or exported as DOT or JSON for visualization.

The compounding return

Every session run against an Atomic repository makes the graph richer. Provenance records, intent history, and semantic enrichment accumulate with each change. An agent running its hundredth session against a repository has access to everything every prior agent and developer recorded: what was changed, why it was changed, which model made the decision, and how that decision connects to the broader architecture.

Standard agents reset to zero with each new session. They re-navigate the same codebase, re-read the same files, and re-discover the same structure their predecessors already mapped. The problem with long, unplanned sessions is that they accumulate context organically. The agent explores, hits dead ends, backtracks, and all of that exploratory noise stays in the window. Atomic eliminates this by making prior navigation a permanent part of the repository rather than a discarded session artifact.

The efficiency gains in the benchmark above are from a single session. The compounding gains across a team running agents continuously against a shared repository are not yet fully measured. That research is ongoing.

References

1. CodeCompass: Graph-Structured Dependency Navigation Outperforms Retrieval in Architecture-Heavy Tasks, arXiv preprint · 2602.20048 (Feb 2026)
2. Agentic Search: How Coding Agents Find the Right Code, Morph · morphllm.com (Feb 2026)
3. Your Agent Is Spending More Time Finding Code Than Understanding It, DEV Community · Akash Goenka (Apr 2026)
4. Effective Context Engineering for AI Agents, Anthropic Engineering (2025)
5. Context Rot in AI Coding Agents, What It Is and How to Prevent It, MindStudio (Apr 2026)
6. How to Use Sub-Agents for Codebase Analysis Without Hitting Rate Limits, MindStudio (Mar 2026)
7. New Research Reassesses the Value of AGENTS.md Files for AI Coding, InfoQ (Mar 2026)
8. grep, ripgrep, and AI-Powered Text Search, ceaksan.com (Apr 2026)
9. Beyond Grep and Vectors: Reimagining Code Retrieval for AI Agents, Medium · Akshat Jain (Oct 2025)