Agentic tool search, made right
Agentic search across many walled-garden sources works when each source is treated as its own authenticated tool, every result carries a real engagement signal, and an agent judge synthesizes the normalized results with citations. I walk through that architecture — fan-out, signal normalization, judged synthesis — and where it breaks.
Most agents search the web the way a browser does: one query, one ranked list, and a model that trusts whatever the list returns. It works, and it is also where a lot of agentic systems quietly cap out. The ranking you inherit from a general web index is optimized for a decade-old objective — pages that earned links and keywords — and it is blind to the two things I usually care about: what happened in the last month, and what the people who actually use a thing think about it.
"Tool search" gets used two ways in this field. One is an agent picking which capability to call from a large registry. The other is an agent searching across many sources to answer a question. This post is about the second, because the design choices that make it work are less obvious and the failure modes are more interesting. A small open project, the last30days skill, is a clean worked example, so I will use it to keep the argument concrete.
Each source is a tool
The first reframe is that the search box is not the tool — each source is. Reddit, X, YouTube, Hacker News, GitHub, Polymarket: every one is a walled garden with its own API, its own auth, its own rate limits and quirks. No single model has native reach into all of them. A general web index does not touch Reddit comments or X posts well; a model with a Reddit deal still cannot read X or TikTok. The project's framing is blunt and correct: "a dozen disconnected platforms, bridged by an agent."
That bridge is the product. It runs on bring-your-own-keys and browser sessions, which is the only honest way to cross those walls — you authenticate as yourself to each garden, and the agent fans out across them on your behalf. Once you accept that the unit of search is a source rather than a query, the rest of the architecture follows.
Fan out, do not funnel
The shape that works: parallel fan-out across authenticated sources, a normalized engagement score, then a judge that has to cite.
The naive shape is a funnel: ask one source, and if it is thin, ask the next. The right shape is a fan-out. Issue the query to every source in parallel, let each return its own ranked slice, and only then merge. This helps latency — the wall-clock cost is the slowest single source, not the sum — but it matters more for coverage. Sources disagree, and the disagreement is signal. The developer consensus on Hacker News and the unfiltered take in a Reddit thread are different measurements of the same event, and you want both before you decide which to trust.
Parallelism also forces a discipline that sequential search lets you skip: every result has to arrive in a common shape — text, source, timestamp, and an engagement number — because something downstream is going to compare a YouTube transcript against a Polymarket position. Designing that common record is most of the work.
Carry the engagement signal as data
SEO relevancy ranks editors and keywords and goes blind on recency; social relevancy ranks real engagement and has to defend against gaming.
This is the part that general search gets wrong for current questions. A web ranker scores a document by its text and its link graph. That is SEO relevancy, and it has a structural blind spot: recency. The pages that have accumulated links and keyword authority are rarely the pages written this week.
The alternative is to attach a real-world engagement signal to every result and rank on that. Upvotes on Reddit. Likes on X. Views on a video. Money on a prediction market. The project calls this "social relevancy, not SEO relevancy," and the framing earns its keep: a Reddit thread with 1,500 upvotes is a stronger signal than a blog post nobody read, and a Polymarket position backed by real volume is harder to wave away than a pundit's guess. These are not opinions about relevance; they are counts of human attention and, in the case of prediction markets, capital at risk.
The engineering consequence is that engagement is a first-class field, not a sort key you bolt on at the end. Each source adapter is responsible for extracting it honestly — the upvote count, the view count, the dollar volume — and for refusing to invent one when the platform does not expose it.
Normalizing apples, oranges, and dollars
The catch is that those signals are in different units. An upvote is not a like is not a view is not a dollar. Ten thousand views is ordinary; ten thousand upvotes is enormous; ten thousand dollars on a thin market is decisive. If you rank on raw numbers, the loudest-unit source wins every time and you have rebuilt a popularity contest with extra steps.
So the signal has to be normalized before anything compares across sources. In practice that means scoring within a source first — a result's strength relative to the typical engagement on that platform, not its absolute count — and putting heavy-tailed quantities like views and dollars on a log scale so a single viral outlier does not flatten everything beneath it. The exact transform matters less than the principle: comparison happens in a normalized space, and the raw counts are kept for display and audit. Get this wrong and the whole ranking inherits the bias of whichever platform happens to mint the biggest numbers.
Let a judge synthesize, with citations
The last stage is an agent that reads the merged, scored results and writes one answer. Two constraints keep it honest. First, a freshness floor: weight recent, high-engagement material over old material, because the entire point was to beat stale training data and stale top-of-search pages. Second, citations on everything. The judge does not get to assert; it has to point at the source and the number behind each claim. That is what makes the output checkable, and checkable is the only kind of synthesis I will put in front of a decision.
Where it breaks
I would not ship this without naming the failure modes. Engagement can be gamed — bots, brigades, and coordinated likes are real, and any system that ranks on attention is a target. Some queries return thin evidence, and a good pipeline says so rather than dressing up three weak results as a consensus. Auth is the fragile seam: keys expire, sessions break, and a degraded run with two sources down is a different object than a full one, so it should be labeled as such. And fan-out costs more than a single query, in tokens and in API calls; the parallelism that buys coverage also buys a bigger bill. None of these are reasons not to build it. They are the things the design has to acknowledge out loud.
The principle
What I keep coming back to is that relevance for a current question is a signal you have to source, not a property you can infer from text. General web search infers it and does a fine job for stable questions. For "what is true about this, this month," you are better off measuring it directly — going to where people vote with upvotes, likes, and money, normalizing those votes into something comparable, and letting an agent do the bridging that no single platform will do for you. That is agentic tool search made right: not one better search box, but many honest sources, scored by the people using them, and held together by something that can read all of them at once.