Arquitetura de agentes de IA: escolha o sistema mais simples que funciona
De um fluxo fixo a um agente autônomo: como escolher a arquitetura, definir seus limites e avaliar o resultado além de uma demonstração convincente.
Revisado em 4 de setembro de 2026.
Uma arquitetura de agentes deve explicar quem decide a próxima ação, onde o estado é mantido e o que impede uma ação inválida. Um diagrama com vários ícones de modelos não basta.
Comece identificando quais decisões são previsíveis. Mantenha cálculos, permissões e regras fixas de negócio em código convencional. Use um modelo onde a interpretação agrega valor e, depois, decida se ele precisa escolher a sequência do trabalho.
Fluxo definido ou agente?
Um workflow segue um caminho definido pela aplicação. Um agente pode escolher o próximo passo conforme o que observa. A discussão da Anthropic sobre agentes eficazes faz essa distinção e recomenda começar por abordagens simples antes de adicionar complexidade. Mais autonomia pode trazer latência, custo e oportunidades adicionais de erro. Leia a discussão original.
Extrair campos de uma solicitação, por exemplo, não exige necessariamente um agente. Validar esses campos, aplicar uma regra conhecida e encaminhar exceções para uma pessoa pode ser suficiente.
Escolha um padrão por um motivo
Este é nosso guia prático de escolha, usando uma operação de atendimento como exemplo ilustrativo.
| Estrutura | Quando é útil | O que verificar |
|---|---|---|
| Sequência fixa | As mesmas etapas valem para cada pedido: extrair, validar, redigir. | Um erro inicial não pode passar silenciosamente à etapa seguinte. |
| Roteamento | Solicitações precisam de caminhos diferentes. | Inclua uma categoria explícita para casos incertos ou não atendidos. |
| Trabalho paralelo | Verificações independentes podem ocorrer ao mesmo tempo. | Concilie divergências; opiniões duplicadas de modelos não são evidência independente. |
| Coordenador e executores | O trabalho pode ser dividido depois de examinar o pedido. | Defina responsáveis, contratos de entrada e saída e uma verificação final de integração. |
| Ciclo de avaliação | Existe um critério concreto para melhorar um rascunho. | Pare ao atingir o limite ou deixar de progredir; aprovação do avaliador não é verdade absoluta. |
| Ciclo de agente | O próximo passo depende de informação nova. | Delimite ferramentas, etapas, custo e escalonamento antes da execução. |
Essas estruturas podem ser combinadas, mas cada camada adicional deve resolver um problema demonstrado. Não acrescente executores só porque é possível paralelizar.
Torne o estado explícito
Em uma solicitação sob investigação, mantenha o estado oficial fora da conversa: identificador, situação atual, evidências reunidas, ações propostas, aprovações e resultados registrados.
O modelo pode interpretar esse estado, mas um resumo fluente não deve substituí-lo. Se a execução reiniciar, o sistema precisa saber se uma ação aconteceu, não se uma mensagem anterior disse que provavelmente aconteceu.
Separe ações propostas de ações executadas. Uma resposta redigida, uma aprovada e uma enviada são estados distintos. Preserve um identificador entre tentativas e use o resultado registrado no sistema de destino para resolver incertezas.
Desenhe ferramentas em torno das operações de negócio
Prefira uma ferramenta de propósito delimitado, com erros compreensíveis, a um acesso genérico. “Consultar a entrega de um pedido permitido” é mais fácil de validar do que “executar SQL arbitrário”.
Defina entradas obrigatórias, autorização, efeitos, comportamento de repetição e evidências retornadas. Torne a ausência de informação explícita, sem substituí-la por um valor plausível. O modelo deve conseguir distinguir “não encontrado”, “não permitido” e “temporariamente indisponível” quando as regras de divulgação permitirem.
Um agente pode escolher entre ferramentas disponíveis; não deve poder ampliar a própria autoridade. Veja esse limite no guia de segurança.
Avalie a tarefa completa
Monte um conjunto pequeno de casos representativos antes de otimizar prompts. Inclua solicitações normais, ambíguas, com fontes contraditórias e fora da autoridade do sistema. Reserve alguns casos para avaliação, sem usá-los no desenvolvimento.
Verifique resultado e conduta. O sistema chegou à resposta correta? Consultou uma fonte adequada, respeitou as restrições de acesso e parou quando necessário?
Meça latência de ponta a ponta e custo total, incluindo repetições e correção humana. Classifique as falhas. Se uma regra fixa resolve uma categoria recorrente de erro, use-a em vez de pedir ao modelo que raciocine sobre ela toda vez.
Um caminho sensato para mais autonomia
Comece com recomendações ou rascunhos para revisão. Acrescente uma ação específica quando seus critérios de aceitação, autorização e recuperação tiverem sido demonstrados.
Aumentar a autonomia muda o risco do produto; não é apenas uma configuração do modelo. Repita as avaliações relevantes quando mudarem o modelo, as ferramentas, as instruções ou os sistemas conectados.
Para um experimento concreto com interfaces tipadas e executores paralelos, veja nosso workflow de criação de jogos e os resultados jogáveis. Para escolher primeiro o problema de negócio, leia o guia operacional de agentes.