Keenable turns live web research into SQL queries

Keenable treats web research as a database query. Its new SELECT system lets an agent issue a read-only DuckDB SELECT statement against live web data, combining search, page fetching and semantic extraction inside the query itself.

The system is presented through Keenable’s SELECT showcase, which displays finished research reports alongside the full execution trail: every query, tool result and result set. A sample request asks which AI researchers moved between frontier labs since 2025, then requests the researcher, former lab, new lab and month of each move. SELECT translates that request into SQL that searches multiple queries, filters pages by meaning and extracts the requested fields.

The design addresses a weakness in agentic search. A conventional web-search tool may return 10 links, leaving the agent to open each page, decide which passages matter and assemble the answer through additional model context. SELECT shifts much of that work into the query engine. A single call can search more than 1,000 pages, apply an exact WHERE clause without an LLM call, run structured extraction on the rows that survive, and then group the results.

The underlying service is an MCP server with one primary tool named select. It runs web and semantic operators outside DuckDB, inserts their output into the row set, and executes the final SQL in DuckDB. The service saves every query result as a result set with an ID, and later queries can read from that stored result.

Recommended reading

Gradium makes its 216ms TTS model the default

Ava Chen • Sep 1, 2026 • 6 min read

The operators inside SELECT

Web access and model-based interpretation appear as SQL functions rather than separate tool calls. Exact SQL filters run first, so semantic operators don’t have to process every page returned by search.

The operators can also be composed with ordinary SQL. For example, an agent can use SEM_SCORE in an ORDER BY … DESC LIMIT k clause, or use SEM_NORM in GROUP BY to merge differently written versions of the same entity. WEB_SEARCH and WEB_FETCH can run once per row, with arguments built from row values such as name || ' founding year'.

This differs from a prompt wrapped around a search API. Exact predicates can discard rows before the model-based operators run, while the semantic functions handle tasks SQL cannot express directly, such as deciding whether a page describes “a named researcher moving between frontier labs” or extracting a field from unstructured text.

Two agents, stored results and generated reports

SELECT separates research from presentation. The research agent is a plain tool loop: an LLM writes a SELECT statement, runs it through the MCP server, examines the returned rows and continues querying until it has enough data. Follow-up questions continue from the stored transcript rather than starting a new conversation from scratch.

A second report agent runs inside generate_html_report. It receives the user’s brief, the rows from selected result sets and an authoring guide, then builds an HTML report in a sandboxed Python session. The result sets are supplied as data frames, so the model does not need to retype the collected data into the page.

The publishing loop includes a limited verification step. After rendering a draft, the server returns screenshots and the page’s JavaScript error count; the report agent can fix the document and publish again within a fixed budget. Only the final draft remains live as a shareable link.

The architecture has two audit trails: the research transcript records the agent’s tool calls and SQL, while stored result-set IDs preserve the intermediate data used by the report generator. This lets readers inspect which pages were searched and which rows were filtered out, rather than seeing only the final answer.

What SELECT changes—and what it doesn’t disclose

Keenable’s earlier NEEDLE benchmark work on search APIs measured 15 APIs and used about 124 curated RSS feeds across 52 US Google Trends geographies. SELECT is a query layer rather than another benchmark result, and the showcase does not provide independent accuracy, latency or cost measurements for its reports.

The published description specifies where model calls occur: SEM_EXTRACT uses one LLM call per surviving row, and SEM_MATCH uses an LLM test per row. That makes early exact filtering central to resource use, but the material does not state the price of those calls, the model providers involved, rate limits, retention period for stored result sets or the maximum query size.

It also doesn’t claim that every retrieved fact is correct. A semantic predicate can select the wrong page, and extraction can return null when a page lacks evidence; the showcase exposes the trajectory so a reader can inspect the inputs and intermediate rows. For engineers evaluating the system, that trace is useful, but it is not a substitute for published precision and recall numbers.

Keenable SELECT is currently demonstrated through generated reports and a live application entry point. The supplied material does not establish a public pricing plan, an enterprise SLA or a broader rollout schedule. It also leaves open whether moving research into SQL lowers total cost and improves reproducibility in real workloads once per-row model calls and web-fetch volume are included.