Databricks simplifica a orquestração de agentes de IA, mas o Postgres agora assume o risco

A Databricks simplifica a orquestração de agentes de IA com um design de produção que substitui vários serviços especializados por um único banco de dados Lakebase Postgres. O lançamento de 22 de julho descreve uma aplicação de auditoria criada com a CLA que processa documentos em minutos, em vez de horas. Essa melhoria é um resultado reportado pela empresa, mas a mudança arquitetural é mais relevante.

O sistema usa o Postgres para filas de tarefas, novas tentativas, agendamento, atribuição de custos e atualizações de status em tempo real. A Databricks afirma que a CLA não precisa mais de brokers externos, como Kafka ou Redis, agendadores separados, como Airflow ou Temporal, nem de um cache dedicado.

Essa consolidação cria um conflito claro. Sistemas especializados de orquestração separam responsabilidades e absorvem falhas complexas. A Databricks coloca mais dessas responsabilidades em um banco de dados familiar, reduzindo a infraestrutura, mas tornando o design do banco de dados central para a confiabilidade dos agentes.

Databricks simplifica a pilha em torno de agentes de longa execução

A mudança imediata não é um novo modelo ou framework de agentes. É um padrão de produção que trata o Lakebase como centro de controle do trabalho dos agentes.

A Databricks e a empresa de serviços profissionais CLA criaram o sistema para auditoria assistida por agentes. Auditorias frequentemente exigem que equipes revisem contratos, faturas, registros financeiros e documentos de apoio antes de extrair informações estruturadas.

A aplicação aceita uploads de PDF por meio de uma interface FastAPI executada no Databricks Apps. Ela armazena esses arquivos em Unity Catalog Volumes e grava cada solicitação de extração no Lakebase.

Lakebase é o serviço gerenciado de Postgres da Databricks. Sua documentação do Postgres descreve escalonamento automático, ramificação de bancos de dados, réplicas de leitura, restauração instantânea e integração com o Unity Catalog.

Duas tabelas relacionais formam o núcleo operacional. A tabela tasks registra cada trabalho lógico, incluindo status, prioridade, informações de lease, atribuição de agente e saída final. A tabela task_attempts registra execuções individuais, incluindo identificadores de trabalho, identificadores de rastreamento e metadados de custo.

Lakeflow Jobs executa o trabalho com documentos. Cada trabalho lê um PDF armazenado, invoca componentes e modelos de processamento de documentos e, em seguida, grava seu resultado de volta no Lakebase. O MLflow captura chamadas de modelo, uso de tokens, latência e informações de custo.

Assim, a arquitetura divide responsabilidades sem introduzir outra camada de infraestrutura. O Lakeflow executa o trabalho, enquanto o Lakebase registra o que deve ser executado, o que está em execução e o que foi concluído.

A Databricks afirma que esse design reduziu o processo de extração da CLA de horas para minutos sem reduzir a qualidade. A empresa não publicou um benchmark independente, distribuição de carga de trabalho ou taxa de erro medida que sustente essa afirmação.

Ainda assim, o lançamento vai além de um diagrama de referência genérico. A Databricks identifica os padrões de concorrência, recuperação, limitação, callbacks, observabilidade e cobrança necessários para operar o design.

Esse detalhe é importante porque uma tabela de banco de dados não se transforma automaticamente em uma fila de tarefas segura. Uma consulta básica pode selecionar trabalho pendente, mas vários workers podem selecionar a mesma linha antes que algum deles atualize seu status.

O design também precisa recuperar o trabalho após a falha de um processo. Precisa impedir que callbacks duplicados gerem resultados duplicados. Deve manter as solicitações ao modelo dentro de cotas externas e permitir que documentos urgentes ultrapassem o trabalho em massa.

O design de orquestração trata desses problemas com transações e recursos consolidados do Postgres. A novidade não é que o Postgres pode armazenar o estado de agentes. Desenvolvedores fazem isso há anos.

A alegação mais forte é que o Postgres gerenciado pode se tornar a espinha dorsal da orquestração de uma carga de trabalho de agentes em produção sem Kafka, Redis, Temporal, Airflow ou outro agendador.

A pressão real recai sobre a infraestrutura especializada

A Databricks está questionando a premissa de que toda aplicação de agentes em produção precisa de um broker, agendador, cache e pilha de observabilidade separados.

Demonstrações de agentes costumam executar uma solicitação do início ao fim em um único processo. Sistemas de produção se comportam de maneira diferente porque os usuários enviam trabalho simultaneamente, as chamadas de modelo falham e tarefas individuais têm durações imprevisíveis.

A Databricks ilustra essa variação com dois tipos de documento. Uma fatura de duas páginas pode ser concluída em segundos, enquanto um contrato de 200 páginas pode exigir vários minutos. Um worker não pode presumir que as tarefas serão concluídas na ordem de envio.

As cotas de modelo adicionam outra restrição. Um endpoint pode limitar solicitações por segundo, tokens por minuto ou ambos. Despachar centenas de documentos de uma vez pode acionar limitação e novas tentativas repetidas.

A aplicação também precisa responder a questões operacionais. As equipes precisam saber qual tarefa falhou, qual chamada de modelo consumiu tokens, quanto custou cada tentativa e se um trabalho abandonado deve ser executado novamente.

Arquiteturas tradicionais costumam atribuir essas preocupações a produtos separados. Um broker de mensagens transporta tarefas. Um mecanismo de workflow gerencia a execução durável. Um cache fornece acesso rápido ao estado. Uma plataforma de monitoramento agrega status, latência e custo.

Essa separação pode sustentar workflows complexos e grandes organizações. Ela também introduz credenciais adicionais, processos de implantação, painéis, modos de falha e código de integração.

A Databricks argumenta que essa sobrecarga é desproporcional para tarefas de longa execução que são independentes umas das outras. A extração de documentos se enquadra nessa descrição porque um contrato geralmente não depende do resultado de outro contrato.

O Lakebase muda esse cálculo ao colocar o estado transacional ao lado do restante da aplicação Databricks. A mesma plataforma fornece a interface, os arquivos, os trabalhos, os rastros de modelo, os controles de governança e os registros de cobrança.

A abordagem pressiona dois grupos. As equipes de plataforma precisam justificar cada serviço adicional que introduzem, enquanto fornecedores de orquestração precisam mostrar por que suas garantias especializadas superam uma fila de banco de dados bem projetada.

Isso não torna sistemas dedicados obsoletos. A Amazon, por exemplo, posiciona o AgentCore Runtime como um ambiente gerenciado com isolamento de sessão, escalonamento, identidade e suporte a agentes de longa execução.

Essa abordagem pede que as equipes adotem um runtime específico para agentes. A Databricks, em vez disso, começa com um banco de dados operacional e o conecta a serviços já usados para cargas de trabalho de dados e machine learning.

Portanto, a disputa é sobre os limites da infraestrutura. A execução de agentes deve viver em um runtime especializado ou um banco de dados deve coordenar trabalhos comuns por meio de estado relacional durável?

A Databricks tem uma vantagem estrutural entre os clientes existentes. As equipes que já usam Lakeflow, MLflow, Unity Catalog e Databricks Apps podem consolidar sem introduzir outro fornecedor ou modelo de segurança.

A mesma vantagem cria dependência da plataforma. Uma empresa que escolhe o padrão completo vincula a execução de tarefas, o armazenamento, a observabilidade, a governança e os relatórios de custo aos serviços da Databricks.

Para compradores, “mais simples” não pode significar apenas menos nomes de produtos. Deve significar menos tarefas operacionais, propriedade mais clara das falhas, comportamento de recuperação aceitável e uma estratégia de saída sustentável.

Quatro padrões do Postgres tornam a fila confiável

A arquitetura funciona porque converte primitivas conhecidas de banco de dados em garantias explícitas sobre concorrência, recuperação, limitação e novas tentativas.

O primeiro padrão é a retirada de tarefas segura para concorrência. Um worker seleciona linhas qualificadas com FOR UPDATE SKIP LOCKED, que bloqueia as linhas selecionadas enquanto permite que outros workers as ignorem.

O PostgreSQL documenta SKIP LOCKED como útil para evitar contenção quando vários consumidores acessam uma tabela semelhante a uma fila. Também alerta que a opção apresenta uma visão inconsistente, tornando-a inadequada para consultas de uso geral.

Essa distinção resume a força do design. A tabela de tarefas não está sendo usada para relatórios arbitrários durante a retirada de tarefas. Os workers precisam de reivindicações exclusivas sobre trabalhos disponíveis sem esperar pelo bloqueio de outro worker.

A consulta ordena o trabalho por prioridade decrescente e hora de criação. Trabalhos de maior prioridade são executados primeiro, enquanto os trabalhos na mesma prioridade mantêm a ordenação por chegada.

O segundo padrão usa leases com expiração. Quando um worker reivindica uma tarefa, ele registra um prazo de expiração do lease em vez de atribuir a propriedade para sempre.

Um processo periódico de varredura devolve tarefas expiradas à fila. Se um worker desaparecer devido a uma remoção, implantação, erro de memória ou falha de processo, outro worker poderá recuperar seu trabalho em minutos.

Leases resolvem o problema do trabalho abandonado, mas também introduzem uma exigência. A aplicação deve escolher períodos de expiração que excedam as durações normais das tarefas ou renovar os leases enquanto o trabalho continua.

Um lease que expira cedo demais pode fazer um trabalho saudável parecer abandonado. Um lease que dura tempo demais aumenta o tempo de recuperação após uma falha real.

O terceiro padrão controla o consumo do modelo antes do despacho. O orquestrador oferece suporte a um limite de tarefas simultâneas, um orçamento projetado de tokens ou uma combinação dos dois.

Um limite de concorrência conta as linhas atualmente marcadas como em processamento. Como o banco de dados mantém essa contagem, a restrição continua visível após reinicializações de workers e entre várias réplicas do orquestrador.

Um orçamento de tokens estima o consumo de cada tarefa em andamento. O orquestrador despacha outro trabalho apenas quando seus tokens projetados se encaixam no limite configurado.

Quando ambos os controles estão habilitados, vence a restrição mais rígida. Isso acomoda cargas de trabalho que alternam entre muitas faturas pequenas e alguns contratos com alto consumo de tokens.

O quarto padrão torna os callbacks idempotentes. Idempotência significa que repetir a mesma solicitação produz o mesmo resultado efetivo, em vez de aplicar a alteração duas vezes.

Interrupções de rede e proxies podem fazer um callback chegar mais de uma vez. A Databricks aceita callbacks para trabalhos em processamento ou recolocados na fila, enquanto trata estados já concluídos como no-ops.

Esse comportamento reduz o risco de processamento ou cobrança duplicados. No entanto, ele depende de identidades de tarefa estáveis, transições de estado cuidadosas e de um limite transacional que inclua a atualização do resultado.

Em conjunto, os quatro padrões criam uma fila confiável. As transações impedem reivindicações simultâneas, os leases recuperam trabalho abandonado, os orçamentos restringem o despacho e os callbacks idempotentes toleram nova entrega.

É assim que a Databricks simplifica uma fila de tarefas de agentes sem alegar que um par de tabelas é suficiente por si só. O código da aplicação ainda implementa a política que rege cada transição.

O mecanismo é adequado para trabalhos com estruturas de dependência relativamente simples. Torna-se menos atraente quando o trabalho exige workflows aninhados, ações compensatórias, aprovações humanas ou longas cadeias de eventos temporizados.

Um mecanismo de workflow dedicado frequentemente representa essas relações de forma direta. Com uma fila de banco de dados, os desenvolvedores precisam modelá-las como tabelas, transições de estado e lógica de aplicação.

Esse trade-off deve orientar a adoção. As equipes devem selecionar esse padrão porque seu workflow é simples o bastante, não porque o Postgres pode, em teoria, representar todos os workflows possíveis.

Um banco de dados conecta estado, visibilidade e custo

A parte mais distinta do design não é o enfileiramento. É a decisão de derivar a visibilidade operacional e a atribuição de custos dos mesmos registros de tarefa.

Os operadores precisam de mais do que um rótulo de concluída ou falhada. O painel do CLA mostra contagens de tarefas enfileiradas, em processamento, concluídas, falhadas e canceladas.

Também apresenta tokens de entrada e saída, custos de modelo, custos de computação, tempo de resposta mediano e confiança por documento. Os filtros abrangem intervalos de tempo, estados das tarefas e agentes individuais.

A latência mediana é uma escolha útil para essa carga de trabalho. O recuo em novas tentativas e a saturação da fila podem criar atrasos extremos que distorcem uma média simples.

O LISTEN/NOTIFY do Postgres fornece o mecanismo de atualização em tempo real. Um gatilho do banco de dados publica um evento quando o estado da tarefa muda, e o backend da aplicação mantém uma conexão de escuta.

O backend distribui esses eventos aos navegadores por meio de Server-Sent Events. SSE é um fluxo HTTP unidirecional que permite a um servidor enviar atualizações por uma conexão persistente com o navegador.

A Databricks afirma que as mudanças no painel geralmente aparecem em aproximadamente um segundo. O design não exige Redis, um servidor WebSocket nem um barramento de mensagens nesse caminho.

O sistema mantém a sondagem como alternativa permanente. Os navegadores solicitam dados atualizados a cada dez segundos quando o streaming fica indisponível.

Essa alternativa é importante porque proxies de entrada em nuvem podem interromper um fluxo sem gerar um erro claro no navegador. Um painel que depende apenas de eventos push pode ficar desatualizado silenciosamente.

O painel combina informações com diferentes velocidades de atualização. O estado do Postgres é imediato, enquanto os dados de rastreamento do MLflow chegam em menos de um segundo, segundo a Databricks.

Consultas de cobrança podem levar dezenas de segundos. Por isso, a aplicação executa consultas rápidas de estado durante atualizações normais e reserva consultas de cobrança mais lentas para ações do usuário.

A atribuição de custos exige outra camada de filtragem. As tabelas de cobrança da Databricks incluem atividade de toda a conta, de modo que uma consulta bruta combinaria gastos de trabalhos e aplicações não relacionados.

O orquestrador registra as execuções específicas de Databricks Job atribuídas às suas tarefas. As consultas de cobrança então filtram a atividade da conta por esses identificadores.

Isso permite que um único SQL warehouse suporte várias aplicações, enquanto cada painel mostra apenas sua própria carga de trabalho. Os operadores podem restringir ainda mais os resultados por status, agente ou data.

O design oferece suporte a questões práticas que o monitoramento genérico frequentemente obscurece. Uma equipe pode inspecionar o custo de tarefas falhadas ao longo de sete dias ou comparar o gasto mediano entre agentes.

Essa ligação entre identidade da tarefa e custo é relevante além da auditoria. Aplicações de IA frequentemente perdem a relação entre uma solicitação do usuário, as tentativas que ela desencadeou e a fatura de modelo resultante.

Um registro durável da tarefa oferece às equipes uma chave de junção estável. Ele conecta a intenção de negócio, o histórico de execução, os rastreamentos do modelo, a atividade de computação e a saída final.

Equipes intensivas em conhecimento enfrentam um problema relacionado após a execução. Elas precisam preservar os documentos, as decisões e as saídas que envolvem o trabalho automatizado em um contexto pesquisável.

Uma base de conhecimento de engenharia estruturada pode complementar os rastreamentos de execução ao reter o contexto humano por trás de incidentes e decisões de design.

O valor do padrão Lakebase, portanto, vai além de menos serviços. Ele cria uma narrativa operacional única para cada tarefa, desde o envio, passando pelas novas tentativas, até o custo e o resultado.

Uma Infraestrutura Mais Simples Transfere o Risco para o Design do Banco de Dados

A Databricks reduz a sobrecarga de integração, mas não elimina a complexidade dos sistemas distribuídos. Ela transfere essa complexidade para esquemas, transações, concessões, e código da aplicação.

A expressão “sem infraestrutura externa” merece uma leitura cuidadosa. A aplicação ainda depende de vários serviços da Databricks, incluindo Apps, Lakeflow Jobs, MLflow, Unity Catalog Volumes e Lakebase.

A simplificação ocorre dentro de uma plataforma gerenciada. Ela não reduz a arquitetura a um processo ou serviço único.

Essa distinção importa durante uma interrupção. Uma fila Lakebase pode permanecer durável enquanto o serviço de jobs está indisponível, mas a aplicação ainda precisa de comportamento testado para despacho atrasado e recuperação.

As equipes também precisam estabelecer o que acontece quando o callback é bem-sucedido, mas uma operação ao redor falha. A idempotência protege contra entregas repetidas apenas quando cada efeito colateral usa identificadores e limites consistentes.

O controle de limite de taxa também contém incerteza. Um orçamento projetado de tokens depende da estimativa do consumo de documentos antes que o modelo os processe.

As estimativas podem subcontar documentos complexos ou supercontar documentos simples. A subestimação pode acionar limitação pelo provedor, enquanto a superestimação pode deixar capacidade de modelo disponível sem uso.

O design publicado não fornece resultados de throughput, limites de profundidade da fila, taxas de falha, carga do banco de dados ou dados operacionais comparativos. Também não compara diretamente a implementação com um mecanismo de workflow dedicado.

A Databricks informa que o tempo de extração caiu de horas para minutos. No entanto, não divulga a amostra de documentos, o processo de revisão humana, a medida de precisão, a configuração do modelo ou o workflow de referência.

Os leitores devem tratar o resultado como um relato de cliente em produção, não como um benchmark controlado. A arquitetura pode ser útil mesmo sem comprovar ganhos universais de desempenho.

O próprio Postgres pode se tornar um ponto de contenção. Desenfileiramentos frequentes, atualizações de status, cálculos de orçamento de tokens, leituras do painel e junções de cobrança partem todos de registros operacionais relacionados.

O Lakebase oferece computação com escalonamento automático e armazenamento durável independente. Esses recursos podem reduzir o planejamento de capacidade, mas o escalonamento automático não elimina consultas ineficientes nem contenção de bloqueios.

As tabelas de fila também crescem de maneira diferente das tabelas comuns de aplicações. O histórico de tentativas se acumula, os registros concluídos continuam valiosos para auditorias e os índices precisam dar suporte tanto ao agendamento em tempo real quanto à análise histórica.

Políticas de retenção e arquivamento são, portanto, parte do design da fila. Sem elas, consultas operacionais podem competir gradualmente com cargas de trabalho de relatórios.

A segurança merece igual atenção. A tabela de tarefas pode conter locais de documentos, resultados extraídos, pontuações de confiança, atribuições de agentes e identificadores de execução.

A Databricks afirma que o Unity Catalog fornece identidade e permissões compartilhadas. As equipes ainda precisam aplicar acesso de privilégio mínimo, proteger endpoints de webhook e decidir quais operadores podem inspecionar resultados sensíveis.

A ramificação do banco de dados pode ajudar a reproduzir defeitos em um ambiente isolado. Ela também pode copiar dados operacionais sensíveis, exigindo mascaramento e controles de acesso adequados à carga de trabalho de auditoria.

A questão competitiva mais ampla continua sem resposta. O AlloyDB AI do Google também posiciona infraestrutura compatível com PostgreSQL como base para aplicações de IA, incluindo buscas vetoriais e híbridas.

A AWS adota uma rota mais específica para agentes, com serviços gerenciados de execução, memória, identidade e orquestração. Sistemas de workflow dedicados continuam focados em execução durável em grafos de processos complexos.

A Databricks mostrou que o Postgres pode cobrir um meio-termo significativo. Ela não mostrou que a orquestração centrada em banco de dados deve substituir esses sistemas em todas as cargas de trabalho de agentes.

O caso de adoção mais forte envolve tarefas independentes e de longa duração em uma plataforma Databricks já existente. O mais fraco envolve workflows entre sistemas com dependências complexas e requisitos rigorosos de portabilidade.

Três Sinais Testarão o Caso de Orquestração do Lakebase

O próximo teste é saber se a arquitetura do CLA se torna um padrão de produção repetível, em vez de uma implementação de cliente cuidadosamente projetada.

O primeiro sinal é a adoção além da extração de documentos. A Databricks deve publicar exemplos envolvendo agentes de programação, operações de clientes, correção de dados ou workflows de pesquisa.

Essas cargas de trabalho testariam diferentes tamanhos de tarefa, estruturas de dependência, permissões de ferramentas e requisitos de aprovação humana. Resultados semelhantes fortaleceriam a alegação de que o Lakebase é um repositório geral de estado para agentes.

Se os exemplos futuros continuarem limitados a jobs independentes de documentos, o design ainda será útil. Seu escopo prático apenas será mais restrito do que sugere a linguagem mais ampla sobre orquestração.

O segundo sinal são dados operacionais comparativos. As equipes precisam de throughput de fila, tempos de recuperação, utilização do banco de dados, taxas de falha e latência de despacho sob carga sustentada.

Uma comparação com workers apoiados por Redis ou com um mecanismo de workflow durável seria especialmente útil. Ela poderia mostrar quando a redução do trabalho de integração supera a lógica adicional de máquina de estados dentro da aplicação.

Dados transparentes reforçariam o argumento de simplificação da Databricks. A ausência desses dados deixaria os compradores dependentes de descrições de arquitetura e resultados relatados por clientes.

O terceiro sinal é a transformação em produto. O padrão atual depende de código da aplicação que implementa bloqueios, concessões, limitação, callbacks, streaming do painel e atribuição de cobrança.

A Databricks poderia transformar partes desse design em modelos, componentes gerenciados, bibliotecas de referência ou recursos nativos do Lakebase. Isso reduziria a quantidade de código crítico para a correção que cada cliente mantém.

A transformação em produto também revelaria como a Databricks define a fronteira entre recursos de banco de dados e recursos de workflow. Uma camada gerenciada maior competiria mais diretamente com runtimes de agentes e plataformas de orquestração.

As equipes que avaliam o padrão devem começar pela forma de seus workflows. Tarefas independentes com estados terminais claros se alinham bem ao design do CLA.

Em seguida, devem testar o comportamento diante de falhas antes de otimizar o throughput. Interrompam workers, atrasem callbacks, dupliquem solicitações, esgotem cotas de modelo e interrompam fluxos do painel.

Por fim, comparem a carga operacional com uma alternativa especializada. Contem os serviços removidos, mas também as transições personalizadas, regras de recuperação, testes e runbooks adicionados.

A Databricks simplifica a infraestrutura visível em torno da orquestração de agentes, e o Lakebase dá ao design um núcleo transacional crível. A questão em aberto é se a sua aplicação é simples o bastante para que essa consolidação continue simples.

Se for, uma fila centrada em banco de dados pode encurtar o caminho do protótipo para um sistema de produção observável. Se não for, o broker ou mecanismo de workflow ausente reaparecerá como código da aplicação. O próximo passo adequado é um piloto focado em falhas, usando tamanhos reais de tarefa, cotas reais e metas reais de recuperação.