O lote noturno já não é suficiente: por que seus agentes de IA precisam de dados em movimento

Quando um piloto de agentes de IA não chega a produção, a conversa quase sempre gira em torno do modelo. Que é preciso ajustar as instruções, que talvez valha a pena trocar de fornecedor, que falta um fine-tuning com dados próprios. Na nossa experiência implementando plataformas de dados na América Latina, a causa costuma estar em outro lugar, bem menos glamouroso: o agente está olhando para dados velhos.

O agente não sabe que está desatualizado

Um modelo de linguagem não tem como saber se o dado que você entregou é de três segundos atrás ou de quatorze horas atrás. Ele vai responder com a mesma confiança nos dois casos. É exatamente essa propriedade que o torna perigoso quando o contexto chega tarde.

Pense em um agente de atendimento ao cliente em um banco. Você pergunta pelo status de uma transferência. O agente consulta o data warehouse, alimentado por um processo noturno, e responde que a transferência está em processamento. Na verdade ela foi rejeitada duas horas atrás e o cliente já recebeu a notificação. O agente não mentiu: respondeu corretamente sobre um estado que deixou de ser verdadeiro.

Nenhuma quantidade de engenharia de prompts corrige isso.

Por que a arquitetura em lote sobreviveu tanto tempo

O modelo de mover dados copiando funcionou por décadas por um motivo simples: as decisões podiam esperar. O relatório de vendas do dia servia para a reunião da manhã seguinte. A conciliação bancária fechava à noite. Ninguém precisava saber o estado do estoque no segundo exato.

Essa premissa se rompeu por duas frentes ao mesmo tempo.

A primeira é o negócio. A fraude se decide dentro da transação, não na revisão do dia seguinte. O cliente que abandona o carrinho faz isso no minuto, não no trimestre. A queda de rede que vai gerar reclamações já está acontecendo enquanto o painel se atualiza.

A segunda é o agente. Um agente autônomo não consulta dados para informar uma pessoa que vai aplicar o próprio critério. Consulta dados para agir. E agir sobre um estado que já mudou não é um erro de relatório, é uma decisão errada executada de verdade.

A armadilha de ligar o agente direto ao banco

A reação natural de quem percebe isso é evidente: se o data warehouse está velho, que o agente consulte o banco transacional diretamente.

Isso funciona com um agente e um caso de uso. Para de funcionar rápido.

• Cada agente novo abre mais uma conexão contra o sistema que sustenta a operação. O core bancário, o sistema de estoque ou o de faturamento não foram desenhados para absorver consultas analíticas de agentes que raciocinam em voz alta.
• As consultas de um agente são imprevisíveis em forma e em volume. Um pico de conversas vira um pico de carga sobre o sistema crítico.
• Cada integração é ponto a ponto. Com dez sistemas e dez agentes você tem cem caminhos possíveis, e todos precisam de manutenção.
• Não fica registro do que o agente viu. Quando alguém perguntar por que ele decidiu o que decidiu, não há como reconstruir.

Esse último ponto é o que costuma travar o projeto em bancos e telecomunicações. Não basta o agente acertar: é preciso poder explicar depois.

Colocar os eventos no centro

A alternativa que implementamos é diferente em um ponto que parece pequeno e muda tudo: em vez de cada consumidor ir buscar o dado onde ele mora, cada sistema publica o que acontece com ele como um evento, e quem precisar consome dali.

Um pagamento aprovado é um evento. Uma mudança de endereço é um evento. Uma célula de rede degradada é um evento. Um produto que sai do depósito é um evento.

Sobre esse fluxo se resolvem as três coisas que a arquitetura anterior não conseguia dar:

O contexto se constrói enquanto os dados se movem. O perfil de comportamento de um cliente não é recalculado toda noite: ele se mantém atualizado à medida que as transações chegam. Quando o agente pergunta, a resposta já está pronta e já está fresca.

A complexidade deixa de crescer ao quadrado. Um sistema novo publica seus eventos uma vez e qualquer consumidor os toma. Não é preciso construir uma integração para cada par.

Cada decisão fica registrada. Se a decisão do agente também é publicada como evento, o registro completo de quais dados existiam e o que foi decidido sobre eles fica no mesmo lugar. Dá para auditar e dá para reproduzir.

Onde isso começa na prática

Não começa comprando uma licença. Começa escolhendo um caso de uso em que o tempo real muda um resultado mensurável, e trazendo para o fluxo apenas os eventos de que esse caso precisa.

Já vimos projetos que começam querendo publicar o core inteiro como eventos e ficam seis meses empacados na modelagem. E vimos projetos que começam com três tipos de evento, resolvem um caso concreto de fraude e a partir dali crescem por demanda real, não por planejamento especulativo.

O segundo caminho chega a produção. O primeiro costuma terminar como uma apresentação.

O que vale revisar antes de somar mais um agente

Se você está avaliando levar um agente a produção, estas perguntas separam os pilotos que sobrevivem dos que não:

1. De onde sai o dado que o agente vai ver, e com que idade ele chega?
2. Se esse dado muda enquanto o agente raciocina, o que acontece?
3. Você consegue reconstruir, seis meses depois, que informação estava disponível quando ele decidiu?
4. Quando você adicionar o quinto agente, quantas integrações novas serão necessárias?

Se alguma das quatro não tem resposta clara, o problema não está no modelo.