Databricks y el futuro de la empresa: del lakehouse a un sistema de registro para agentes de IA

Aviso: el texto recibido está cortado a mitad del artículo, justo cuando empieza a hablar de Herbert Simon y la naturaleza de la empresa. Este resumen cubre solo lo que aparece en el material. Las partes sobre cómo cambia la empresa con agentes y sobre en qué consistirá el trabajo diario no llegan a leerse, y no las reconstruyo.

El artículo es de Ben Horowitz y Michael McGuiness, publicado en el sitio de Andreessen Horowitz el 27 de octubre de 2026. Sostiene que una de las cinco cuestiones que más cambiarán en los próximos veinte años es qué hace una persona en el trabajo durante todo el día. Ve dos avances inminentes. El primero es la automatización agéntica: describes una tarea que hoy se hace y se automatiza. El segundo es que los empleados cobren iniciativa, porque quienes están más cerca del problema pueden investigar y actuar sin esperar a que la información y la autoridad recorran capas de jerarquía.

Los autores añaden una condición: las organizaciones tienen que ser capaces de evolucionar hacia esa forma de trabajar. Una parte enorme del trabajo diario de alguien depende del sistema de registro y de decisión de su empresa. Ese sistema, a su vez, depende de la tecnología de bases de datos que use y de lo que esta permita. Ahí entra Databricks. El texto la presenta como quizá la historia más discreta de Silicon Valley, con un run rate superior a 7.000 millones de dólares y un crecimiento del 80 % interanual. Según el artículo, hace tres años cada interacción en Databricks involucraba a un humano. Hoy la plataforma recibe más consultas de agentes que de personas, y los agentes lanzan más de 17 millones de bases de datos al día.

El artículo anuncia cuatro bloques. Primero, qué hace Databricks y por qué lakehouse y Lakebase son un avance arquitectónico. Segundo, qué es un sistema de registro y por qué los agentes necesitan uno nuevo. Tercero, qué es una empresa y cómo cambia si los agentes superan a las personas en proporción de 1000 a 1. Cuarto, en qué trabajarán las personas. La tesis de fondo es que la promesa habitual, que cualquiera tendrá poderes de ingeniero de software, quizá no sea la correcta. Podría ser más bien que todos serán gerentes. Los autores lo conectan con La revolución gerencial de James Burnham, que hace 85 años describió cómo la tecnología de la información y la complejidad organizativa centralizaron las decisiones en una clase de directivos profesionales. Ahora, dicen, los profesionales de primera línea recuperan responsabilidad.

La primera sección repasa la historia técnica como cuatro curvas en S apiladas: Spark, Lakehouse, Lakebase y los agentes. En 2009 Ali Ghodsi era investigador visitante en UC Berkeley. El marco dominante era Hadoop, que repartía el procesamiento entre miles de servidores baratos. Su defecto era que guardaba en disco los resultados de cada ronda antes de empezar la siguiente. Eso facilitaba recuperarse de fallos, pero era muy lento para cargas iterativas como el aprendizaje automático. Matei Zaharia, doctorando en Berkeley, escribió la primera versión de Apache Spark. Spark mantenía en memoria los datos reutilizados entre rondas sin perder tolerancia a fallos, y las cargas repetitivas iban hasta diez veces más rápido. El laboratorio lo liberó en 2010 y, tres años después, Ghodsi, Zaharia y otros cinco investigadores fundaron Databricks para ocultar la complejidad de la infraestructura distribuida tras una plataforma empresarial.

El segundo problema era dónde vivían los datos. Los data warehouses guardaban registros estructurados y fiables, consultables en SQL, que alimentaban los dashboards y los informes trimestrales. Los data lakes ofrecían almacenamiento barato para todo lo demás, como documentos, imágenes, grabaciones y logs. Como nada se verificaba al entrar, les llamaban pantanos de datos. Los ingenieros y científicos de datos vivían en el lago con Python y los analistas en el almacén con SQL, y cada vez que uno necesitaba los datos del otro había que construir una canalización. El resultado eran copias, permisos y definiciones en conflicto.

A finales de la década de 2010, Databricks, Uber y Netflix llegaron por separado a la misma solución. Sus proyectos (Delta Lake, Hudi e Iceberg) añadían una capa de tablas sobre los ficheros del lago, con garantías propias de un almacén: actualizaciones de todo o nada, gestión de esquemas e historial versionado. En 2020 Databricks acuñó el lakehouse, que combina el almacenamiento barato y flexible del lago con la fiabilidad y el rendimiento de consulta del almacén. Según el artículo, el Lakehouse supera hoy los 1.500 millones de dólares de run rate, con un crecimiento de más del 100 % interanual. El texto cita además una entrada de blog de enero de 2020 de Werner Vogels, CTO de Amazon. Vogels defendía que un lago permite importar datos en cualquier formato y evita los compromisos del ETL, y que la IA prospera con conjuntos de datos grandes y diversos.

Quedaba una brecha. La base de datos operacional, la que gestiona transacciones en tiempo real como pagos o inicios de sesión, seguía unida al lakehouse mediante frágiles canalizaciones. Además, el cómputo y el almacenamiento iban juntos y los datos quedaban atrapados en formatos propietarios. En 2025 Databricks compró Neon, una empresa de Postgres sin servidor cuyas bases de datos ya las creaban sobre todo agentes de IA. De ahí salió Lakebase, que aplica la misma idea del lakehouse a la base operacional. Separa almacenamiento y cómputo, de modo que los datos se guardan baratos en el lago mientras el cómputo escala según la demanda. Los cambios en la base quedan disponibles para analistas, ingenieros y agentes sin canalizaciones. Databricks llama LTAP a esta unión de transacciones y analítica. La separación hace que la base de datos se comporte más como código. Incluso bases de petabytes se duplican en segundos porque solo se copian los cambios, y un agente puede crear una rama aislada, experimentar y descartarla. Según el artículo, Lakebase se lanzó el año pasado y ya supera los 100 millones de dólares de run rate, con los agentes como sus usuarios más prolíficos. Ghodsi cree que a largo plazo será un mercado mayor que el actual de bases de datos. La visión es pasar de miles de empleados que leen y escriben en unas pocas bases gestionadas por un equipo central a miles de bases de datos en las que escriben y leen millones de agentes.

La segunda parte arranca con el Data + AI Summit de junio, donde Ghodsi habló ante unas 30.000 personas. Preguntó quién creía que la inteligencia artificial general había llegado y contó, según el texto, un diez por ciento de manos. Él afirmó que la AGI ya está aquí, y lo apoyó en que los modelos de frontera resuelven más de la mitad de las preguntas de Humanity's Last Exam, 2.500 preguntas escritas por expertos de más de cien campos. El artículo añade que ChatGPT en 2022 manejaba tareas de programación de unos treinta segundos de trabajo humano, y que los agentes actuales completan tareas que a un ingeniero cualificado le llevan una jornada. Según el texto, METR, un laboratorio independiente de evaluación, ha medido que la duración de las tareas que un agente completa por su cuenta se duplica aproximadamente cada siete meses. Si eso se mantiene hasta principios de la década de 2030, los agentes podrían hacer tareas que a una persona le llevarían años.

Aun así, dentro de la mayoría de las empresas la IA todavía no goza de confianza para actualizar registros en Salesforce. Para Ghodsi, la IA no tiene un problema de inteligencia sino de contexto. Su respuesta es lo que llama un sistema de registro para agentes (SORA). El artículo lo relaciona con la idea de ontología que defiende Alex Karp, de Palantir. Toda empresa tiene una ontología: un modelo de trabajo de qué existe, cómo se relaciona, qué significan sus palabras y qué fuente manda cuando dos discrepan. Gran parte vive solo en la cabeza de empleados veteranos y nunca está terminada. La autoridad (quién decide) y la evaluación (qué decisiones fueron acertadas) tampoco están escritas. El ejemplo del texto es el vicepresidente de ventas que sabe que un acuerdo importante se ha estancado o que el 90 % de cierto comercial equivale a un 50 %. Para que los agentes actúen con autonomía, mucho de eso tendrá que pasar al sistema de registro, y Databricks apuesta a que el lakehouse es su sede natural porque ahí ya está el resto de los datos.

Los empleados interactúan con ese sistema mediante Genie, la interfaz en lenguaje natural lanzada en 2024, con la que se pueden hacer preguntas a los datos y, cada vez más, crear agentes. El sistema debe responder continuamente cuatro preguntas. ¿Qué es verdad? El estado lo guardan Lakehouse y Lakebase. ¿Qué significa? Genie Ontology construye de forma continua un grafo de lo que sabe la organización, y un algoritmo llamado OntoRank, guiño al PageRank de Google, clasifica qué conocimiento es autoritativo según quién creó una definición, cuán usada es y cuándo cambió. En las pruebas de Databricks, anclar a un agente en la ontología subió la precisión de las respuestas de aproximadamente el 50 % al 84,5 %. ¿Qué está permitido? El modelo clásico de un login por empleado se rompe cuando cada uno lanza cientos de agentes al día, y Unity Gateway da a cada modelo, agente y herramienta una identidad, un presupuesto y límites, y registra cada acción. ¿Funcionó? Los equipos de negocio construyen agentes en Genie y los ingenieros, agentes más personalizados en Agent Bricks. En ambos casos los equipos escriben sus propios exámenes, es decir, los resultados aceptables y los errores inadmisibles, y optimizan cada agente frente a esa definición de lo que es bueno.

El texto sitúa esto en una historia de disputas por el sistema de registro en cada cambio de plataforma. IBM dominó la era del mainframe, Oracle y SAP la del cliente-servidor, y Salesforce, Workday y ServiceNow construyeron los sistemas SaaS de ventas, RR. HH. y TI. Los agentes son el siguiente salto, pero los autores consideran más importante la pregunta de cómo cambiarán la empresa misma que la de qué proveedor gane.

El material termina al empezar la sección sobre la naturaleza de la empresa. Recoge el artículo de 1937 de Ronald Coase, que explicaba la existencia de las empresas por los costes de transacción: encontrar a la persona adecuada, negociar y supervisar cuesta. La empresa sustituye parte de esas transacciones por una relación más abierta dirigida por directivos, pero organizar dentro también cuesta. Por eso crece hasta que el coste de organizar una transacción internamente iguala al de comprarla en el mercado. El texto cita después a Herbert Simon, que cuarenta años más tarde observó que centralizar la memoria de un negocio descentralizaba sus decisiones, y se corta ahí.

Como lectura crítica, conviene recordar que el artículo viene de un inversor en el sector y que casi todas las cifras (run rates, crecimiento, precisión del 84,5 %, 17 millones de bases creadas por agentes) proceden de la propia Databricks o del relato del autor. En el texto recibido no aparece verificación independiente.