Toda equipe que constrói agentes de IA esbarra no mesmo muro.
Você começa com um prompt e algumas ferramentas.
Funciona.
Aí os requisitos crescem. Mais casos extremos. Mais equipes. Mais risco.
De repente, seu "agente" é um system prompt de 3.000 palavras tentando fazer cinco trabalhos ao mesmo tempo.
A solução não é mais engenharia de prompt.
É escolher o padrão certo.
Aqui estão os 15 padrões a partir dos quais todo sistema agêntico de produção é construído — e exatamente quando usar 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 produz 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
Uma tarefa geralmente 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 com template.
Estas 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 system prompt. 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 um trabalho claro.
Use quando: a tarefa é bem definida, o conjunto de ferramentas é pequeno e um agente consegue manter o contexto completo sem se confundir.
Ele quebra quando: você continua adicionando ferramentas e o system prompt ultrapassa uma página. Esse é o sinal de que você precisa de um padrão diferente — não de um prompt mais longo.
PADRÃO 2 — Multiagente Sequencial
Agentes especializados são executados 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 equipe 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.
Ele quebra quando: a ordem precisa variar com base no que é descoberto durante o processo. Pipelines sequenciais assumem que o caminho é fixo — se não for, você precisa de algo mais dinâmico.
PADRÃO 3 — Multiagente Paralelo
Subtarefas independentes são executadas simultaneamente e depois combinadas em uma única visão.
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 são genuinamente independentes e a velocidade é importante.
Ele quebra quando: as tarefas dependem dos resultados umas das outras. Forçar trabalho dependente em execução paralela 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 atender — até um número máximo de tentativas.
Use quando: a tarefa precisa de várias tentativas e você pode definir uma condição de parada clara e verificável.
Ele quebra quando: não há uma condição de saída confiável. Sem uma, você terá 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 dá 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 incorporada ao sistema, não anexada depois.
Ele quebra quando: o agente crítico tem os mesmos pontos cegos que o gerador. Um revisor treinado em suposições semelhantes não detectará 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 em relação às diretrizes da marca e continua reescrevendo até atingir uma pontuação mínima de qualidade — não apenas uma verificação de aprovado/reprovado, mas uma melhoria graduada.
Use quando: a qualidade da saída é genuinamente variável e "bom o suficiente" tem um limite mensurável.
Ele quebra quando: a função de pontuação é vaga ou manipulável. Se o modelo pode 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 faturamento, suporte técnico, conta, envio ou fraude — cada um com contexto restrito, em vez de um agente tentando saber tudo.
Use quando: você tem tipos de solicitação genuinamente diferentes que precisam de contexto, ferramentas ou lógica de decisão diferentes.
Ele 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 roteamento incorreto.
PADRÃO 8 — Decomposição Hierárquica de Tarefas
Um agente raiz divide um objetivo complexo em subobjetivos menores, delega-os a trabalhadores especialistas e depois sintetiza tudo em uma resposta.
Exemplo real: "Em 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 passagem de raciocínio, mas se divide claramente em áreas de especialização independentes.
Ele 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 — Enxame (Swarm)
Múltiplos 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 nível de assinatura? Agentes de pesquisa, engenharia, finanças e suporte argumentam suas perspectivas em várias rodadas antes que um facilitador pondere as compensações.
Use quando: não há uma única resposta "correta" — você precisa de uma decisão bem fundamentada, moldada por pontos de vista genuinamente concorrentes.
Ele quebra quando: você precisa de uma resposta rápida e determinística. Enxames 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ências suficientes.
Exemplo real: "O processador de fila parece travado" — o agente pesquisa documentos, verifica a integridade do serviço, correlaciona descobertas e só então sugere uma correção. O caminho da investigação não é predefinido; depende do que ele encontra ao longo do caminho.
Use quando: o caminho para a resposta genuinamente não pode ser planejado antecipadamente — depende do que cada etapa revela.
Ele 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 Ciclo (Human-in-the-Loop)
O agente investiga e recomenda, mas um humano toma a decisão final sobre 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 qualquer finalização.
Use quando: a decisão envolve risco financeiro, legal ou de reputação real e a automação total ainda não é aceitável.
Ele 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 a frota de workers de 10 para 20 instâncias, verificar se a fila é drenada, atualizar o runbook." O plano completo está visível antes da execução começar, 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 acontecer — importante para operações com consequências reais.
Ele quebra quando: o ambiente muda mais rápido do que o plano pode executar. Um plano desatualizado executado cegamente é pior do que nenhum plano.
PADRÃO 13 — Reflexão (Reflexion)
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 tempo de 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 melhora genuinamente a próxima tentativa.
Ele 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 (Custom Logic)
Um híbrido: código determinístico lida com as regras que nunca devem falhar, enquanto o modelo lida com julgamento, redação e tratamento de exceções.
Exemplo real: Um fluxo de trabalho 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.
Ele quebra quando: as equipes confundem 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 uma decisão exclusiva do modelo.
PADRÃO 15 — Agente Orientado a Eventos (Event-Driven Agent)
O agente não espera ser solicitado. 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 traz à tona, momento em que o dano já está feito.
Use quando: o tempo é mais importante do que qualquer outra coisa, e esperar por uma solicitação humana significa perder a janela de ação.
Ele quebra quando: as condições de disparo são mal definidas. Um fluxo de eventos ruidoso com gatilhos vagos se transforma em um sistema que constantemente grita "lobo!" — ou pior, perde o sinal real.
Seleção de padrão — combine a incerteza, não o hype
O padrão certo corresponde à forma da incerteza no seu trabalho:
→ Incerteza sobre qual ferramenta usar → Agente Único ou ReAct
→ Incerteza sobre para onde rotear → Coordenador
→ Incerteza sobre a 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 Ciclo ou Lógica Personalizada
→ Incerteza sobre a estrutura do problema → Decomposição Hierárquica ou Enxame
→ Não pode esperar por uma solicitação → Agente Orientado a Eventos
Um enxame 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 é um upgrade do ReAct se seu plano ficar desatualizado no passo três.
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 de 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 ferramentas 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 gastos por solicitação. Um agente sem limites de orçamento é um passivo esperando para aparecer em uma conta.
- Registre o rastro completo das ações. Chamadas de ferramenta, argumentos, saídas, decisão final. Sem isso, a investigação de incidentes é um palpite.
- Mantenha ações irreversíveis atrás de verificações determinísticas ou aprovação humana. Nunca deixe um modelo ser o único portão antes de uma movimentação de dinheiro ou alteração na produção.
- Avalie com casos de falha reais, não apenas com caminhos felizes. A correção do caminho feliz é um protótipo. A correção do caso extremo é um produto.
- Separe prompts por responsabilidade antes que o system prompt se torne ilegível. "Mas não faça X quando Y" entrando no seu prompt significa que o agente está fazendo dois trabalhos.
- Trate sistemas multiagente como sistemas distribuídos. Falha parcial, timeouts, tentativas e observabilidade não são opcionais.
- Revisão por modelo não substitui validação determinística. Use juízes para melhorar a qualidade. Use testes e verificações de permissão para garantir a correção.
- 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. Combine a forma do problema. Não adicione autonomia onde ela não merece seu lugar.
Se isso foi útil:
→ Republique para compartilhar com todo engenheiro construindo agentes na sua equipe
→ Siga @sairahul1 para mais análises como esta
→ Salve isto — você voltará aqui toda vez que iniciar um novo projeto de agente
Escrevo sobre IA, construção de produtos e sistemas que funcionam sem você.
