Arquitetura de agentes deve seguir o modo de falha, não a moda do framework

Karthik Ramgopal, engenheiro do LinkedIn, organiza a infraestrutura de agentes em cadeias lineares, grafos e ambientes que geram e executam código.[7] O artigo compara confiabilidade, latência, custo e recuperação, sem apresentar a abordagem mais sofisticada como destino obrigatório.[7]

Essa distinção importa porque adicionar autonomia e ramificações não define, por si só, uma melhoria. Minha proposta é escolher a arquitetura a partir de duas perguntas: onde a tarefa pode falhar e que evidência permite aceitar o resultado?

O que muda para quem desenvolve

Na experiência descrita, cadeias atendem tarefas estreitas, mas um erro pode contaminar as etapas seguintes sem recuperação explícita.[7] Grafos acrescentam decisões, paralelismo, estado estruturado, validação e alternativas; no LinkedIn, foram combinados com infraestrutura de mensagens para tarefas duradouras e histórico.[7]

O custo é precisar codificar mais caminhos e exceções, até o controle se tornar rigidez em problemas pouco previsíveis.[7] A terceira abordagem permite produzir código, executá-lo em isolamento e corrigir falhas observadas, apoiada por instrumentação e ciclos limitados de refinamento.[7]

Minha análise: essas opções não precisam competir pelo sistema inteiro. Uma extração previsível pode continuar linear, enquanto uma aprovação exige estado explícito e um cálculo é delegado a execução restrita. O importante é tornar as fronteiras visíveis, sem esconder regras de negócio em decisões livres do modelo.

Como aplicar

Escolha uma tarefa concreta, como extrair dados de documentos de demonstração e calcular um total. Defina previamente o esquema de saída, exemplos corretos e condições que exigem rejeição. Inclua entradas incompletas, duplicadas e contraditórias.

Comece com uma cadeia simples. Registre em qual etapa cada falha surgiu e se é possível retomar dali sem repetir ações anteriores. Só acrescente um grafo se houver uma decisão ou recuperação que justifique estado próprio. Para cálculos, avalie execução isolada apenas quando puder validar entradas, limitar recursos e conferir resultados.

Compare as alternativas com o mesmo conjunto de casos. Observe taxa de conclusão correta, custo por tarefa aceita, tempo total e esforço para investigar falhas. Não use a quantidade de agentes como indicador de qualidade. O resultado esperado do experimento é uma decisão documentada, não uma arquitetura previamente escolhida.

Cuidados e limites

O artigo recomenda tratar saídas de LLM como entradas não confiáveis, separar planejamento de execução e manter avaliações contínuas, com proteção de dados sensíveis nos registros.[7] O exemplo analítico interno do LinkedIn usa SQL e Python com controles de acesso, privacidade e governança.[7]

Compilar ou passar em testes não comprova correção sem critérios adequados.[7] Por isso, limite tentativas e defina uma saída de falha compreensível. Um sistema que sabe interromper uma tarefa sem evidência suficiente pode ser operacionalmente melhor que um sistema mais autônomo que sempre entrega alguma resposta.

Fonte

[7] Fonte: InfoQ