Streaming Agents: agentes que executam dentro do fluxo de dados

A forma habitual de construir um agente é como um serviço: ele recebe uma requisição, consulta o que precisa, raciocina e responde. É o modelo que herdamos das aplicações web e funciona bem quando alguém faz uma pergunta.

Existe uma segunda forma, menos conhecida, que muda onde o agente vive: em vez de ser um serviço a quem se pergunta, o agente é um processo que executa dentro do fluxo de eventos. Ninguém o invoca. Ele é ativado quando ocorre o evento que lhe cabe atender.

A diferença não é de infraestrutura

À primeira vista parece uma decisão de deploy. Na prática muda três coisas de fundo.

O agente deixa de pedir contexto. Um agente-serviço, quando precisa saber o histórico de um cliente, faz uma consulta e espera. Um agente que roda dentro do fluxo já tem esse estado à mão, porque o motor de processamento vem mantendo esse estado a cada evento que passou. A diferença entre consultar e ter costuma ser de centenas de milissegundos por decisão, o que em volume de produção não é um detalhe.

O agente reage em vez de esperar. Um serviço não faz nada até alguém chamá-lo. Isso significa que o processo só começa quando um humano ou um sistema decide iniciá-lo. Quando o agente vive no fluxo, o gatilho é o próprio fato. A degradação de rede não espera o cliente ligar para que alguém olhe para ela.

O agente escala como o fluxo escala. O motor já sabe repartir o trabalho por partição e garantir que os eventos de uma mesma entidade sejam processados pela mesma tarefa. Essa é exatamente a repartição de que um agente com estado precisa, e ela vem resolvida.

O que se ganha em rastreabilidade

Há um benefício menos óbvio que em setores regulados costuma ser o decisivo.

Quando o agente executa dentro do fluxo, tanto os dados que ele viu quanto a decisão que tomou são eventos no mesmo registro. Isso permite algo que com um agente-serviço é muito difícil: reproduzir o caso. Dá para voltar à posição exata do fluxo, rodar a versão do agente que estava em vigor naquele dia e ver por que ele decidiu o que decidiu.

Com um agente-serviço, essa reconstrução exige ter registrado separadamente a requisição, a resposta de cada sistema consultado e a versão do modelo, e confiar que os três registros batam. Quase nunca batem.

Quando não vale a pena

Este padrão não substitui o agente conversacional, e forçá-lo onde não cabe é um erro caro.

Não vale a pena quando a interação é iniciada por uma pessoa. Se o caso de uso é alguém escrevendo em um chat, o agente-serviço é a forma correta.

Não vale a pena quando o raciocínio é longo e de muitos passos. Um fluxo de eventos é otimizado para processar muito com baixa latência. Um agente que vai fazer quinze chamadas a ferramentas e demorar quarenta segundos não encaixa nesse modelo, e colocá-lo ali gera backpressure rio acima.

Não vale a pena quando o volume é baixo. Se são cem eventos por dia, a complexidade operacional não se justifica.

O critério prático: se o gatilho é um fato do negócio, o volume é alto e a decisão precisa sair rápido, o agente vai no fluxo. Se o gatilho é uma pessoa e o raciocínio é aberto, ele vai como serviço.

Os dois convivendo

Na maioria das implementações reais os dois acabam operando juntos, e essa é a arquitetura saudável.

O agente no fluxo faz o trabalho contínuo: avalia cada transação, mantém o contexto atualizado, detecta o que foge do normal e dispara a ação quando é o caso. O agente conversacional atende a pessoa, e quando precisa saber o estado do negócio consulta o contexto que o primeiro vem mantendo.

Dito de outro modo: um constrói a verdade sobre o presente, o outro a explica. É uma divisão de trabalho bem mais limpa do que pedir a um único agente que faça as duas coisas.

Por onde começar

Se você já tem uma plataforma de eventos operando, o primeiro caso costuma ser o mais chato de propósito: pegar uma regra que hoje roda em lote e movê-la para o fluxo, sem agentes no meio. Isso valida o modelo de estado, o dimensionamento e a operação.

Com isso funcionando, acrescentar raciocínio sobre esse mesmo fluxo é um passo incremental e não um salto. O erro mais comum que vemos é o inverso: começar pelo agente e descobrir depois que a plataforma de dados de que ele precisava não estava pronta.