Keenable SELECT: el agente que busca la web con SQL

Qué es Keenable SELECT y por qué cambia la conversación

Keenable AI publicó este 1 de septiembre una galería con 20 informes de investigación generados íntegramente por SELECT, su nuevo agente MCP que ejecuta consultas SQL con operadores semánticos directamente sobre datos web en vivo. En lugar de entregar al agente «diez enlaces azules» para que los lea uno por uno, SELECT mueve el trabajo de filtrado y extracción al motor de búsqueda, antes de gastar tokens del LLM.

La propuesta contrasta con el patrón dominante hasta ahora: un agente recibe una lista de URLs, las visita, y construye la respuesta releyendo páginas completas con modelos caros. En la galería de Keenable, cada tarjeta muestra el informe final junto con la trayectoria completa detrás: cada consulta SQL, cada herramienta invocada y cada conjunto de resultados. Esto convierte el proceso, normalmente opaco, en algo auditable de extremo a extremo.

Keenable no es un recién llegado: salió del modo sigilo el 25 de agosto con una ronda semilla de US$26M liderada por Accel, con participación de Conviction Partners y varios ejecutivos de Google y Amazon como inversores ángel, según reportó TechCrunch. La empresa, fundada por Andrey Styskin (exresponsable de búsqueda, IA y nube en Yandex) y Matthias Petri (científico alemán proveniente de Amazon AGI), mantiene un índice propietario de más de 100.000 millones de documentos y ya da servicio en producción a varios laboratorios de IA.

🤖 La IA no es solo para leer sobre ella

En la comunidad la aplicamos: automatización, agentes IA y herramientas reales para emprender, no solo para informarte.

👥 Aplicarla en la comunidad

Cómo funciona un SQL con operadores semánticos sobre la web

El servidor MCP de SELECT expone dos herramientas principales: select y generate_html_report. La primera acepta una consulta DuckDB de solo lectura; la segunda toma un brief y los identificadores de los conjuntos de resultados para producir un informe HTML compartible.

El ejemplo del showcase lo deja claro. Para responder «¿qué investigadores de IA se movieron entre laboratorios frontera desde 2025?», SELECT ejecuta algo equivalente a:

SELECT
  SEM_EXTRACT(content, 'researcher'),
  SEM_EXTRACT(content, 'left lab'),
  SEM_EXTRACT(content, 'joined lab'),
  SEM_EXTRACT(content, 'move month')
FROM WEB_SEARCH(8 diverse queries)
WHERE SEM_MATCH(content,
  'named researcher moving between frontier labs, 2025+')

El servidor detecta los operadores semánticos dentro del SELECT parseado, los ejecuta fuera de DuckDB y reemplaza su salida por columnas planas antes de correr el resto del SQL en DuckDB. Las coincidencias exactas del WHERE corren primero, de modo que solo las filas supervivientes llegan a los operadores LLM.

Los operadores que SELECT añade al SQL clásico

La galería documenta siete operadores que extienden SQL más allá del álgebra relacional clásica:

WEB_SEARCH(‘q1’, ‘q2’, …) — lanza todas las consultas en paralelo, mezcla los resultados rankeados y elimina URLs duplicadas.
WEB_FETCH(‘https://…’, …) — descarga las URLs indicadas como Markdown, una fila por página.
SEM_EXTRACT(column, ‘descripción del campo’) — una llamada LLM por fila; devuelve el campo pedido o null si el texto no lo aporta.
SEMEXTRACTALL(column, ‘qué es un valor’) — igual que el anterior, pero devuelve una lista de todos los valores coincidentes.
SEM_MATCH(column, ‘predicado’) — test LLM por fila, útil como WHERE semántico.
SEM_SCORE(column, ‘query’) — puntuación de embedding por fila; se usa con ORDER BY ... DESC LIMIT k.
SEM_NORM(column) — agrupa valores con el mismo significado bajo una clave común, para GROUP BY.

WEBSEARCH y WEBFETCH admiten argumentos por fila, lo que permite concatenar columnas: por ejemplo, WEB_SEARCH(name || ' founding year'). Esta pieza cambia la economía del agente: una sola llamada puede revisar más de 1.000 páginas, filtrarlas con un WHERE exacto sin coste de LLM y extraer campos con una llamada pequeña por fila, según describe Keenable en su showcase.

La galería: 20 informes en una semana

El showcase incluye desde reconstrucciones históricas hasta análisis sectoriales. Entre los más llamativos: una cronología de lanzamientos orbitales 1957–2026, un atlas de Voronoi de los zoológicos más cercanos en EE. UU., un árbol genealógico de fundadores de laboratorios de IA, una cronología de lanzamientos de teclados mecánicos en 10 años, y un reporte de movimientos de investigadores frontera desde 2025.

Lo relevante para entender el estado del producto: cada informe viene acompañado de un link de trayectoria que expone el número exacto de mensajes y consultas SQL necesarias. Los rangos observados van desde 13 mensajes con 9 consultas («U.S. Specialty Coffee Roaster Atlas») hasta 36 mensajes con 18 consultas («Twenty Years of YC Startup-Name Morphology»). La galería incluye además dos agentes en la cadena: un agente de investigación que itera con la herramienta select, y un agente de reporte que corre dentro de generate_html_report en el servidor, armado con las filas de los result sets como dataframes dentro de una sesión Python en sandbox.

Dónde encaja SELECT en el ecosistema MCP

SELECT no llega solo. El estándar MCP (Model Context Protocol) ha pasado de experimento a infraestructura: InfoWorld documentó diez servidores oficiales para conectar LLMs con bases de datos — Snowflake, BigQuery, Aurora MySQL/Postgres, MongoDB, Pinecone, Redis, Neo4j, Elasticsearch y la MCP Toolbox de Google, que conecta con cerca de 30 fuentes. En el último año se han sumado además servidores oficiales de X, GitHub, Slack, Notion, Stripe y Salesforce, según TechCrunch.

Keenable añade una pieza que faltaba: un servidor MCP donde la fuente de datos no es una base corporativa, sino la web abierta, y donde la consulta se expresa como SQL enriquecido con operadores semánticos. El benchmark que la propia empresa liberó la semana pasada, NEEDLE (News, Everyday, Expert, Deep-tail, Legal Evaluation), refuerza la posición competitiva: en la ventana de 7 días cerrada el 28 de agosto de 2026, Keenable registró latencias de 193 ms p50 y 284 ms p95 en su API en tiempo real, frente a 1.876 / 2.955 ms de Exa y 2.767 / 9.381 ms de Bing, según los datos publicados por MarkTechPost.

Qué significa esto para tu startup

Si tu producto depende de un agente que investiga la web, el cuello de botella ya no es el LLM sino la cadena de búsqueda + fetch + extracción. SELECT demuestra que mover el filtrado a SQL nativo reduce drásticamente los tokens consumidos por tarea. Tres acciones concretas que puedes aplicar esta semana:

Audita cuántas llamadas de fetch hace tu agente por tarea. Si la respuesta supera las 20–30 páginas por objetivo, estás pagando LLM donde podrías pagar SQL. Mide el coste por consulta y compáralo con el coste de un endpoint de búsqueda dedicado.
Separa el filtrado exacto del filtrado semántico. El patrón de Keenable — WHERE clásico primero, SEM_MATCH después — protege presupuesto porque solo las filas supervivientes llegan al LLM. Aplica el mismo orden en tu pipeline aunque uses herramientas distintas.
Mide latencia p50 y p95 por endpoint, no solo calidad. Los números de NEEDLE muestran que una API puede ser la más rápida y la mejor rankeada a la vez, y que ambas cosas importan en producción.

Para founders hispanohablantes construyendo agentes B2B, la lección no es «usar Keenable», sino diseñar tu stack asumiendo que el coste de búsqueda será un componente central de tu margen, no un gasto menor escondido bajo el LLM.