# Arquitetura de agentes de IA: escolha o sistema mais simples que funciona - Author: FMKTech Team - Published: 2025-11-06 - Reading time: 4 min - Tags: Arquitetura de IA, Workflows, Engenharia de Software - URL: https://www.fmktech.com.br/pt-BR/blog/understanding-ai-agents-architecture-and-patterns.md (HTML: https://www.fmktech.com.br/pt-BR/blog/understanding-ai-agents-architecture-and-patterns) 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](https://www.anthropic.com/engineering/building-effective-agents). 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](/pt-BR/blog/ai-agent-security-challenges). ## 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](/pt-BR/blog/replicating-fable-with-opus). Para escolher primeiro o problema de negócio, leia [o guia operacional de agentes](/pt-BR/blog/what-are-ai-agents). --- ## Onde procurar depois - [Índice do blog](https://www.fmktech.com.br/pt-BR/blog.md) - [Homepage](https://www.fmktech.com.br/pt-BR.md) - [llms.txt](https://www.fmktech.com.br/llms.txt)