Sonar closes that gap. It is a retrieval pipeline that gives AI systems live, source-grounded access to the open web, returning ranked, scraped content ready for a model's context, behind a single integration surface.
Large language models are bounded by their training data. Anything that happened after the cutoff, anything niche enough to be underrepresented, anything changing in real time, none of it is reachable by the model alone. Ask a model about something that didn't exist when the model was trained, and the answer is either out of date or fabricated.
The capability to search the web, read the results contents, and bring the information cleanly into the model's context, isn't built into the models themselves. It has to be assembled. And assembling it well is harder than it looks. The developer doesn't just need data; they need data shaped for a model's context, full content rather than summary snippets, ranked for relevance so token budgets aren't wasted on noise, and reliable enough to be worth integrating against. To get that depth, developers building AI products at the API level have typically had to balance a search service, a scraping service, and a reranking endpoint, each with its own cost model, failure mode, and integration surface.
Sonar is that capability, assembled. One pipeline, one call, with results shaped for a model's context.
Sonar handles a query in three stages: search across many engines at once, rerank against the original query, and scrape the chosen results. Model-ready content is then delivered back to the consumer.
A metasearch aggregator fans the query out across a curated set of engines, spanning general web, encyclopedic, and developer-focused sources, and merges the results into a single ranked list. No single engine is the source of truth; results come from multiple providers simultaneously, with their relative rankings preserved through the merge.
The merged result list is passed to a neural reranker, a transformer-based relevance model, which reorders it against the original query. The reranker operates on the result snippets returned by the search stage rather than on full page content, working from the titles and short excerpts each engine provides. If it times out or fails, results pass through in their original order.
Once the reranked results have been provided, a scraping service extracts full page content from the top URLs. The scraper renders JavaScript via a headless browser, which means modern sites are handled correctly rather than returning empty shells. Scrapes run as queued jobs through an asynchronous broker, so the calling system isn't blocked on render time.
The three stages sit behind a single integration surface. A consumer makes one call and gets back a result set ready for a model's context, with the search aggregation, relevance reranking, and content extraction handled inside the pipeline rather than stitched together by the consumer.
The pipeline is composable. Each stage operates against a clean interface, and the ordering is a configuration rather than a constraint. Sonar's recommended configuration runs the stages as described above, with reranking before scraping so that fetch cost and latency stay proportional to what the consumer actually consumes. A consumer with different priorities, such as relevance over cost or full-content reranking over interactive latency, can reorder the same stages without rebuilding the pipeline.
The integration surface stays the same regardless. One call in, model-ready content out.
Sonar is composed of four runtime components, designed to deploy as a unit. The component shapes are deliberate, and several of the design choices are worth surfacing.
A metasearch aggregator handles query fan-out and result merging. A neural reranker is invoked from inside the aggregator's process as a post-search hook. A scraping API handles full-page extraction, backed by a headless browser service for JavaScript rendering. A Redis-compatible cache provides shared state across the pipeline.
The alternative — scraping all results and then reranking on full content — would in principle give the reranker more signal. In practice it pays N×fetch cost and latency on results that will never be read. Reranking on snippets first, then scraping only the top selections, keeps the search hop interactive and the cost model linear in what the consumer actually consumes. The pipeline's seams are clean enough that this ordering can be reversed if a different consumer profile demands it.
The obvious shape for a three-stage pipeline is three services. Folding the reranker into the search stage as a post-search hook instead lets it reuse the aggregator's existing result-container abstraction, preserve multi-engine ranking metadata cleanly, and return reranked results through the same JSON endpoint consumers were already calling. One fewer service to deploy, one fewer hop per query, no loss of separability. When the consumer profile requires a different operational order then processing will flow through a standalone reranker, which loses many of the efficiency and performance benefits described.
AI models are limited to what they were trained on. Sonar gives developers a single integration surface to reach past that limit.
Search, ranking, and scraping handled inside one pipeline, with results delivered ready for the model's context.
