Search has two new users
Jo Kristian Bergum and Henning Baldersheim have written up why they started Hornet. It's billed as a founding story, but most of it is a working history of search infrastructure from two people who built and ran Yahoo's search platform from 2007, on servers with two to four cores and 4 to 8 GB of memory, sharding early because nothing else fitted, then rebuilding every few years as memory got cheap, cores multiplied, SSDs arrived, and ranking went from linear models to gradient-boosted trees to BERT, and then on to whatever we're calling retrieval-augmented anything this month. It's the best short account I've read of why the right retrieval design keeps moving, partly because they were in the room for all of it.
I first met Jo at Haystack in Charlottesville in April 2018, the first year of the conference and about six months after Yahoo, by then Oath, had put Vespa on GitHub. Most of us there were still working out how to get learning-to-rank running inside Elasticsearch and Solr, and here was someone whose engine had been doing ranking, real-time updates and serving at Yahoo scale for years, and you could now go and read the source. I came away impressed and I've read what Jo writes ever since, through his Vespa years and now at Hornet. He's one of a handful of people whose posts I read properly rather than skim.
Their line - "Agents are the new user of retrieval infrastructure. It's a new type of workload." - isn't new. They've been saying it since the spring, and I responded to one of their experiments in July. This post is the backstory. I'm not going to argue with it. What I want to do is add the user they don't cover, who sits a layer up from where they work, which happens to be the layer I work in.
Workloads, workloads, workloads
The heading's theirs, and so is the first line under it: "Workloads matter the most." I've spent most of this year going on about operating points, which is the same idea in more words: that a retrieval system rarely has a correct design, only a correct one for a given corpus, query mix and budget. Jo and Henning's version is more concrete: a billion documents where every query is routed to a tenant partition of a few thousand might be best served by an exact scan, while a billion documents with no partition key is a different architecture altogether.
Then scaling. Algorithms whose work grows linearly with document count shard cleanly; divide N over K nodes and the total is still N. Algorithms closer to log(N) don't, because every query still visits every shard and the per-shard work barely shrinks, and they've watched teams buy 10x the nodes for about 2x the throughput. They don't name a structure in that passage; the one I'd name is an HNSW graph, which is what most of you have behind your vector search, probably without ever having asked this question. Their advice is to benchmark with representative data and queries, and the filters and update rates you'll actually see, before you add capacity. I have given that advice so many times it has lost all force, and it's still the advice.
And the agent workload. Jo's trace analysis of GPT-5 on BrowseComp-Plus shows a median of 24 search calls per question, a median query of 10 terms (past the 99th percentile of the old AOL log), and phrase quotes in 98% of sessions. Reading the results costs money too, and the new post puts a number on it: 24 searches returning five 512-token snippets each is about 61k tokens, which they price at $0.61 "to read once" at GPT-6 Astra's uncached input rate. Note the "once". In a loop, the context gets re-read every turn.
The user who stopped seeing the results
Those 24 searches come from a research benchmark, riddle-like questions over a fixed corpus of 100,195 pages, so I shouldn't pretend they're shoppers. But the shape is the same on the assistant on my phone: somebody started every one of those searches, the agent ran them, and the person got back a paragraph.
What the person no longer gets is the results page. I wrote earlier this year about catching myself acting on an answer about a buzzing light fitting without ever learning whose knowledge it was, and what unsettled me wasn't that I'd used an assistant, it was that the checking had quietly fallen away. Back in the ten-blue-links days you were the last relevance filter: you scrolled past the 2019 forum thread, you opened four tabs to compare. That filter has moved into the model, and Hornet's own Mutually assured distraction post puts the mechanism better than I can: for a Transformer, in their words, there is no "ignore". A stale pricing page goes into the context looking as authoritative as everything else, and you can't discount a source you never saw.
So search has two new users, or near enough. The retrieval engine has a new client. The person who used to be that client is still there, one step back, and can no longer see what was retrieved. I'm not sure "new" is quite the right word for them - it's the old user, blindfolded - but neither of them behaves like someone typing two words into a box.
Where their numbers point for brands
The connection I actually want to make comes out of Hornet's data rather than mine. Every pressure they describe on the agent side pushes toward fewer documents in context: fewer per turn and fewer in the final set, even though the agent reads far more over a whole task than any human ever did (their own code-mode run searched more per question than tool mode did, and still cut the prompt tokens in half). Reading costs money. Distractors poison reasoning, so the MAD post argues for low-k retrieval, or rather dynamic-k, and for metrics that give plausible-but-wrong passages negative utility. The code-mode harness curates evidence before carrying any of it forward. In my citations post I put the number at three to six citations per answer where there used to be ten links. The agent's results page is narrower than the human one was, and cost and reliability keep pushing it narrower. The slot a brand is trying to occupy is shrinking, and the person who might once have spotted it in position seven has stopped looking.
I should be straight about a tension here. From Hornet's seat, a brand optimising its way into the context window is a candidate distractor, and a retriever that scores utility rather than similarity is built to keep it out. I think that's right, and it's good news for anyone whose content actually is the answer. I wrote in June that anyone claiming to have cracked the algorithm is selling something; distraction-aware ranking is one more reason that stays true.
One more thing from their post that I recognised. Jo and Henning want agents to tune their own retrieval: change a scoring configuration, test it against judged queries, compare quality and cost, then adopt. The hard part of that loop has always been the queries. Their series keeps falling back on the 2006 AOL log for how humans typed, presumably because nothing newer is public, and there's no public log at all of what people now ask ChatGPT, which is a different gap. The prompt universes we build at Searchable, millions of consumer questions mapped by topic and buying stage, are the nearest thing I know of to filling that second one. (I wrote about how we lay them out a little while back, and if you'd rather see one than read about it, there's a video walkthrough.) They're not a judged set; we have no relevance labels, only what the assistants actually say. So they're the query half of a test collection for a world that stopped publishing query logs twenty years ago. What the judgment half looks like, I don't know yet.
Jo and Henning's thesis, in their words, is that "investing in retrieval is mandatory for any organization that wants agents to work with its data." Go one level up and it's mandatory for any organisation that wants to show up in the answers people now read instead of the results they used to see. Everything is search and search is everything ❤️