Cada equipe criando agentes de IA encontra a mesma barreira.
Você começa com um prompt e algumas ferramentas.
Funciona.
Então os requisitos crescem. Mais casos de exceção. Mais equipes. Mais risco.
De repente, seu "agente" é um prompt de sistema de 3.000 palavras tentando fazer cinco tarefas ao mesmo tempo.
A solução não é mais engenharia de prompts.
É escolher o padrão certo.
Aqui estão os 15 padrões que todo sistema agêntico em produção usa — e exatamente quando aplicar cada um.
Antes de escolher um padrão
Nem toda tarefa precisa de um agente.
Uma tarefa justifica um agente quando:
→ Uma única chamada de modelo não consegue gerar um resultado confiável
→ O modelo precisa escolher entre ferramentas ou fontes de dados em tempo de execução
→ A tarefa exige planejamento, validação ou refinamento iterativo
→ O fluxo de trabalho tem incerteza real que não pode ser codificada diretamente
Geralmente, uma tarefa não precisa de um agente quando o caminho de entrada para saída é previsível.
Sumarização. Classificação. Extração simples. Geração baseada em template.
Essas são mais rápidas, mais baratas e mais confiáveis como chamadas diretas de modelo.
Envolvê-las em um agente só adiciona latência e pontos de falha sem benefício algum.
PADRÃO 1 — Agente Único
O ponto de partida mais simples e comum.
Um modelo. Um prompt de sistema. Um conjunto limitado de ferramentas.
O modelo decide qual ferramenta chamar, observa o resultado e continua até ter informações suficientes para responder.
Exemplo real: Um agente de suporte ao cliente que consulta o status do pedido, verifica o envio e cria um ticket se não conseguir resolver o problema — tudo com 2 a 3 ferramentas e uma única tarefa clara.
Use quando: a tarefa for bem definida, o conjunto de ferramentas for pequeno e um único agente conseguir manter o contexto completo sem se confundir.
Quebra quando: você fica adicionando ferramentas e o prompt de sistema ultrapassa uma página. Esse é o sinal de que você precisa de um padrão diferente — não de um prompt maior.
PADRÃO 2 — Sequencial Multiagente
Agentes especializados executam em uma ordem fixa. A saída de cada um alimenta a entrada do próximo.
Exemplo real: Um pipeline de revisão de contratos — um agente extrai obrigações, o próximo identifica riscos, um terceiro redige o resumo para a área de compras. A sequência nunca muda.
Use quando: o fluxo de trabalho tem etapas claras e repetíveis, e cada etapa produz exatamente o que a próxima precisa.
Quebra quando: a ordem precisa variar com base no que é descoberto no meio do processo. Pipelines sequenciais assumem que o caminho é fixo — se não for, você precisa de algo mais dinâmico.
PADRÃO 3 — Paralelo Multiagente
Subtarefas independentes são executadas simultaneamente e depois combinadas em uma visão única.
Exemplo real: Um incidente de produção às 2h da manhã. Três agentes investigam logs, métricas e implantações recentes ao mesmo tempo — não um após o outro — porque cada minuto importa durante uma interrupção.
Use quando: as subtarefas forem genuinamente independentes e a velocidade for importante.
Quebra quando: as tarefas dependem umas dos resultados das outras. Forçar trabalho dependente em execução paralela só cria condições de corrida e contexto incompleto.
PADRÃO 4 — Loop
Repita uma sequência de etapas até que uma condição de saída seja atendida.
Exemplo real: Um agente de limpeza de dados que analisa dados CSV bagunçados, propõe um plano de limpeza, verifica se atende aos padrões de qualidade e tenta novamente se não passar — até um número máximo de tentativas.
Use quando: a tarefa precisar de múltiplas tentativas e você puder definir uma condição de parada clara e verificável.
Quebra quando: não houver uma condição de saída confiável. Sem ela, você tem custos descontrolados e um sistema que pode nunca terminar.
PADRÃO 5 — Revisão e Crítica
Um agente juiz revisa a saída de outro agente, critica e fornece feedback específico e acionável.
Exemplo real: Um relatório gerado é revisado por um agente "crítico" separado que sinaliza alegações fracas, evidências ausentes ou seções pouco claras antes de chegar a um humano.
Use quando: a qualidade importa mais que a velocidade e você quer uma segunda opinião embutida no sistema, não adicionada depois.
Quebra quando: o agente crítico tem os mesmos pontos cegos que o gerador. Um revisor treinado com suposições semelhantes não vai perceber os mesmos erros.
PADRÃO 6 — Refinamento Iterativo
Um loop de feedback com um limite de pontuação de qualidade. O gerador continua refinando até ultrapassar a barreira.
Exemplo real: Um gerador de textos de marketing que avalia seu próprio rascunho com base nas diretrizes da marca e reescreve até atingir uma pontuação mínima de qualidade — não apenas uma verificação de aprovado/reprovado, mas melhoria gradual.
Use quando: a qualidade da saída for genuinamente variável e "bom o suficiente" tiver um limite mensurável.
Quebra quando: a função de pontuação é vaga ou manipulável. Se o modelo consegue inflar sua própria pontuação sem melhoria real, o loop só queima tokens.
PADRÃO 7 — Coordenador
Um agente roteador central direciona solicitações para agentes especializados com base no que está sendo perguntado.
Exemplo real: Tickets de suporte são roteados para especialistas em cobrança, suporte técnico, conta, envio ou fraude — cada um com contexto restrito, em vez de um único agente tentando saber de tudo.
Use quando: você tem tipos de solicitação genuinamente diferentes que precisam de contexto, ferramentas ou lógica de decisão distintos.
Quebra quando: o próprio roteamento se torna ambíguo. Se as solicitações não se encaixam claramente em uma categoria, o coordenador se torna um novo gargalo e fonte de erros de roteamento.
PADRÃO 8 — Decomposição Hierárquica de Tarefas
Um agente raiz divide um objetivo complexo em subobjetivos menores, delega para especialistas e depois sintetiza tudo em uma única resposta.
Exemplo real: "Quais 3 países devemos expandir no próximo ano?" é dividido em análise competitiva, pesquisa regulatória, viabilidade logística e dimensionamento de mercado — cada um tratado por um especialista diferente e depois combinado.
Use quando: o problema é amplo demais para uma única passada de raciocínio, mas se divide claramente em áreas independentes de conhecimento.
Quebra quando: os subobjetivos não são realmente independentes. Se os fluxos de trabalho precisam se informar em tempo real, decompor antecipadamente perde essa interação.
PADRÃO 9 — Swarm (Enxame)
Vários agentes especialistas contribuem para uma discussão compartilhada, desafiam as suposições uns dos outros, e um facilitador sintetiza uma recomendação final.
Exemplo real: A empresa deveria lançar um plano de assinatura? Agentes de pesquisa, engenharia, finanças e suporte debatem suas perspectivas em várias rodadas antes que um facilitador pondere os prós e contras.
Use quando: não há uma única resposta "correta" — você precisa de uma decisão bem fundamentada, moldada por pontos de vista genuinamente concorrentes.
Quebra quando: você precisa de uma resposta rápida e determinística. Swarms são deliberadamente lentos e exploratórios — ferramenta errada se você precisa de velocidade.
PADRÃO 10 — ReAct (Raciocinar e Agir)
O agente alterna entre raciocínio e ação: decide o que investigar, chama uma ferramenta, observa o resultado, decide se já há evidência suficiente.
Exemplo real: "O processador de fila parece travado" — o agente busca na documentação, verifica a saúde do serviço, correlaciona os achados e só então sugere uma correção. O caminho de investigação não é predefinido; depende do que ele encontra ao longo do caminho.
Use quando: o caminho para a resposta realmente não pode ser planejado antecipadamente — depende do que cada etapa revela.
Quebra quando: as investigações se prolongam sem convergir. Sempre limite o número de ciclos de raciocínio-ação, ou você corre o risco de exploração infinita.
PADRÃO 11 — Humano no Loop
O agente investiga e recomenda, mas um humano toma a decisão final em qualquer coisa arriscada ou ambígua.
Exemplo real: Aprovações de reembolso — casos de baixo risco e claros são automatizados. Valores altos, sinais de fraude ou exceções de política pausam para revisão humana antes de finalizar.
Use quando: a decisão envolve risco financeiro, legal ou de reputação real, e a automação total ainda não é aceitável.
Quebra quando: você trata isso apenas como um recurso de interface, em vez de arquitetural. Você precisa de estado durável, atribuição de revisor, tratamento de tempo limite e caminhos de escalonamento — não apenas um botão de "pausar".
PADRÃO 12 — Planejar e Executar
Um agente planejador cria um plano estruturado completo antecipadamente — revisável e modificável — antes de qualquer ação ser tomada. Um executor então percorre as etapas.
Exemplo real: "Redimensionar o pool de workers de 10 para 20 instâncias, verificar se a fila drena, atualizar o runbook." O plano completo fica visível antes do início da execução, ao contrário do ReAct, onde o caminho emerge passo a passo.
Use quando: você quer que o plano seja revisável ou aprovável antes de qualquer ação — importante para operações com consequências reais.
Quebra quando: o ambiente muda mais rápido que o plano pode executar. Um plano desatualizado executado cegamente é pior do que nenhum plano.
PADRÃO 13 — Reflexão
O agente avalia suas próprias falhas, reflete sobre o que deu errado e carrega essa memória para a próxima tentativa.
Exemplo real: Um agente de geração de código escreve um script, ele falha em execução, o agente analisa o erro real, registra o que corrigir e tenta novamente — ficando mais inteligente a cada tentativa, em vez de repetir o mesmo erro.
Use quando: as falhas são informativas e a autocorreção realmente melhora a próxima tentativa.
Quebra quando: os modos de falha são aleatórios ou não relacionados entre si. A reflexão só ajuda quando há um padrão real a ser aprendido.
PADRÃO 14 — Lógica Personalizada
Um híbrido: código determinístico lida com as regras que nunca devem falhar, enquanto o modelo cuida de julgamento, redação e tratamento de exceções.
Exemplo real: Um fluxo de reembolso onde a verificação de compra e as verificações de fraude são executadas como regras determinísticas rígidas — nunca delegadas ao modelo — enquanto a redação da resposta ao cliente e as recomendações de roteamento permanecem agênticas.
Use quando: o fluxo de trabalho tem lógica de ramificação real com consequências legais ou financeiras, e você precisa ser preciso sobre o que é determinístico versus o que é flexível.
Quebra quando: as equipes borram a linha e deixam o modelo tomar decisões que deveriam ser regras codificadas. Elegibilidade, permissões e movimentação de dinheiro nunca devem ser decisão exclusiva do modelo.
PADRÃO 15 — Agente Orientado a Eventos
O agente não espera ser chamado. Ele assina um fluxo de eventos e age no momento em que uma condição é acionada.
Exemplo real: Um agente de detecção de fraude que reage no instante em que um evento de transação suspeita é disparado — não quando um ticket de suporte eventualmente o revela, momento em que o dano já está feito.
Use quando: o timing importa mais que qualquer outra coisa, e esperar por uma solicitação humana significa perder a janela de ação.
Quebra quando: as condições de acionamento são mal definidas. Um fluxo de eventos ruidoso com gatilhos vagos se transforma em um sistema que constantemente "chama o lobo" — ou pior, perde o sinal real.
Seleção de padrão — alinhe com a incerteza, não com o hype
O padrão certo corresponde ao formato da incerteza no seu trabalho:
→ Incerteza sobre qual ferramenta usar → Agente Único ou ReAct
→ Incerteza sobre para onde rotear → Coordenador
→ Incerteza sobre qualidade → Revisão e Crítica ou Refinamento Iterativo
→ Incerteza sobre o caminho de execução → Planejar e Executar ou ReAct
→ Incerteza sobre como se autocorrigir → Reflexão ou Loop
→ Incerteza sobre risco de negócio → Humano no Loop ou Lógica Personalizada
→ Incerteza sobre a estrutura do problema → Decomposição Hierárquica ou Swarm
→ Não pode esperar por uma solicitação → Agente Orientado a Eventos
Um swarm não é mais avançado que um agente único se a tarefa só precisa de uma chamada de ferramenta confiável.
Planejar e Executar não é uma atualização do ReAct se seu plano fica obsoleto na terceira etapa.
Os sistemas de produção mais confiáveis não são os mais autônomos.
Eles colocam autonomia exatamente onde ela cria valor — e a restringem em todos os outros lugares.
10 regras para sistemas agênticos em produção
- Comece com o menor padrão que funciona. Um agente único com contratos de ferramenta limpos vence um sistema multiagente com contratos fracos.
- Escreva descrições de ferramenta como contratos. O modelo só sabe o que a ferramenta faz pela descrição — não pela sua intenção.
- Limite iterações, chamadas de ferramenta e gasto por solicitação. Um agente sem limites de orçamento é um passivo esperando para aparecer na conta.
- Registre o rastro completo de ações. Chamadas de ferramenta, argumentos, saídas, decisão final. Sem isso, investigação de incidentes é palpite.
- Mantenha ações irreversíveis atrás de verificações determinísticas ou aprovação humana. Nunca deixe um modelo ser o único guardião antes de uma movimentação de dinheiro ou alteração em produção.
- Avalie com casos de falha reais, não apenas caminhos felizes. Corretude no caminho feliz é um protótipo. Corretude em casos de exceção é um produto.
- Separe prompts por responsabilidade antes que o prompt de sistema se torne ilegível. "Mas não faça X quando Y" aparecendo no seu prompt significa que o agente está fazendo dois trabalhos.
- Trate sistemas multiagente como sistemas distribuídos. Falha parcial, timeouts, retentativas e observabilidade não são opcionais.
- Revisão por modelo não substitui validação determinística. Use juízes para melhorar qualidade. Use testes e verificações de permissão para garantir corretude.
- Prefira o padrão mais simples — não porque simples é sempre melhor, mas porque o orçamento de complexidade que você economiza pode ser gasto em melhores ferramentas, melhores prompts, melhor avaliação.
Esses são todos os 15.
A maioria das equipes não falha porque escolheu o padrão errado.
Elas falham porque nunca perguntaram para qual incerteza estavam realmente projetando.
Escolha o padrão. Alinhe com o formato do problema. Não adicione autonomia onde ela não merece seu lugar.
Se isso foi útil:
→ Reposte para compartilhar com todo engenheiro que cria agentes na sua equipe
→ Siga @sairahul1 para mais análises como esta
→ Salve — você vai voltar aqui toda vez que iniciar um novo projeto de agente
Escrevo sobre IA, construção de produtos e sistemas que funcionam sem você.
