Databricks simplifica la orquestación de agentes de IA, pero Postgres ahora asume el riesgo

Databricks simplifica la orquestación de agentes de IA con un diseño de producción que sustituye varios servicios especializados por una única base de datos Lakebase Postgres. El lanzamiento del 22 de julio describe una aplicación de auditoría creada con CLA que procesa documentos en minutos en lugar de horas. Esa mejora es un resultado comunicado por la empresa, pero el cambio arquitectónico es más relevante.

El sistema usa Postgres para colas de tareas, reintentos, programación, atribución de costes y actualizaciones de estado en tiempo real. Databricks afirma que CLA ya no necesita intermediarios externos como Kafka o Redis, programadores separados como Airflow o Temporal, ni una caché dedicada.

Esta consolidación crea una tensión evidente. Los sistemas de orquestación especializados separan responsabilidades y absorben fallos complejos. Databricks sitúa más de esas responsabilidades dentro de una base de datos conocida, reduciendo la infraestructura, pero haciendo que el diseño de la base de datos sea esencial para la fiabilidad de los agentes.

Databricks simplifica la pila en torno a los agentes de larga duración

El cambio inmediato no es un nuevo modelo ni un marco de agentes. Es un patrón de producción que trata a Lakebase como el centro de control del trabajo de los agentes.

Databricks y la firma de servicios profesionales CLA crearon el sistema para auditorías asistidas por agentes. Las auditorías suelen requerir que el personal revise contratos, facturas, informes financieros y documentos de respaldo antes de extraer información estructurada.

La aplicación acepta cargas de PDF a través de una interfaz FastAPI que se ejecuta en Databricks Apps. Almacena esos archivos en Unity Catalog Volumes y escribe cada solicitud de extracción en Lakebase.

Lakebase es el servicio Postgres gestionado de Databricks. Su documentación de Postgres describe escalado automático, bifurcación de bases de datos, réplicas de lectura, restauración instantánea e integración con Unity Catalog.

Dos tablas relacionales constituyen el núcleo operativo. La tabla tasks registra cada trabajo lógico, incluido su estado, prioridad, información de arrendamiento, asignación de agente y resultado final. La tabla task_attempts registra ejecuciones individuales, incluidos identificadores de trabajos, identificadores de trazado y metadatos de costes.

Lakeflow Jobs realiza el trabajo con los documentos. Cada trabajo lee un PDF almacenado, invoca componentes y modelos de procesamiento documental y, después, escribe el resultado en Lakebase. MLflow captura las llamadas a modelos, el uso de tokens, la latencia y la información de costes.

Por tanto, la arquitectura divide responsabilidades sin introducir otra capa de infraestructura. Lakeflow ejecuta el trabajo, mientras Lakebase registra qué debe ejecutarse, qué se está ejecutando y qué ha finalizado.

Databricks afirma que este diseño redujo el proceso de extracción de CLA de horas a minutos sin reducir la calidad. La empresa no ha publicado una referencia independiente, una distribución de cargas de trabajo ni una tasa de error medida que respalde esa afirmación.

Aun así, el lanzamiento va más allá de un diagrama de referencia impreciso. Databricks identifica los patrones de concurrencia, recuperación, limitación, callbacks, observabilidad y facturación necesarios para operar el diseño.

Ese detalle importa porque una tabla de base de datos no se convierte automáticamente en una cola de tareas segura. Una consulta básica puede seleccionar trabajo pendiente, pero varios trabajadores podrían seleccionar la misma fila antes de que alguno actualice su estado.

El diseño también debe recuperar el trabajo tras el fallo de un proceso. Debe impedir que los callbacks duplicados generen resultados duplicados. Debe mantener las solicitudes a modelos dentro de las cuotas externas y permitir que los documentos urgentes eludan el trabajo por lotes.

El diseño de orquestación aborda esos problemas mediante transacciones y funciones consolidadas de Postgres. La novedad no es que Postgres pueda almacenar el estado de los agentes. Los desarrolladores llevan años haciéndolo.

La afirmación más ambiciosa es que Postgres gestionado puede convertirse en la columna vertebral de orquestación para una carga de trabajo de agentes en producción sin Kafka, Redis, Temporal, Airflow ni otro programador.

La verdadera presión recae sobre la infraestructura especializada

Databricks cuestiona la premisa de que toda aplicación de agentes en producción necesita un intermediario, programador, caché y pila de observabilidad separados.

Las demostraciones de agentes suelen ejecutar una solicitud de principio a fin dentro de un único proceso. Los sistemas de producción se comportan de otra forma porque los usuarios envían trabajo de manera concurrente, las llamadas a modelos fallan y las tareas individuales tienen duraciones impredecibles.

Databricks ilustra esa variabilidad con dos tipos de documentos. Una factura de dos páginas puede terminar en segundos, mientras que un contrato de 200 páginas puede requerir varios minutos. Un trabajador no puede asumir que las tareas se completarán en el orden en que se enviaron.

Las cuotas de los modelos añaden otra restricción. Un endpoint puede limitar las solicitudes por segundo, los tokens por minuto o ambos. Enviar cientos de documentos a la vez puede activar limitaciones y reintentos repetidos.

La aplicación también debe responder preguntas operativas. Los equipos necesitan saber qué tarea falló, qué llamada a modelo consumió tokens, cuánto costó cada intento y si un trabajo abandonado debe volver a ejecutarse.

Las arquitecturas tradicionales suelen asignar esas preocupaciones a productos separados. Un intermediario de mensajes transporta tareas. Un motor de flujos de trabajo gestiona la ejecución duradera. Una caché proporciona acceso rápido al estado. Una plataforma de monitorización agrega el estado, la latencia y los costes.

Esa separación puede respaldar flujos de trabajo complejos y grandes organizaciones. También introduce credenciales adicionales, procesos de despliegue, paneles, modos de fallo y código de integración.

Databricks sostiene que esta sobrecarga es desproporcionada para tareas de larga duración que son independientes entre sí. La extracción de documentos encaja en esa descripción porque un contrato normalmente no depende del resultado de otro.

Lakebase cambia el cálculo al situar el estado transaccional junto al resto de la aplicación de Databricks. La misma plataforma proporciona la interfaz, los archivos, los trabajos, los rastros de modelos, los controles de gobernanza y los registros de facturación.

El enfoque presiona a dos grupos. Los equipos de plataforma deben justificar cada servicio adicional que introducen, mientras que los proveedores de orquestación deben demostrar por qué sus garantías especializadas superan a una cola de base de datos bien diseñada.

Esto no vuelve obsoletos a los sistemas dedicados. Amazon, por ejemplo, presenta AgentCore Runtime como un entorno gestionado con aislamiento de sesiones, escalado, identidad y soporte para agentes de larga duración.

Ese enfoque pide a los equipos adoptar un entorno de ejecución específico para agentes. Databricks, en cambio, comienza con una base de datos operativa y la conecta con servicios ya utilizados para cargas de trabajo de datos y aprendizaje automático.

Por tanto, la competencia gira en torno a los límites de la infraestructura. ¿Debería la ejecución de agentes vivir dentro de un entorno de ejecución especializado o debería una base de datos coordinar trabajos ordinarios mediante estado relacional duradero?

Databricks tiene una ventaja estructural entre los clientes existentes. Los equipos que ya usan Lakeflow, MLflow, Unity Catalog y Databricks Apps pueden consolidar sin introducir otro proveedor ni modelo de seguridad.

La misma ventaja crea dependencia de la plataforma. Una empresa que elige el patrón completo vincula la ejecución de tareas, el almacenamiento, la observabilidad, la gobernanza y los informes de costes a los servicios de Databricks.

Para los compradores, «más simple» no puede significar únicamente menos nombres de productos. Debe significar menos tareas operativas, una responsabilidad de fallos más clara, un comportamiento de recuperación aceptable y una estrategia de salida sostenible.

Cuatro patrones de Postgres hacen creíble la cola

La arquitectura funciona porque convierte primitivas de base de datos conocidas en garantías explícitas sobre concurrencia, recuperación, limitación y reintentos.

El primer patrón es la extracción de tareas segura ante concurrencia. Un trabajador selecciona filas aptas con FOR UPDATE SKIP LOCKED, que bloquea las filas seleccionadas y permite que otros trabajadores las omitan.

PostgreSQL documenta SKIP LOCKED como útil para evitar la contención cuando varios consumidores acceden a una tabla similar a una cola. También advierte que la opción presenta una vista inconsistente, lo que la hace inadecuada para consultas de propósito general.

Esa distinción resume la fortaleza del diseño. La tabla de tareas no se utiliza para informes arbitrarios durante la extracción de tareas. Los trabajadores necesitan reclamaciones exclusivas sobre trabajos disponibles sin esperar detrás del bloqueo de otro trabajador.

La consulta ordena el trabajo por prioridad descendente y hora de creación. Los trabajos de mayor prioridad se ejecutan primero, mientras que los trabajos con la misma prioridad mantienen el orden de entrada, primero en salir, primero.

El segundo patrón utiliza arrendamientos con vencimiento. Cuando un trabajador reclama una tarea, registra una hora de expiración del arrendamiento en lugar de asignar la propiedad para siempre.

Un proceso de barrido periódico devuelve las tareas expiradas a la cola. Si un trabajador desaparece debido a una expulsión, un despliegue, un error de memoria o un fallo de proceso, otro trabajador puede recuperar su trabajo en cuestión de minutos.

Los arrendamientos resuelven el trabajo abandonado, pero también introducen un requisito. La aplicación debe elegir períodos de expiración que superen las duraciones normales de las tareas o renovar los arrendamientos mientras el trabajo continúa.

Un arrendamiento que expira demasiado pronto puede hacer que un trabajo sano parezca abandonado. Un arrendamiento que dura demasiado aumenta el tiempo de recuperación tras un fallo real.

El tercer patrón controla el consumo de modelos antes del envío. El orquestador admite un límite de tareas concurrentes, un presupuesto de tokens proyectado o una combinación de ambos.

Un límite de concurrencia cuenta las filas marcadas actualmente como en procesamiento. Como la base de datos mantiene ese recuento, la restricción sigue siendo visible entre reinicios de trabajadores y múltiples réplicas del orquestador.

Un presupuesto de tokens estima el consumo de cada tarea en curso. El orquestador envía otro trabajo solo cuando sus tokens proyectados encajan dentro del límite configurado.

Cuando ambos controles están habilitados, prevalece la restricción más estricta. Esto se adapta a cargas de trabajo que alternan entre muchas facturas pequeñas y unos pocos contratos con un uso intensivo de tokens.

El cuarto patrón hace que los callbacks sean idempotentes. La idempotencia significa que repetir la misma solicitud produce el mismo resultado efectivo en lugar de aplicar el cambio dos veces.

Las interrupciones de red y los proxies pueden hacer que un callback llegue más de una vez. Databricks acepta callbacks para trabajos en procesamiento o reenviados a la cola, mientras trata los estados ya completados como operaciones sin efecto.

Ese comportamiento reduce el riesgo de procesamiento o facturación duplicados. Sin embargo, depende de identidades de tarea estables, transiciones de estado cuidadosas y un límite de transacción que incluya la actualización del resultado.

En conjunto, los cuatro patrones crean una cola creíble. Las transacciones impiden reclamaciones concurrentes, los arrendamientos recuperan trabajo abandonado, los presupuestos restringen el envío y los callbacks idempotentes toleran la reentrega.

Así es como Databricks simplifica una cola de tareas de agentes sin afirmar que un par de tablas sea suficiente por sí solo. El código de la aplicación sigue implementando la política que rige cada transición.

El mecanismo se adapta a trabajos con estructuras de dependencia relativamente simples. Se vuelve menos atractivo cuando el trabajo requiere flujos de trabajo anidados, acciones compensatorias, aprobaciones humanas o largas cadenas de eventos temporizados.

Un motor de flujos de trabajo dedicado suele representar esas relaciones directamente. Con una cola de base de datos, los desarrolladores deben modelarlas como tablas, transiciones de estado y lógica de aplicación.

Esa compensación debería determinar la adopción. Los equipos deberían seleccionar este patrón porque su flujo de trabajo es lo bastante sencillo, no porque Postgres pueda representar teóricamente cualquier flujo de trabajo posible.

Una base de datos conecta estado, visibilidad y costes

La parte más distintiva del diseño no es la gestión de colas. Es la decisión de derivar la visibilidad operativa y la atribución de costes de los mismos registros de tareas.

Los operadores necesitan más que una etiqueta de completada o fallida. El panel de CLA muestra recuentos de tareas en cola, en procesamiento, completadas, fallidas y canceladas.

También muestra tokens de entrada y salida, costes de modelo, costes de cómputo, tiempo de respuesta mediano y nivel de confianza por documento. Los filtros abarcan rangos de tiempo, estados de tarea y agentes individuales.

La latencia mediana es una elección útil para esta carga de trabajo. El retroceso de reintentos y la saturación de colas pueden generar retrasos extremos que distorsionan un promedio simple.

Postgres LISTEN/NOTIFY proporciona el mecanismo de actualización en tiempo real. Un desencadenador de base de datos publica un evento cuando cambia el estado de una tarea, y el backend de la aplicación mantiene una conexión de escucha.

El backend distribuye esos eventos a los navegadores mediante Server-Sent Events. SSE es un flujo HTTP unidireccional que permite a un servidor enviar actualizaciones a través de una conexión persistente con el navegador.

Databricks afirma que los cambios en el panel suelen aparecer en aproximadamente un segundo. El diseño no requiere Redis, un servidor WebSocket ni un bus de mensajes para esta ruta.

El sistema conserva el sondeo como alternativa permanente. Los navegadores solicitan datos actualizados cada diez segundos cuando el streaming deja de estar disponible.

Esta alternativa es importante porque los proxies de entrada en la nube pueden interrumpir un flujo sin producir un error claro en el navegador. Un panel que depende solo de eventos push puede quedar desactualizado de forma silenciosa.

El panel combina información con distintas velocidades de actualización. El estado de Postgres es inmediato, mientras que los datos de trazas de MLflow llegan en menos de un segundo, según Databricks.

Las consultas de facturación pueden tardar decenas de segundos. Por ello, la aplicación ejecuta consultas rápidas de estado durante las actualizaciones normales y reserva las consultas de facturación más lentas para las acciones del usuario.

La atribución de costes requiere otra capa de filtrado. Las tablas de facturación de Databricks incluyen actividad de toda la cuenta, por lo que una consulta sin filtrar combinaría el gasto de trabajos y aplicaciones no relacionados.

El orquestador registra las ejecuciones específicas de Databricks Job asignadas a sus tareas. Las consultas de facturación filtran entonces la actividad de la cuenta según esos identificadores.

Esto permite que un almacén SQL respalde varias aplicaciones mientras cada panel muestra solo su propia carga de trabajo. Los operadores pueden acotar aún más los resultados por estado, agente o fecha.

El diseño permite responder preguntas prácticas que la monitorización genérica suele ocultar. Un equipo puede examinar el coste de las tareas fallidas durante siete días o comparar el gasto mediano entre agentes.

Esta conexión entre la identidad de la tarea y el coste es relevante más allá de la auditoría. Las aplicaciones de IA suelen perder la relación entre una solicitud de usuario, los intentos que desencadenó y la factura de modelo resultante.

Un registro de tareas duradero proporciona a los equipos una clave de unión estable. Conecta la intención de negocio, el historial de ejecución, las trazas de modelo, la actividad de cómputo y el resultado final.

Los equipos intensivos en conocimiento afrontan un problema relacionado después de la ejecución. Necesitan preservar los documentos, las decisiones y los resultados que rodean el trabajo automatizado en un contexto consultable.

Una base de conocimiento de ingeniería estructurada puede complementar las trazas de ejecución al conservar el contexto humano detrás de incidentes y decisiones de diseño.

Por tanto, el valor del patrón Lakebase va más allá de reducir servicios. Crea una narrativa operativa única para cada tarea, desde el envío hasta los reintentos, el coste y el resultado.

Una infraestructura más simple traslada el riesgo al diseño de la base de datos

Databricks reduce la sobrecarga de integración, pero no elimina la complejidad de los sistemas distribuidos. Reubica esa complejidad en esquemas, transacciones, arrendamientos y código de aplicación.

La expresión «sin infraestructura externa» merece una lectura cuidadosa. La aplicación sigue dependiendo de varios servicios de Databricks, entre ellos Apps, Lakeflow Jobs, MLflow, Unity Catalog Volumes y Lakebase.

La simplificación se produce dentro de una plataforma gestionada. No reduce la arquitectura a un único proceso ni a un único servicio.

Esta distinción importa durante una interrupción. Una cola de Lakebase puede seguir siendo duradera mientras el servicio de trabajos no está disponible, pero la aplicación aún necesita un comportamiento probado para el despacho retrasado y la recuperación.

Los equipos también deben establecer qué ocurre cuando el callback tiene éxito, pero falla una operación circundante. La idempotencia protege frente a entregas repetidas solo cuando cada efecto secundario utiliza identificadores y límites coherentes.

El control de límites de tasa también contiene incertidumbre. Un presupuesto de tokens proyectado depende de estimar el consumo de documentos antes de que el modelo los procese.

Las estimaciones pueden infravalorar documentos complejos o sobrevalorar documentos simples. La subestimación puede activar la limitación del proveedor, mientras que la sobreestimación puede dejar sin usar capacidad disponible del modelo.

El diseño publicado no ofrece resultados de rendimiento, límites de profundidad de cola, tasas de fallo, carga de base de datos ni datos operativos comparativos. Tampoco compara directamente la implementación con un motor de flujos de trabajo dedicado.

Databricks informa de que el tiempo de extracción se redujo de horas a minutos. Sin embargo, no divulga la muestra de documentos, el proceso de revisión humana, la medida de precisión, la configuración del modelo ni el flujo de trabajo de referencia.

Los lectores deberían considerar el resultado como el testimonio de un cliente en producción, no como un benchmark controlado. La arquitectura puede ser útil incluso sin demostrar mejoras de rendimiento universales.

Postgres puede convertirse en un punto de contención. Las extracciones frecuentes de la cola, actualizaciones de estado, cálculos de presupuesto de tokens, lecturas del panel y uniones de facturación proceden de registros operativos relacionados.

Lakebase ofrece cómputo con escalado automático y almacenamiento duradero independiente. Estas funciones pueden reducir la planificación de capacidad, pero el escalado automático no elimina las consultas ineficientes ni la contención por bloqueos.

Las tablas de colas también crecen de forma distinta a las tablas de aplicación convencionales. El historial de intentos se acumula, los registros completados siguen siendo valiosos para auditorías y los índices deben respaldar tanto la programación en tiempo real como el análisis histórico.

Por ello, las políticas de retención y archivado forman parte del diseño de la cola. Sin ellas, las consultas operativas pueden competir gradualmente con las cargas de trabajo de informes.

La seguridad merece la misma atención. La tabla de tareas puede contener ubicaciones de documentos, resultados extraídos, puntuaciones de confianza, asignaciones de agentes e identificadores de ejecución.

Databricks afirma que Unity Catalog proporciona identidad y permisos compartidos. Los equipos aún deben aplicar acceso de mínimo privilegio, proteger los endpoints de webhook y decidir qué operadores pueden inspeccionar resultados sensibles.

La ramificación de bases de datos puede ayudar a reproducir defectos en un entorno aislado. También puede copiar datos operativos sensibles, lo que exige enmascaramiento y controles de acceso adecuados para la carga de trabajo de auditoría.

La cuestión competitiva más amplia sigue sin resolverse. AlloyDB AI de Google también presenta infraestructura compatible con PostgreSQL como base para aplicaciones de IA, incluidas las búsquedas vectoriales e híbridas.

AWS adopta una vía más específica para agentes con servicios gestionados de ejecución, memoria, identidad y orquestación. Los sistemas de flujos de trabajo dedicados siguen centrados en la ejecución duradera a través de grafos de procesos complejos.

Databricks ha demostrado que Postgres puede cubrir un terreno intermedio significativo. No ha demostrado que la orquestación centrada en bases de datos deba sustituir a esos sistemas en todas las cargas de trabajo de agentes.

El caso de adopción más sólido implica tareas independientes y de larga duración sobre una plataforma Databricks existente. El más débil implica flujos de trabajo entre sistemas con dependencias complejas y requisitos estrictos de portabilidad.

Tres señales pondrán a prueba el caso de la orquestación con Lakebase

La próxima prueba es si la arquitectura de CLA se convierte en un patrón de producción repetible, en lugar de una implementación de cliente cuidadosamente diseñada.

La primera señal es la adopción más allá de la extracción de documentos. Databricks debería publicar ejemplos que involucren agentes de programación, operaciones de atención al cliente, corrección de datos o flujos de trabajo de investigación.

Estas cargas de trabajo pondrían a prueba distintos tamaños de tarea, estructuras de dependencias, permisos de herramientas y requisitos de aprobación humana. Resultados similares reforzarían la afirmación de que Lakebase es un almacén de estado general para agentes.

Si los ejemplos futuros siguen limitándose a trabajos de documentos independientes, el diseño seguirá siendo útil. Su alcance práctico simplemente será más limitado de lo que sugiere el lenguaje más amplio sobre orquestación.

La segunda señal son los datos operativos comparativos. Los equipos necesitan rendimiento de cola, tiempos de recuperación, utilización de base de datos, tasas de fallo y latencia de despacho bajo carga sostenida.

Sería especialmente útil una comparación con trabajadores respaldados por Redis o con un motor de flujos de trabajo duradero. Podría mostrar cuándo la reducción del trabajo de integración compensa la lógica adicional de máquina de estados dentro de la aplicación.

Los datos transparentes reforzarían el argumento de simplificación de Databricks. La ausencia de dichos datos dejaría a los compradores dependiendo de descripciones de arquitectura y resultados comunicados por clientes.

La tercera señal es la conversión en producto. El patrón actual depende de código de aplicación que implementa bloqueos, arrendamientos, limitación, callbacks, streaming del panel y atribución de facturación.

Databricks podría convertir partes de este diseño en plantillas, componentes gestionados, bibliotecas de referencia o capacidades integradas de Lakebase. Eso reduciría la cantidad de código crítico para la corrección que mantiene cada cliente.

La conversión en producto también revelaría cómo Databricks define el límite entre las funciones de base de datos y las funciones de flujo de trabajo. Una capa gestionada mayor competiría más directamente con los entornos de ejecución de agentes y las plataformas de orquestación.

Los equipos que evalúan el patrón deberían comenzar por la forma de su flujo de trabajo. Las tareas independientes con estados terminales claros encajan bien con el diseño de CLA.

Después deberían probar el comportamiento ante fallos antes de optimizar el rendimiento. Detengan trabajadores, retrasen callbacks, dupliquen solicitudes, agoten las cuotas del modelo e interrumpan los flujos del panel.

Por último, comparen la carga operativa con una alternativa especializada. Cuenten los servicios eliminados, pero también las transiciones personalizadas, reglas de recuperación, pruebas y manuales operativos añadidos.

Databricks simplifica la infraestructura visible alrededor de la orquestación de agentes, y Lakebase aporta al diseño un núcleo transaccional creíble. La pregunta abierta es si su aplicación es lo bastante sencilla para que esa consolidación siga siendo simple.

Si lo es, una cola centrada en la base de datos puede acortar el camino desde el prototipo hasta un sistema de producción observable. Si no lo es, el broker o motor de flujos de trabajo ausente reaparecerá como código de aplicación. El siguiente paso adecuado es un piloto centrado en fallos con tamaños de tarea reales, cuotas reales y objetivos de recuperación reales.