AnswersAgents & RAG

Why Do AI Agents Search With Regex?

Q: Given a keyword tool and a regex tool, why do agents reach for regex even for plain phrase queries, and what does that demand from the search engine underneath?

Agents search with regex because it is the one tool that covers every query they produce. A literal phrase is already a valid regular expression, and case insensitivity, optional spelling, and alternatives are small edits to the same string, so the agent uses regex for everything. That makes a good interface and a costly operator. Regex is fast per string and slow per corpus, and an agent issues many such queries at once. The engine underneath has to make regex cheap at scale, or the agent's own search behavior becomes the bottleneck.

Given a keyword tool and a regex tool, why do agents reach for regex even for plain phrase queries, and what does that demand from the search engine underneath?

3 min readAugust 2026

What do agent regex queries look like?

Watch an agent work and the pattern shows quickly. It sends invoice when it means a keyword. It sends (?i)nobel prize when it wants a phrase search that ignores case. It sends colou?r to cover a spelling variant, and it sends error (reading|writing) file to test two hypotheses in one call. None of those queries need the power of regex, but regex expresses all of them, so the agent never has to choose a tool. TopK observed the same behavior in production, and it is what motivated the sparse-gram regex index.

Same regex, different query distribution.

Person searching

One query at a time

Keywords for keywords, regex rarely

Can tolerate a slow scan

Scans are an occasional cost

Agent searching

Many concurrent probes

Regex for everything, mostly literals

Explores, verifies, refines in a loop

Scans saturate immediately

Why does this break a naive engine?

It breaks because the cost is per document. A regex filter over a collection reads and tests every row, and a person's occasional query can absorb that. An agent's burst of concurrent regex filters cannot absorb it, because the scans compete to read the same body of text and throughput stops growing almost as soon as concurrency does. The same thing happens in why RAG fails for agents, where agent workloads take a mechanism built for one human query at a time and run it many times in parallel, which exposes costs a person never notices. Why regex in particular scales this way is covered in why is regex search slow at scale.

What does the engine have to do about it?

It has to use the literals. The useful observation in TopK's design is that agent regexes contain many literals, and even a pattern with optional sections or alternatives says that certain characters must occur. An index over those characters turns each regex into a boolean expression over required n-grams, generates a small candidate set, and runs the exact regex only on the candidates. The agent keeps the interface it prefers, and the engine keeps the work small. How the index is built is in how do you index text for regex search.

How much does it matter?

It decides whether agent search is viable at all. On TopK's cluster measurement at concurrency sixteen, the sparse-gram path delivered 55.3 times the throughput and 61 times lower average latency of a full scan. Indexed throughput also grew almost thirteen times from concurrency one to sixteen, and throughput on the scan path barely moved over the same range (August 2026). Agents run at those concurrency levels.

TopK's regex filter plans through the index automatically.

from topk_sdk.query import select, field

# Whatever literals the agent's pattern contains become the candidate plan.
docs = client.collection("docs").query(
    select("text").filter(
        field("text").regexp_match("(?i)nobel prize")
    ).limit(50)
)

The fast regex search post has the full design, and the query documentation covers the filter syntax.