En una entrevista doble inusual, los líderes técnicos de Databricks Matei Zaharia y Reynold Xin hablaron en el Data + AI Summit 2026 con Latent Space sobre lo que tomará que cada empresa construya su propia "nube de agentes". La conversación abrió en el contexto del post de Satya Nadella sobre frontier ecosystems y la valorización reciente de Databricks, que ronda los 175 mil millones de dólares.

¿Qué es Omnigent y por qué importa?

Desde abrir el código de la capa que va por encima de los agentes de programación hasta repensar las bases de datos para la era de los agentes, los cofundadores de Databricks están empujando a la compañía más allá del lakehouse hacia un sistema operativo completo para datos e IA. En el episodio, Matei y Reynold desempacaron junto a Shawn "swyx" Wang varias piezas centrales: Omnigent, LTAP, Lakebase, seguridad de agentes, formatos abiertos, Mosaic y por qué las bases de datos importan más que nunca cuando los agentes empiezan a hacer trabajo real.

El punto más profundo del episodio es Omnigent: el meta-harness open source de Databricks para combinar, controlar y compartir agentes entre Claude Code, Codex, Cursor, Pi, agentes a medida y herramientas internas. Matei explica por qué los agentes de programación y los agentes empresariales tropiezan con los mismos problemas: portabilidad, colaboración, historial de sesiones, seguridad, control de gasto y la necesidad de una API común sobre cada harness.

Después, Reynold recorre el sueño de Databricks con bases de datos: por qué CDC (change data capture) es tan frágil que en la firma bromean diciendo que significa "continuous data corruption", por qué HTAP fue el santo grial de la ingeniería de bases de datos, y por qué en Databricks creen que LTAP obtiene la mayoría de los beneficios al unificar la capa de almacenamiento en vez de colapsar todos los motores de consulta. La entrevista también cubre la escala de infraestructura de Databricks, la cultura detrás del prototipado rápido, la diferencia entre clientes tech y clientes enterprise, el duelo Databricks vs Snowflake, la pregunta de si las bases de datos vectoriales debieron existir alguna vez, la estrategia Mosaic, Genie, AI Runtime, el fine-tuning con RL y la tesis de que el software tradicional se reescribe una vez que los datos están en el lugar correcto y los agentes se ubican encima.

El giro: de big data a contexto para agentes

Databricks nació como una compañía para la era del big data. La aparición de Spark en el AMPLab de Berkeley, que más tarde se transformó en el producto Lakehouse, convenció a las empresas de que no necesitaban un data lake, un warehouse, una plataforma ML y una capa de gobernanza por separado. Solo necesitaban una fundación abierta donde todos sus datos pudieran vivir y ser razonados.

Desde entonces mucho cambió, pero los datos solo se volvieron más importantes. Los datos ya no son algo que uno guarda y analiza ad hoc, son el contexto necesario que los agentes precisan para actuar. El encuadre pasó de "dónde guardamos todos nuestros datos?" a "cómo exponemos la rebanada correcta de estado, historia, permisos y lógica de negocio a un sistema de IA en el momento exacto en que está trabajando?".

Si el rendimiento de los modelos de frontera se vuelve un commodity, la ventaja durable pasa a ser el contexto específico de cada empresa que los rodea: datos propietarios, accesos gobernados, estado operativo, logs transaccionales, flujos de trabajo y feedback loops. Lo que deja a Databricks bien posicionada.

Recién salida del Data + AI Summit 2026, la compañía se mueve igual de rápido para mantenerse al día y acaba de anunciar Genie One, Omnigent, LTAP y más, dando una pista de la misión central de su nueva etapa: Databricks intenta convertirse en el sistema operativo para los agentes empresariales.

Los modelos se vuelven suficientemente buenos, pero los agentes solo son útiles si tienen el contexto correcto, los permisos, la memoria, el estado, los controles de costo y el acceso a datos de negocio en vivo. En el fondo, el problema de obtener significativamente mejor rendimiento de los modelos en producción es un problema de sistemas, justo el tipo de problema para el que la gente que viene de datos está preparada.

Lo que toca el episodio

  • Por qué Databricks construyó Omnigent como meta-harness sobre los agentes de IA existentes.
  • Por qué los agentes de programación y los agentes empresariales a medida necesitan la misma infraestructura.
  • La API común para sesiones de agentes, archivos, streams, llamadas a tools y cancelación.
  • Por qué importan las sesiones persistentes, los cloud sandboxes, el compartir, la búsqueda y la colaboración.
  • Por qué Databricks abrió el código de Omnigent en lugar de mantenerlo propietario.
  • El uso interno de agentes en Databricks, los cloud sandboxes y los flujos de codificación.
  • La escala de Databricks: entre 50 y 60 millones de máquinas virtuales por día y exabytes antes del desayuno.
  • Por qué la seguridad de agentes necesita políticas contextuales y con estado.
  • Cómo un agente podría leer documentos confidenciales, instalar un paquete npm comprometido y filtrar datos.
  • Por qué el control de gasto importa cuando un agente puede quemar 500 dólares leyendo logs.
  • Oportunidades de startups en torno a analítica, calidad, skills y gasto de agentes de codificación.
  • LTAP, Lakebase y por qué Databricks quiere repensar el stack de base de datos.
  • OLTP vs OLAP, CDC y por qué los pipelines de datos se rompen a las 3 de la mañana.
  • Por qué HTAP fue históricamente el santo grial de la ingeniería de bases de datos.
  • Por qué en Databricks creen que LTAP es "HTAP bien hecho".
  • Cómo escribir datos transaccionales en formatos columnares cambia la analítica.
  • Por qué los agentes necesitan contexto operativo en vivo desde las bases de datos, no solo telemetría.
  • Cómo Databricks prototipa sistemas estratégicos sin proceso interminable.
  • Clientes enterprise vs clientes tech, gobernanza, procurement y cultura DIY.
  • El riesgo del "síndrome del segundo sistema" al reescribir un motor de base de datos.
  • Construir un motor de base de datos desde una década de trazas y quadrillones de data points.
  • Por qué las bases de datos vectoriales nunca debieron ser una categoría separada.
  • Por qué los formatos abiertos y la IA cambiaron la carrera con Snowflake.
  • La historia de Mosaic, DBRX, Genie, modelos de parseo de documentos y entrenamiento de modelos especializados.
  • Por qué la personalización de modelos y el fine-tuning con RL podrían volverse mainstream.
  • Por qué "llevar los datos al lugar correcto, poner un agente encima" podría reescribir el software tradicional.

Los perfiles de los invitados y los enlaces: