Keenable SELECT executes read-only DuckDB SQL queries against live web data for structured research

Keenable’s SELECT system reframes web research as a database problem by embedding search, fetching, and semantic extraction into DuckDB SQL queries. The design replaces iterative agent loops, where an LLM opens links, reads pages, and synthesizes answers, with a single SQL statement that executes these steps in sequence. This shifts computational load from the LLM to the query engine, which can process thousands of pages with exact filters before invoking model-based operators like `SEM_EXTRACT` or `SEM_MATCH`. The approach is read-only, avoiding the risks of write operations on live web data while preserving the flexibility of SQL for filtering, grouping, and ranking.

The system’s efficiency stems from its operator composition. Web and semantic functions appear as SQL functions, allowing engineers to chain them with standard SQL clauses like `WHERE`, `ORDER BY`, or `GROUP BY`. For example, `WEB_SEARCH` can run once per row, with arguments dynamically built from other columns, while `SEM_NORM` normalizes semantically equivalent values for grouping. This reduces redundant LLM calls by discarding irrelevant rows early, but it also ties the system to DuckDB’s execution model. The proprietary operators (e.g., `SEM_EXTRACT_ALL`) are not portable to other SQL engines, and their performance depends on DuckDB’s ability to optimize the query plan.

SELECT separates research from presentation with two distinct agents. The research agent generates SQL queries, executes them via an MCP server, and stores intermediate results as named result sets. A second report agent then assembles these results into HTML reports, using the stored data frames to avoid retyping or hallucination. This division of labor improves reproducibility, as the research transcript and result-set IDs create an audit trail for every step. However, the system’s transparency is limited by its reliance on Keenable’s MCP server, which abstracts the underlying web and semantic operations. Engineers cannot inspect the raw tool calls or intermediate outputs unless they are explicitly saved as result sets.

The architecture’s trade-offs become clear in its verification and publishing loop. The report agent can revise drafts based on screenshots and JavaScript errors, but only within a fixed budget, which may constrain complex reports. Stored result sets enable follow-up questions to build on prior work, but the system does not disclose how it handles dynamic web data, such as pages that change between queries, or how it scales beyond the 1,000-page limit mentioned in the material. For engineers, the primary value is the ability to express research tasks in SQL, but the system’s closed-loop design and DuckDB dependency may limit its use in environments requiring broader database compatibility or custom tooling.