Por que Sistemas Multiagentes Produzem Respostas Diferentes?

Todo mundo fala sobre agentes de IA. Pouca gente fala sobre um dos seus maiores desafios em produção: a deriva (drift) na execução.

Uso aqui “deriva” como a tendência de pequenas variações se acumularem ao longo de um fluxo composto por múltiplos agentes, produzindo resultados diferentes mesmo quando a tarefa e os dados de entrada permanecem essencialmente os mesmos. Esse fenômeno decorre de uma característica fundamental dos LLMs: eles são modelos probabilísticos.

Quando um único LLM responde a uma pergunta, já existe alguma variabilidade potencial na saída. Mesmo utilizando o mesmo prompt, pequenas mudanças na amostragem, no contexto recuperado, nas ferramentas acionadas ou até na infraestrutura de execução podem levar a respostas diferentes. Em algumas configurações essa variabilidade é muito pequena; em outras, torna-se perceptível.

Agora imagine uma arquitetura composta por vários agentes. Um agente interpreta a solicitação. Outro elabora um plano. Outro consulta bases de dados. Outro utiliza ferramentas externas. Outro gera código. Outro revisa. Outro sintetiza a resposta final.

Cada agente recebe como entrada o resultado produzido pelo agente anterior. Assim, pequenas diferenças introduzidas nas primeiras etapas podem influenciar decisões tomadas nas etapas seguintes. Em determinadas arquiteturas, essas diferenças são amortecidas; em outras, acabam sendo amplificadas.

Esse é o fenômeno que estou chamando de efeito deriva.

A razão técnica é simples. Diferentemente de um algoritmo clássico, um LLM não executa uma sequência fixa de instruções que necessariamente produzirá sempre a mesma saída. A cada token gerado, o modelo estima uma distribuição de probabilidades sobre o próximo token possível e seleciona um deles segundo sua estratégia de decodificação. Dependendo da configuração (temperatura, top-p, penalidades, entre outros parâmetros), duas execuções podem seguir trajetórias diferentes.

Vale ressaltar que nem toda diferença representa um erro. Muitas vezes duas respostas distintas são igualmente corretas. O problema aparece quando o processo exige alta reprodutibilidade ou quando pequenas diferenças alteram decisões posteriores da cadeia de agentes.

Um exemplo numérico ajuda a visualizar o fenômeno. Suponha, apenas como exercício ilustrativo, que cada etapa de um fluxo tenha 98% de probabilidade de produzir exatamente a saída esperada e que essas etapas fossem estatisticamente independentes. A probabilidade de oito etapas consecutivas produzirem exatamente o comportamento esperado seria: 0,98⁸ ≈ 85%. Isso significa que aproximadamente 15% das execuções apresentariam alguma diferença em pelo menos uma etapa.

Se a consistência individual cair para 95%, o resultado passa para: 0,95⁸ ≈ 66%, ou seja, cerca de um terço das execuções apresentaria alguma divergência. E em uma cadeia de quinze etapas: 0,95¹⁵ ≈ 46%. Nesse modelo simplificado, mais da metade das execuções apresentaria alguma variação ao longo do fluxo.

Esses cálculos não descrevem o comportamento real de um sistema multiagente, porque pressupõem independência estatística entre as etapas e uma probabilidade fixa de sucesso. Na prática, agentes podem corrigir erros anteriores, introduzir novas divergências ou compartilhar fontes comuns de erro. Ainda assim, o exemplo ilustra um princípio importante da engenharia de sistemas: quanto maior a cadeia de decisões probabilísticas, maior tende a ser a necessidade de mecanismos de controle.

É justamente por isso que a mitigação desse problema depende muito mais da arquitetura do que do prompt.

Arquiteturas robustas normalmente incorporam mecanismos como  validação cruzada entre agentes, etapas determinísticas para regras de negócio,  workflows com estados explícitos, guardrails e políticas de validação, verificações automáticas antes da execução de ações críticas, isolamento de contexto entre agentes, memória versionada,  checkpoints para interromper propagação de inconsistências, e supervisão humana para decisões de alto impacto.

O ponto central é que LLMs são sistemas probabilísticos, não determinísticos. Isso não é um defeito. É uma propriedade da tecnologia.

Por isso, aplicações que exigem resultados rigorosamente reproduzíveis, como cálculo tributário, liquidação financeira, controle industrial, dosagem de medicamentos, sistemas de segurança ou cumprimento automático de regras regulatórias, precisam ser projetadas com extremo cuidado antes de colocar um LLM diretamente no circuito decisório.

Nesses cenários, os LLMs costumam agregar enorme valor na interpretação de linguagem natural, síntese de informações, geração de alternativas e apoio à decisão.

Mas a decisão final, a aplicação de regras de negócio e as operações críticas normalmente devem permanecer sob responsabilidade de componentes determinísticos, como motores de regras, algoritmos tradicionais ou sistemas transacionais auditáveis.

Por isso, é importante ter bem claro no desenho da solução em quais partes do processo a variabilidade probabilística é aceitável e em quais ela simplesmente não pode existir.