Ilya Gusev, Matthias Petri, and Andrey Styskin
Ilya Gusev, Matthias Petri, and Andrey Styskin
SELECT the tail FROM the web
SELECT the tail FROM the web
SELECT the tail FROM the web
Agents inherited the web search interface from humans: ten blue links with short snippets. That interface was designed for a person who will click one result and read it. An agent doing real work needs the full distribution of what the world has already tried, what worked, and what didn't.
The web contains that distribution, but search engines weren't built to surface it. The smartest language model still answers like an average one because of the human-focused ten-link API. We introduce SELECT, a new search interface with SQL-like syntax.
Agents inherited the web search interface from humans: ten blue links with short snippets. That interface was designed for a person who will click one result and read it. An agent doing real work needs the full distribution of what the world has already tried, what worked, and what didn't.
The web contains that distribution, but search engines weren't built to surface it. The smartest language model still answers like an average one because of the human-focused ten-link API. We introduce SELECT, a new search interface with SQL-like syntax.
The model knows the best answer but gives the typical ones
Why doesn't the language model alone suffice? There is a misconception that language models compress toward the average, that they return what most people would say. In reality, the best continuation and the mediocre one are both inside the model.
Tests show this: give GPT-3 the background of a real survey respondent, and it answers like people with that background, not like the national average. Show a base model a chess game between strong players, and the model plays better chess than the same model that saw a game between beginners. In both cases the model contains the good answers and the bad ones.
When a question is underspecified and generic, the model gives a typical answer. This is a documented effect: alignment training collapses the model onto its most typical response, because human annotators reward familiar text. The best answers are unique answers, they live in the tail of the distribution, and the model needs a reason to go there. We just need to steer the model into the rare answers with some piece of evidence.
World knowledge is what steers the model to the best answers
Agents can learn from the world's experience instead of only their own sessions. Thousands of people have launched products and written posts, and surprisingly often the outcomes are public. The world is a vast set of experiments whose results are out in the open, in a form you can compute over.
This is effective. If you start with good knowledge of what worked before, you need far fewer observations of your own. Access to external knowledge is worth a lot: on Humanity's Last Exam, Grok 4 scores 25.4% closed-book and 38.6% once it can search and run code. And that jump happens on a benchmark whose authors removed every question a search engine could answer. The model is assembling evidence it could not produce from memory. An agent with world knowledge starts every task near the answer and uses its own feedback only to slightly refine.
Nobody should pay the full cost of learning from scratch when the answer to "has anyone tried this?" is usually “yes, thousands of times, and the results are sitting in public”. At Keenable, we are building the interface that hands this information over.
To get world knowledge, query the web as a database
Finding the public results of those experiments is hard. A standard web search API will get you some evidence, but it was never designed for this task.
Our approach to effectively querying the web is SELECT. SELECT is an agentic tool that queries the web as a database. It gives you the whole distribution instead of just documents. The cleanest way to see it is an example, an agent tasked with pricing a developer tool:
Model alone. After you ask the question “How should I price my AI observability product?”, the model generates an answer based on its parametric knowledge. It gives you a chunk of text: its own opinion conditioned on your prompt. You get the median of every pricing article ever written: three tiers, a free plan, some standard prices. It is correct in the way a horoscope is correct. The model returns the answer an average person would like, because that is what it was trained to do.
Model plus web search API. The model calls intermediate tools, usually doing one or two searches. It sees 10-20 standard blue links with short snippets. Sometimes it decides it wants to read some of those pages, but usually it doesn’t. If you insist, it can do deep research that is exactly the same, but with more tool calls. What it reads is pricing-advice content for humans: value-based pricing, don't race to the bottom, talk to your customers. All true, all useless, and the agent relays it to the user. That's because standard search is ranked for a human reader.
Model plus SELECT. Now the model also calls the tool (sometimes multiple times), but the tool is very different. The whole form of the query (SQL-like syntax) nudges the model to ask for the whole picture. SELECT gives you the table with pricing pages of every developer tool launched in the last three years. For each, it extracts the entry price, whether billing is per-seat or usage-based, whether a free tier exists, and so on. It might discover that entry prices cluster hard at $20 and $49 with a dead zone in between; or that free tiers are near-universal before Series A and quietly disappear after it. The agent is holding the whole market as a table.
The main difference between the second and the third run is the interface, on both ends. The tool in the second run was expecting a search query as an input and was returning ten snippets. The tool in the third run went from keywords to SQL, which pushed the model to ask for the whole picture, transforming the tool output from snippets to a table. In between, WebQL did the work of turning unstructured pages into rows.
SELECT turns a slice of the web into a table
The main task SELECT solves is wide search: getting distributions (tables) instead of single answers. For example, “What does this apartment cost” is just a lookup. “What do two-bedroom apartments in this neighborhood actually rent for, and how long do listings sit before they close” is wide search.
Mechanically, SELECT lets you treat a topical slice of the web as a dataframe. The agent declares the slice of the web and the fields it wants; it can filter, group, aggregate, count, and extract structured columns out of unstructured pages, and the system materializes only what the agent’s query actually needs rather than crawling and dumping ten thousand documents on the agent to parse by itself. The unit you get back is a typed row. That single change is what turns the web from something you read into something you reason over.
The primitives that convert the web to a dataframe have a name in recent database research: semantic operators. They are relational operators that accept prompts executed by an LLM over some database column. The formalism comes from Stanford's LOTUS, which defined LLM-powered filters, maps, joins, and top-k over dataframes and showed they can be optimized like relational plans.
Since then semantic operators have moved into SQL engines: Snowflake ships AI_FILTER and AI_AGG in production as Cortex AISQL. Our operators sit squarely in this lineage with one difference: the table underneath is not a warehouse you already own, but a slice of the live web, materialized by the same query that reasons over it.
Semantic operators allow us to convert unstructured web pages into structured data. They are usually applied to a content column, so they process thousands of pages at each call.
Another direction targets the same task: Perplexity’s Search as Code. It exposes the search stack as a Python SDK and makes the agent write the pipeline by hand, every time, from scratch: fan-out loops, dedup keys, backfill logic.
It is the old competition between imperative and declarative languages. Before SQL you told the system how to walk the data; SQL won in analytical tasks because you declare what you want and the engine owns the how.
When the answer is a property of the set, not of any page
Every use case below shares one pattern: the answer is a property of a set of pages, not of any single one. These are four situations where that pattern shows up most often.
Questions with a huge number of answers. Which institutions win best-paper awards across conferences? Which researchers moved between frontier labs, and which startups did each top VC back, in which round? Even the South Bay's public tennis courts exist only as separate parks-department pages, one per city.
Questions whose answer is a union, not a page. What does an H100 actually cost per hour? The number that hits the invoice is the union of the pricing page, the capacity page, and the egress fee schedule, which means that no single page contains it. The true cost of a flight works the same way: fare plus baggage plus seat fees, spread across three pages of one site. The answer exists, but only as a merge of multiple pages.
Launching anything. Any time you are about to do a thing that thousands of people have done publicly and been scored on (a launch, a title, a thumbnail, a repo, a pitch) you are ignoring public evidence if you only reason from the language model’s priors.
Collecting training data. For AI labs, this is the most strategic surface. SELECT at runtime makes one agent smarter on one task. Using it as a mid-training source makes a model categorically better at an entire vertical, for everyone who uses it, with no query at inference time.
In every case, the query is declarative and the output is the same unit: a typed, cited table over a slice of the web. The anecdotes are compelling, but does SELECT generalize?
SELECT holds up on wide search benchmarks
There are standard ways to measure wide search quality and costs.
The main benchmark that targets table completion is WideSearch, which coined the term 'wide search' for the whole task. The benchmark contains English and Chinese questions from many domains whose answers are tables that cannot be assembled from a single source.
WANDR is another benchmark that was recently introduced by Perplexity. The main difference is that WANDR requires evidence from original web documents: every extracted value must be backed by a quote.
SELECT performs similarly to Perplexity's Search as Code on these benchmarks. However, it is a tool, so you can use it with any model and any harness. We report numbers with GPT-5.6-Sol with medium effort inside a simple ReAct loop with planning and history compression.
Perplexity's SaC numbers are lower than those in their official report. During our reproduction run, we found that 12 WideSearch samples were contaminated by HuggingFace dataset downloads, so we re-ran the evaluation with HF access blocked, and the final numbers came out lower.
Agents need the whole slice, not ten pages
SELECT is a bet on two specific claims: that the web is the largest outcome-labeled dataset in existence, and that agents should query it like a database.
Agents don't want ten pages from search engines, they want the whole slice, because the answer they need is a property of the set, not of any single page.
A stronger model behind a ten-links API still sees ten links. The bottleneck is not only intelligence, it is also access. SELECt is the access.
Keenable SELECT is live. Try it in the demo or add to your coding agent: https://app.keenable.ai/select/start
Or see the gallery of existing reports: https://keenableai.github.io/select-showcase/
The model knows the best answer but gives the typical ones
Why doesn't the language model alone suffice? There is a misconception that language models compress toward the average, that they return what most people would say. In reality, the best continuation and the mediocre one are both inside the model.
Tests show this: give GPT-3 the background of a real survey respondent, and it answers like people with that background, not like the national average. Show a base model a chess game between strong players, and the model plays better chess than the same model that saw a game between beginners. In both cases the model contains the good answers and the bad ones.
When a question is underspecified and generic, the model gives a typical answer. This is a documented effect: alignment training collapses the model onto its most typical response, because human annotators reward familiar text. The best answers are unique answers, they live in the tail of the distribution, and the model needs a reason to go there. We just need to steer the model into the rare answers with some piece of evidence.
World knowledge is what steers the model to the best answers
Agents can learn from the world's experience instead of only their own sessions. Thousands of people have launched products and written posts, and surprisingly often the outcomes are public. The world is a vast set of experiments whose results are out in the open, in a form you can compute over.
This is effective. If you start with good knowledge of what worked before, you need far fewer observations of your own. Access to external knowledge is worth a lot: on Humanity's Last Exam, Grok 4 scores 25.4% closed-book and 38.6% once it can search and run code. And that jump happens on a benchmark whose authors removed every question a search engine could answer. The model is assembling evidence it could not produce from memory. An agent with world knowledge starts every task near the answer and uses its own feedback only to slightly refine.
Nobody should pay the full cost of learning from scratch when the answer to "has anyone tried this?" is usually “yes, thousands of times, and the results are sitting in public”. At Keenable, we are building the interface that hands this information over.
To get world knowledge, query the web as a database
Finding the public results of those experiments is hard. A standard web search API will get you some evidence, but it was never designed for this task.
Our approach to effectively querying the web is SELECT. SELECT is an agentic tool that queries the web as a database. It gives you the whole distribution instead of just documents. The cleanest way to see it is an example, an agent tasked with pricing a developer tool:
Model alone. After you ask the question “How should I price my AI observability product?”, the model generates an answer based on its parametric knowledge. It gives you a chunk of text: its own opinion conditioned on your prompt. You get the median of every pricing article ever written: three tiers, a free plan, some standard prices. It is correct in the way a horoscope is correct. The model returns the answer an average person would like, because that is what it was trained to do.
Model plus web search API. The model calls intermediate tools, usually doing one or two searches. It sees 10-20 standard blue links with short snippets. Sometimes it decides it wants to read some of those pages, but usually it doesn’t. If you insist, it can do deep research that is exactly the same, but with more tool calls. What it reads is pricing-advice content for humans: value-based pricing, don't race to the bottom, talk to your customers. All true, all useless, and the agent relays it to the user. That's because standard search is ranked for a human reader.
Model plus SELECT. Now the model also calls the tool (sometimes multiple times), but the tool is very different. The whole form of the query (SQL-like syntax) nudges the model to ask for the whole picture. SELECT gives you the table with pricing pages of every developer tool launched in the last three years. For each, it extracts the entry price, whether billing is per-seat or usage-based, whether a free tier exists, and so on. It might discover that entry prices cluster hard at $20 and $49 with a dead zone in between; or that free tiers are near-universal before Series A and quietly disappear after it. The agent is holding the whole market as a table.
The main difference between the second and the third run is the interface, on both ends. The tool in the second run was expecting a search query as an input and was returning ten snippets. The tool in the third run went from keywords to SQL, which pushed the model to ask for the whole picture, transforming the tool output from snippets to a table. In between, WebQL did the work of turning unstructured pages into rows.
SELECT turns a slice of the web into a table
The main task SELECT solves is wide search: getting distributions (tables) instead of single answers. For example, “What does this apartment cost” is just a lookup. “What do two-bedroom apartments in this neighborhood actually rent for, and how long do listings sit before they close” is wide search.
Mechanically, SELECT lets you treat a topical slice of the web as a dataframe. The agent declares the slice of the web and the fields it wants; it can filter, group, aggregate, count, and extract structured columns out of unstructured pages, and the system materializes only what the agent’s query actually needs rather than crawling and dumping ten thousand documents on the agent to parse by itself. The unit you get back is a typed row. That single change is what turns the web from something you read into something you reason over.
The primitives that convert the web to a dataframe have a name in recent database research: semantic operators. They are relational operators that accept prompts executed by an LLM over some database column. The formalism comes from Stanford's LOTUS, which defined LLM-powered filters, maps, joins, and top-k over dataframes and showed they can be optimized like relational plans.
Since then semantic operators have moved into SQL engines: Snowflake ships AI_FILTER and AI_AGG in production as Cortex AISQL. Our operators sit squarely in this lineage with one difference: the table underneath is not a warehouse you already own, but a slice of the live web, materialized by the same query that reasons over it.
Semantic operators allow us to convert unstructured web pages into structured data. They are usually applied to a content column, so they process thousands of pages at each call.
Another direction targets the same task: Perplexity’s Search as Code. It exposes the search stack as a Python SDK and makes the agent write the pipeline by hand, every time, from scratch: fan-out loops, dedup keys, backfill logic.
It is the old competition between imperative and declarative languages. Before SQL you told the system how to walk the data; SQL won in analytical tasks because you declare what you want and the engine owns the how.
When the answer is a property of the set, not of any page
Every use case below shares one pattern: the answer is a property of a set of pages, not of any single one. These are four situations where that pattern shows up most often.
Questions with a huge number of answers. Which institutions win best-paper awards across conferences? Which researchers moved between frontier labs, and which startups did each top VC back, in which round? Even the South Bay's public tennis courts exist only as separate parks-department pages, one per city.
Questions whose answer is a union, not a page. What does an H100 actually cost per hour? The number that hits the invoice is the union of the pricing page, the capacity page, and the egress fee schedule, which means that no single page contains it. The true cost of a flight works the same way: fare plus baggage plus seat fees, spread across three pages of one site. The answer exists, but only as a merge of multiple pages.
Launching anything. Any time you are about to do a thing that thousands of people have done publicly and been scored on (a launch, a title, a thumbnail, a repo, a pitch) you are ignoring public evidence if you only reason from the language model’s priors.
Collecting training data. For AI labs, this is the most strategic surface. SELECT at runtime makes one agent smarter on one task. Using it as a mid-training source makes a model categorically better at an entire vertical, for everyone who uses it, with no query at inference time.
In every case, the query is declarative and the output is the same unit: a typed, cited table over a slice of the web. The anecdotes are compelling, but does SELECT generalize?
SELECT holds up on wide search benchmarks
There are standard ways to measure wide search quality and costs.
The main benchmark that targets table completion is WideSearch, which coined the term 'wide search' for the whole task. The benchmark contains English and Chinese questions from many domains whose answers are tables that cannot be assembled from a single source.
WANDR is another benchmark that was recently introduced by Perplexity. The main difference is that WANDR requires evidence from original web documents: every extracted value must be backed by a quote.
SELECT performs similarly to Perplexity's Search as Code on these benchmarks. However, it is a tool, so you can use it with any model and any harness. We report numbers with GPT-5.6-Sol with medium effort inside a simple ReAct loop with planning and history compression.
Perplexity's SaC numbers are lower than those in their official report. During our reproduction run, we found that 12 WideSearch samples were contaminated by HuggingFace dataset downloads, so we re-ran the evaluation with HF access blocked, and the final numbers came out lower.
Agents need the whole slice, not ten pages
SELECT is a bet on two specific claims: that the web is the largest outcome-labeled dataset in existence, and that agents should query it like a database.
Agents don't want ten pages from search engines, they want the whole slice, because the answer they need is a property of the set, not of any single page.
A stronger model behind a ten-links API still sees ten links. The bottleneck is not only intelligence, it is also access. SELECt is the access.
Keenable SELECT is live. Try it in the demo or add to your coding agent: https://app.keenable.ai/select/start
Or see the gallery of existing reports: https://keenableai.github.io/select-showcase/
