← Todos os insights

Análise de tendênciaRecorte: Brasil3 min de leitura

Um agente que lê o warehouse de ontem erra sobre hoje. Confluent e Databricks correm para servir o agora

Streamhouse e Lightning Tables, da Confluent, e o CDC do Debezium ao Databricks sem Kafka querem dar aos agentes o estado atual. Atualidade é requisito da especificação.

Ouça este artigo · 4 min

Narração completa do artigo, gerada por IA.

Corredeiras de um rio atravessando uma floresta, em duotone La Madre, ao lado da frase Quão velho é demais
Foto: Vsatinet (Wikimedia Commons, CC0)

Um cliente liga para dizer que a entrega nunca chegou. O agente de atendimento consulta o sistema de pedidos, vê “em trânsito” e tranquiliza a pessoa. A transportadora marcou o pedido como perdido duas horas antes, mas essa atualização só chega ao warehouse que o agente lê hoje à noite.

Nada nessa conversa é erro do modelo. O agente raciocinou corretamente a partir de uma visão desatualizada do negócio. À medida que os agentes passam de responder perguntas a executar ações, esse tipo de erro se torna o caro, e dois anúncios do início de novembro o atacam por direções opostas.

A Confluent coloca o stream no centro

Em 4 de novembro, a Confluent, agora uma empresa da IBM, apresentou o Streamhouse, uma arquitetura feita para dar a agentes e aplicações uma visão governada e atualizada continuamente do estado atual do negócio. Sua plataforma de streaming de dados agora se organiza em cinco pilares: stream, connect, process, govern e query.

A peça nova está no pilar query. O Lightning Tables, em disponibilidade geral (GA) na AWS, materializa dados do Kafka em tabelas que podem ser consultadas com SQL ou uma API. A Confluent diz que os dados ficam disponíveis para consulta cerca de 100 milissegundos depois de criados, com latência de consulta de 10 a 100 milissegundos e mais de 1.000 consultas por segundo. Esses números vêm dos testes internos da Confluent e variam conforme a configuração. O Lightning Tables é somente leitura, e a Confluent posiciona o Streamhouse ao lado dos warehouses e lakehouses existentes, não como substituto. Um Real-Time Context Engine entrega esse contexto aos agentes via MCP.

A Accenture, citada no anúncio, diz que sair de integrações em batch e ponto a ponto para esse desenho reduziu seu tempo até o insight de meses para dias.

A Databricks tira o stream do meio

Um dia depois, a Databricks descreveu o caminho oposto. A versão 3.7 do Debezium Server inclui um sink para o Zerobus Ingest que empurra eventos de change data capture de bancos como PostgreSQL, MySQL, SQL Server, Oracle e MongoDB direto para tabelas do Unity Catalog, sem cluster Kafka no meio. A NVIDIA contribuiu com um modo envelope e proteções de entrega: o sink espera até o Zerobus confirmar que os eventos são duráveis antes de o Debezium avançar sua posição no log de origem.

O detalhe na letra miúda importa para agentes. A entrega é at least once, não exactly once. Cada evento carrega uma chave de idempotência, mas é preciso remover as duplicatas adiante.

Quão atual é o estado que seu agente lê?

OntemAgora

  1. Carga noturna em batchCarga típica de warehouse
  2. De hora em hora ou micro-batchPipelines comuns de lakehouse
  3. CDC por pushEventos de mudança chegam conforme o commit
  4. Stream materializadoCerca de 100 ms, nos testes da Confluent
As posições são ilustrativas. Os números de latência são alegações dos fornecedores nos anúncios de 4 e 5 de novembro.

Atualidade é requisito, não funcionalidade

Já defendemos que o contexto de um agente precisa de uma especificação, e a atualidade é uma das suas quatro propriedades. Esses lançamentos tornam possível cumprir uma meta apertada de atualidade. Eles não dizem qual deve ser essa meta.

Escreva a meta por ação:

  • Responder perguntas sobre políticas ou histórico tolera uma carga diária.
  • Informar um cliente sobre o status de um pedido ou de um sinistro precisa de minutos, no máximo.
  • Agir sobre estoque, crédito, fraude ou um pagamento exige o estado atual, e uma checagem no sistema de registro imediatamente antes da ação.

Duas cautelas práticas vêm daí. Primeiro, entrega at least once significa que um agente pode ver a mesma mudança duas vezes. Qualquer ação disparada por um evento, como um reembolso ou uma notificação, precisa da própria chave de idempotência, ou pode acontecer duas vezes. Segundo, uma cópia rápida continua sendo cópia. Para ações irreversíveis, o agente deve ler do sistema que é dono do registro, ou confirmar com ele, como defendemos em onde deve ficar a autoridade para confirmar uma transação.

A Confluent e a Databricks vão competir em números de latência. A decisão que importa é interna: para cada coisa que seus agentes fazem, quão velho é velho demais?

Tem um caso de uso de IA parado entre o protótipo e a produção?

Conte o que você quer colocar no ar. Respondemos com próximos passos honestos.

Converse sobre um caso de uso