Separar a lógica do fluxo de trabalho das estratégias de inferência melhora a escalabilidade de agentes de IA ao desvincular o que o sistema deve fazer de como ele lida com a imprevisibilidade do modelo.
O salto de protótipos de IA generativa para agentes prontos para produção esbarra em um desafio de engenharia específico: confiabilidade. Modelos de linguagem são estocásticos por natureza — um prompt que funciona bem numa execução pode falhar na seguinte. Para contornar isso, equipes costumam envolver a lógica principal do negócio em laços complexos de tratamento de erro, tentativas repetidas e caminhos ramificados.
Esse artifício cria um problema de manutenção: o código que descreve o que o agente deve fazer se mistura irremediavelmente ao código que descreve como lidar com a incerteza do modelo. Pesquisadores da Asari AI, MIT CSAIL e Caltech propõem um padrão arquitetural diferente para escalar fluxos de trabalho agentivos em ambientes corporativos.
PAN e ENCOMPASS: separar lógica e inferência
A pesquisa apresenta um modelo de programação chamado Probabilistic Angelic Nondeterminism (PAN) e uma implementação em Python chamada ENCOMPASS. A ideia é que o desenvolvedor escreva o “caminho feliz” do fluxo de trabalho do agente, enquanto as estratégias de inferência em tempo de execução (por exemplo, beam search ou backtracking) ficam a cargo de um motor separado. Essa separação de responsabilidades pode reduzir a dívida técnica e, ao mesmo tempo, melhorar o desempenho de tarefas automatizadas.
O problema do emaranhamento na programação de agentes
Hoje, muitas abordagens misturam dois aspectos distintos: (1) a lógica do fluxo de trabalho — a sequência de passos necessários para cumprir uma tarefa de negócio — e (2) a estratégia de inferência em tempo de execução — como o sistema navega pela incerteza, gerando rascunhos múltiplos ou verificando saídas contra um critério. Quando unidos, o código se torna frágil. Implementar algo como “best-of-N” exige envolver a função inteira do agente em um loop; mudar para uma estratégia mais complexa, como busca em árvore ou refinamento, frequentemente requer reescrever toda a estrutura do agente.
Os pesquisadores argumentam que esse emaranhamento limita a experimentação. Trocar uma estratégia simples por uma busca em beam para melhorar acurácia normalmente força reengenharia do fluxo de controle, o que eleva o custo da experimentação e leva equipes a se contentarem com soluções de confiabilidade subótimas.
Como ENCOMPASS desacopla lógica e busca
O framework ENCOMPASS permite que programadores marquem “locais de não confiabilidade” no código usando uma primitiva chamada branchpoint(). Esses marcadores indicam onde existe uma chamada ao LLM e onde a execução pode divergir. O desenvolvedor escreve o código como se a operação fosse bem-sucedida; em tempo de execução, o framework interpreta os branch points e constrói uma árvore de busca das possíveis execuções.
Essa arquitetura permite o que os autores chamam de agentes “program-in-control”. Ao contrário de sistemas “LLM-in-control”, em que o modelo decide toda a sequência de operações, agentes program-in-control operam dentro de um fluxo definido pelo código, invocando o LLM apenas para subtarefas específicas — um formato geralmente preferível em empresas por oferecer maior previsibilidade e auditabilidade.
Ao tratar as estratégias de inferência como uma busca sobre caminhos de execução, o framework possibilita aplicar diferentes algoritmos — busca em profundidade, beam search, Monte Carlo tree search — sem alterar a lógica de negócio subjacente.
Exemplo prático: migração de código legado
A utilidade do método ficou evidente em fluxos complexos, como migração de código legado. Os pesquisadores aplicaram o framework a um agente de tradução de Java para Python que traduzia repositórios arquivo a arquivo, gerava entradas e validava a saída via execução.
Num cenário Python padrão, adicionar lógica de busca exigiu definir uma máquina de estados, o que obscureceu a lógica de negócio e dificultou leitura e linting. Implementar beam search impôs quebrar o fluxo em passos individuais e gerenciar explicitamente o estado em um dicionário de variáveis.
Com o ENCOMPASS, as mesmas estratégias de busca foram implementadas inserindo branchpoint() antes das chamadas ao LLM, mantendo a lógica central linear e legível. O estudo mostrou que aplicar beam search tanto no nível de arquivo quanto no nível de método superou estratégias de amostragem mais simples. Os dados indicam que separar essas preocupações permite melhores leis de escala: o desempenho melhorou linearmente com o logaritmo do custo de inferência. A estratégia mais eficaz — beam search de granularidade fina — teria sido a mais complexa de implementar pelos métodos tradicionais.
Custo, desempenho e estratégias de busca
Controlar o custo de inferência é uma preocupação central para quem gerencia o P&L de projetos de IA. A pesquisa demonstra que algoritmos de busca sofisticados podem trazer melhores resultados a um custo inferior ao de simplesmente aumentar o número de loops de feedback. Em um estudo de caso envolvendo o padrão “Reflexion” (em que o LLM critica sua própria saída), comparar o aumento do número de loops de refinamento com o uso de um algoritmo best-first mostrou que a abordagem baseada em busca alcançou desempenho comparável com custo por tarefa reduzido.
Isso sugere que a escolha da estratégia de inferência é um fator de otimização de custo. Ao externalizar essa estratégia, equipes podem ajustar o equilíbrio entre orçamento de compute e precisão exigida sem reescrever a aplicação: uma ferramenta interna de baixo risco pode usar uma busca barata e gananciosa, enquanto uma aplicação voltada ao cliente pode empregar uma busca mais exaustiva, rodando sobre o mesmo código base.
Adaptação, limitações e desafios de engenharia
Adotar essa arquitetura exige uma mudança na forma como times encaram a construção de agentes. O framework foi projetado para funcionar em conjunto com bibliotecas existentes, como LangChain, e não para substituí-las — ele atua em uma camada diferente da pilha, gerenciando o fluxo de controle em vez do prompt engineering ou das interfaces de ferramentas.
Ainda assim, há desafios. O framework reduz o código necessário para implementar buscas, mas não automatiza o design do próprio agente: os engenheiros precisam identificar corretamente onde inserir branch points e definir métricas de sucesso verificáveis. A eficácia de qualquer capacidade de busca depende da habilidade do sistema em pontuar um caminho específico. No exemplo de tradução de código, o sistema podia rodar testes unitários para verificar correção; em domínios mais subjetivos, como sumarização ou geração criativa, definir uma função de pontuação confiável continua sendo um gargalo.
Além disso, o modelo depende da capacidade de copiar o estado do programa nos pontos de ramificação. Embora o framework cuide de escopo de variáveis e gerenciamento de memória, desenvolvedores devem garantir que efeitos colaterais externos — gravações em banco de dados, chamadas de API — sejam gerenciados corretamente para evitar ações duplicadas durante a busca.
Implicações para escalabilidade e governança
A mudança proposta por PAN e ENCOMPASS está alinhada com princípios de engenharia de software de modularidade. À medida que fluxos agentivos se tornam centrais nas operações, mantê-los exigirá o mesmo rigor aplicado a software tradicional. Incorporar lógica probabilística diretamente em aplicações de negócio acarreta dívida técnica, tornando sistemas difíceis de testar, auditar e atualizar. Desacoplar a estratégia de inferência da lógica do fluxo permite otimizar ambos de forma independente.
Essa separação também facilita governança. Se uma estratégia de busca específica gerar alucinações ou erros, ela pode ser ajustada globalmente sem revisar cada base de código individual. Simplifica versionamento de comportamentos de IA — requisito importante em setores regulados, onde o “como” de uma decisão é tão relevante quanto o resultado.
Os autores concluem que, conforme o compute em tempo de inferência escala, a complexidade de gerenciar caminhos de execução tende a crescer. Arquiteturas empresariais que isolam essa complexidade provavelmente se mostrarão mais duráveis do que aquelas que a deixam permear a camada de aplicação.
