SEPTEMBER 03, 2026 · Evis Drenova
Introducing Agentic Search for Code and Context
For most of software history, code search meant finding a symbol, string, or file. That worked when a developer knew which repository to open and which keywords to try.
Agents changed the requirements. To work effectively, an agent needs to understand how a shared package is used across an organization, which pattern a team settled on, and why a change landed. That context sits in repositories, commits, and past sessions.
Finding it used to mean cloning repositories, grepping files, and reading through matches one at a time. That process is slow, token-intensive, and skips the history that produced the code.
Today we're launching Agentic Search to replace that loop with a single API your agent can query across every repository it can access. Each result returns the matching code and commit, plus that commit's checkpoint: the session, the transcript, and the prompt behind the change.
We benchmarked search against the hardest question an agent can be asked: "Why is our code like this?" Across nine real engineering-history questions, an agent with access to the full Git history and the GitHub CLI answered 70 of 90 runs correctly. The same agent with search answered 81 of 90, using less than half the tokens and half the steps.
One API: Two Types of Search
In agentic systems, "search" serves two separate needs, so we built one system to serve both.
Semantic search answers what happened and why. It enables agents to search your sessions, commits, checkpoints, and transcripts, matching meaning and tolerating imprecise words. Search "rate limit retry logic" and it finds the session where an agent wrote it, even if the word "retry" never appears.
Code search answers where an exact line of code lives. It's a literal, symbol-aware search over source, with definitions and references, so a query for a config key returns that config key, every time, or it's broken.
Agents have full control over both search types and can filter to individual repos or search everything they have access to.
Under the Hood
Indexing: From Push to Searchable
The same repo activity stream that powers Entire feeds directly into the search index. Every push emits a ref event onto a durable message stream, and a fleet of indexer workers consume that event and determine what's changed.
Indexing is incremental. A long session produces many checkpoints, and each checkpoint indexes only the slice of transcript that's new since the previous one. A three-hour session doesn't get re-embedded from the top every time the agent commits. The stripped increment is chunked into roughly 700 tokens with one turn of overlap, embedded, and upserted alongside the committed files. A query returns the chunk that matches, not the full transcript.
Documents live in turbopuffer with one namespace per repository, stored in the account's native region. A query only ever fans out to the namespaces it can access. A repo you can't see is a namespace that never gets queried.
In a steady state, pushed commits become searchable within seconds.
Ranking, Recall, and Relevance
For each repo in scope, two retrieval queries run concurrently: a full-text query (BM25, with a weighted formula for titles, metadata, and body text) and a vector query against the embeddings. The union of the two is the candidate set.
Because BM25 scores and cosine similarities are not comparable numbers, we rank results in three tiers:
-
Full-phrase matches: The exact query phrase appears verbatim. We rank these highest, because if you know what you're searching for, you probably want that exact thing returned.
-
Keyword matches: Some query words appear in some form. We use stemming and tokenization to pull keywords out of the natural language query. Search "how did we implement jwt auth?" and documents containing "auth" and "jwt" are likely decent matches.
-
Vector-only matches: No lexical overlap appears at all. The embedding alone, via the cosine similarity score from ANN, thinks it's related. In our testing, the highest scoring cosine matches usually had matching keywords too, so they tend to rank well.
Tiering leaves roughly 200 candidates that scored well on recall. Our reranking model then orders them by relevance rather than retrieval score.
Code Search: Exact by Design
A performant indexing pipeline powers code search. On push, it fetches the repo, builds a custom index, and stores it in object storage. It typically updates the index incrementally rather than rebuilding it, and caches hot repos locally for fast reads. Code search supports literal and regex queries plus symbol extraction for jump-to-definition and find-references, within a file and across a repo.
Median query latency is around 100 milliseconds across thousands of indexed repos. When an agent asks, "where is MAX_QUERY_FANOUT_CONCURRENCY set?" the answer returns before the model has finished its next token.
One Query, Every Region
Entire stores your repos in the region you choose, available today in EU, US, India and Australia. You can mirror the same repo across regions so teams and agents work against nearby copies, or keep different repos in different jurisdictions when data residency matters. This keeps access fast without forcing all your code into one global location.
Search inherits that geography completely. Each region runs the full stack: its own indexers, its own vector namespaces on a region-pinned endpoint, its own embedding and reranking, and its own code-search engine. When a repo lives in Frankfurt, everything derived from it lives in Frankfurt too: the transcript chunks, the embeddings, and the code search index. Mirror a repo to three regions and it still has exactly one home, so a broad query never returns the same result twice, and there's never ambiguity about which copy is authoritative for search.
At query time, this globally distributed system still behaves like one search box. A single query fans out in parallel to every region where you have data. Each region resolves which of your repos it homes, searches them locally, and returns the result. A thin merge layer combines the slices into one list. What crosses a regional boundary is the query and the ranked results you're authorized to see; the corpus never moves. The query goes to the data, not the other way around.
If a region is slow or unreachable, you get the other regions' results with the response flagged as incomplete, rather than a hung query or a silently partial answer.
Benchmark: “Why Is Our Code Like This?”
The questions that cost engineering teams the most time are questions about why: "why is this config set this way?" and "what incident produced this change?" Those answers live in agent sessions.
We pulled nine real engineering-history questions asked inside our own organization, including "why does the rate limiter count inputs instead of requests?", and ran each one ten times through two identical headless Claude agents. Both agents got full-history clones of every relevant repo, git log, git log -S, git show, and the GitHub CLI for PRs and issues. One also got Entire's agentic search.
| Scenario | No search | Search |
|---|---|---|
| Across all 90 runs | ||
| Correct answershigher is better | 70/90 | 81/90 |
| Tokens per questionmean · lower is better | 547K | 262K |
| Cost per questionmean · lower is better | $0.38 | $0.23 |
| Agent stepsmean · lower is better | 14 | 7 |
| Deepest-history question | ||
| Correct answershigher is better | 0/10 | 10/10 |
| Time to answermedian · lower is better | 407s | 35s |
| Unprompted tool use | ||
| Reached for search on its ownof 90 runs | — | 90/90 |
| Search as the very first tool callof 90 runs | — | 66/90 |
Three things stand out.
First, the gap concentrates where history runs deep. Seven of the nine tasks tie at 10/10. On the hardest question, the design history of an autoscaler, the Git-history agent produced a plausible but wrong adjacent story in all ten runs. It found real commits, real PRs, and a coherent narrative, all about the wrong thing. The search agent found the session where the decision was made and went 10/10 in 35 seconds.
Second, agents reach for search on their own. The search-arm agent used unprompted in 90 of 90 runs, and as its first tool call in 66 of them. When the question is "why," the answer lives in sessions and checkpoints rather than in the code, and the agent can tell.
Third, a methodological caveat applies. These questions target our own organization's history, so task-selection bias applies. Our commit messages are detailed, largely because agents write them, which strengthens the Git-history baseline. For most teams, the gap may be wider.
We published the full harness, tasks, grading methodology, and raw per-run results at entireio/searchmark, and designed the harness so you can rerun it against your own org.
Try It
The fastest way to use search is to install the Entire CLI and the search skill. Run in your repo.
-
CLI: provides semantic search across your sessions, commits, checkpoints, and transcripts. Add
--codeto include code matches. Use interactive mode for a tabbed view, or--jsonfor structured output agents can read. Scope any search to one repo, several repos, or everything you have access to. -
Web: entire.io also provides search in the browser. Click Search in the left-hand menu. Code search includes definitions and references, both within a file and across the repo.
-
Agent skill:
/searchteaches your agent when and how to use the CLI, so it reaches for search instead of cloning repos and grepping files.
We are building Entire to be the system of record for agentic coding. In the coming weeks, we'll keep shipping tools that let agents query code, sessions, and commits together, making Entire one API for your code and the work that produced it.