
Padrões de Workflow de Agentes de IA: 7 Padrões e Quando Cada Um Realmente Vence (2026)
Padrões de workflow de agentes de IA finalmente têm números associados: em janeiro de 2026, o Google Research avaliou 180 configurações de agentes e descobriu que a mesma mudança de coordenação elevou o raciocínio financeiro paralelizável em 80,9%, enquanto esmagou o planejamento sequencial em até 70% no PlanCraft. Mesma alavanca, resultados opostos. A variável que decide é a decomponibilidade da tarefa, não a contagem de agentes, e os sete padrões abaixo são julgados contra dados publicados, não contra diagramas de fornecedores.
- Sete padrões importam: sequencial, roteamento, paralelização, orquestrador-trabalhadores, reflexão, ReAct, plan-and-execute.
- A decomponibilidade da tarefa decide o vencedor. Trabalho paralelizável ganha; trabalho sequencial degrada.
- Comece com um agente. Adicione um segundo somente quando um único agente estagnar abaixo de ~85% de precisão.
Padrões de Workflow de Agentes de IA em Resumo: O Que os Dados Dizem
Os sete padrões de agentes de IA são sequencial (encadeamento de prompts), roteamento (handoff), paralelização (fan-out/fan-in), orquestrador-trabalhadores, reflexão (avaliador-otimizador), ReAct e plan-and-execute. Cinco documentações de fornecedores os nomeiam de forma diferente, mas esses sete formatos cobrem toda taxonomia que Anthropic, OpenAI, Vercel, Microsoft e Google Cloud publicam atualmente. Human-in-the-loop não é um dos sete: é uma camada de controle que envolve qualquer um deles.
| Padrão | O que é | Use quando | Custo / benefício medido (fonte) | LangGraph / OpenAI SDK / Anthropic / AI SDK |
|---|---|---|---|---|
| Sequencial (encadeamento de prompts) | Etapas executam uma após a outra | O caminho é fixo e cada etapa precisa da anterior | Nenhuma medição pública de ganho; a Anthropic (2026-03-05) o chama de ponto de partida padrão | chain / code orchestration / sequential / sequential processing |
| Roteamento (handoff) | Classifica e despacha para um especialista | As entradas se dividem em domínios distintos | Nenhuma medição pública | router / handoff / routing / routing |
| Paralelização (fan-out/fan-in) | Executa subtarefas ao mesmo tempo e mescla os resultados | As subtarefas são genuinamente independentes | +80,9% sobre um único agente em tarefas financeiras paralelizáveis (Google Research, 2026-01-28, 180 configs) | Send fan-out / code orchestration / parallel / parallel processing |
| Orquestrador-trabalhadores | Um agente líder decompõe e delega | Os domínios de contexto são separados e grandes | +90,2% sobre o Opus 4 single-agent na avaliação de pesquisa da Anthropic (2025-06-13); ~15× tokens de chat | supervisor / agents-as-tools / orchestrator-workers / orchestrator-worker |
| Reflexão (avaliador-otimizador) | Gerador mais crítico em loop | A qualidade da saída é mensurável | Nenhuma medição pública | reflection / LLM orchestration / evaluator-optimizer / evaluator-optimizer |
| ReAct | Raciocínio e chamadas de ferramenta intercalados | As etapas dependem de observações anteriores | +34% absoluto no ALFWorld, +10% no WebShop (Yao et al., 2022) | ReAct agent / sem padrão nomeado / autonomous agent / sem padrão nomeado |
| Plan-and-execute | Planeja a rota inteira e depois executa | A rota é previsível de antemão | Venceu zero-shot CoT em 10/10 datasets (Wang et al., ACL 2023); nenhum número único publicado | plan-and-execute / sem primitiva / autonomous agent / sem padrão nomeado |
Leia a coluna de medições com ceticismo. Três linhas trazem números reais; quatro trazem "nenhuma medição pública", que é o estado honesto do campo em 2026. Cinco fornecedores publicam cinco nomes diferentes para o que são, na verdade, três ou quatro formatos subjacentes. A última coluna existe para você mapear qualquer um desses nomes de volta ao formato subjacente, que o resto do post destrincha uma família de cada vez.
Duas colunas que ninguém na SERP discute são custo de tokens e orçamento de latência. Sequencial e roteamento gastam o mínimo de ambos; orquestrador-trabalhadores gasta o máximo de ambos; paralelização troca gasto de tokens por tempo total. Escolha o padrão pelo recurso que a sua tarefa realmente restringe, não pelo diagrama que parece impressionante.
O Que São Padrões de Workflow de Agentes de IA (e Quais São as 4 Etapas de um Workflow de IA)?
Padrões de design de workflow de agentes de IA são formatos reutilizáveis para organizar chamadas de LLM, uso de ferramentas e lógica de controle em um sistema. Os sete que se repetem em toda taxonomia de fornecedor são sequencial, roteamento, paralelização, orquestrador-trabalhadores, reflexão, ReAct e plan-and-execute. Cada um troca custo de tokens, latência e precisão de forma diferente, então a escolha certa depende da estrutura da tarefa, não do framework que você por acaso usa.
Um workflow típico de agente de IA roda quatro etapas, em loop:
- Planejar: o modelo decide o que fazer em seguida, dado o objetivo e o histórico até ali.
- Agir: ele chama uma ferramenta, o que em 2026 geralmente significa um servidor MCP ou uma function call. O Model Context Protocol (MCP) padroniza essa camada de ferramentas entre modelos.
- Observar: o resultado da ferramenta volta ao contexto como uma nova mensagem.
- Refletir / repetir: o modelo julga se o resultado é bom o suficiente, então repete o loop ou para.
Cada padrão deste post é uma forma diferente de conectar essas quatro etapas. O sequencial fixa a ordem no código. O ReAct deixa o modelo escolher a próxima etapa a cada turno. O orquestrador-trabalhadores divide o loop entre vários modelos.
Uma distinção importa antes do catálogo. Um workflow segue caminhos de código predeterminados; um agente entrega o controle ao modelo. A Anthropic traça a linha assim em Building Effective Agents: "Workflows oferecem previsibilidade e consistência para tarefas bem definidas, enquanto agentes são a melhor opção quando flexibilidade e tomada de decisão dirigida pelo modelo são necessárias em escala."
Se você chegou aqui procurando os tipos clássicos de agentes em IA (reflexo simples, baseado em modelo, baseado em objetivos, com aprendizado), essa taxonomia é anterior aos LLMs; os sete padrões acima são os que decidem se o seu projeto embarca ou não.
Os Padrões Determinísticos: Sequencial, Roteamento e Paralelização
Três padrões mantêm o controle no seu código, não no modelo. São os mais baratos de rodar e os mais fáceis de depurar, e a orientação da equipe do Claude de março de 2026 é direta sobre onde começar: "Comece com o padrão mais simples que resolve o seu problema. Use sequencial por padrão."
Sequencial (encadeamento de prompts)
Uma chamada alimenta a próxima. Você divide uma tarefa difícil em etapas ordenadas, e cada etapa recebe a saída da anterior como entrada. O ganho é legibilidade: você pode inspecionar cada resultado intermediário e cachear cada etapa. Evite quando as subtarefas forem independentes, porque você está pagando latência por uma ordenação de que não precisa. Se o estado precisa sobreviver entre etapas ou entre sessões, isso é um problema de memória, não de encadeamento; veja nosso guia de memória de agentes para entender a divisão. O único endosso publicado do padrão é ser o ponto de partida padrão: nenhum estudo mede ganho do encadeamento em si, porque ele é a linha de base que todo outro padrão paga a mais para superar.
from anthropic import Anthropic
client = Anthropic()
def chain(steps: list[str], context: str = "") -> str:
for step in steps:
msg = client.messages.create(
model="claude-sonnet-4-5",
max_tokens=1024,
messages=[{"role": "user", "content": f"{context}\n\n{step}"}],
)
context = msg.content[0].text
return context
summary = chain([
"Extract the five key claims from this report: {report}",
"Rewrite those claims as bullets an engineer would trust.",
])Roteamento (handoff)
Um classificador barato lê a entrada e a despacha para um prompt ou modelo especialista. A OpenAI descreve assim na documentação do Agents SDK: "Um agente de triagem roteia a conversa para um especialista, e esse especialista se torna o agente ativo pelo resto do turno." Evite o roteamento quando o classificador for menos confiável do que simplesmente rodar um caminho geral único, porque cada erro de rota é uma resposta errada silenciosa. O modo de falha nomeado aqui é a perda de contexto no handoff: o especialista só vê o que o roteador encaminha. Carregar o rastro completo é uma decisão de engenharia de contexto, e errar nisso é por que sistemas roteados parecem esquecidos. A conta de tokens ainda assim favorece o roteamento: o classificador roda num modelo pequeno (gpt-4o-mini acima), então um roteador adiciona algumas centenas de tokens baratos por requisição, em vez de uma segunda chamada cara.
from openai import OpenAI
client = OpenAI()
SPECIALISTS = {
"billing": "You answer billing and refund questions.",
"technical": "You debug API errors and integration issues.",
}
def route(question: str) -> str:
triage = client.responses.create(
model="gpt-4o-mini",
input=f"Reply with exactly one of {list(SPECIALISTS)}: {question}",
)
key = triage.output_text.strip().lower()
return client.responses.create(
model="gpt-4o",
instructions=SPECIALISTS.get(key, SPECIALISTS["technical"]),
input=question,
).output_textParalelização (fan-out/fan-in)
Subtarefas independentes rodam ao mesmo tempo, e uma etapa de mesclagem as combina. A Anthropic divide isso em sectioning (dividir o trabalho) e voting (rodar a mesma tarefa várias vezes e comparar). Esse é o formato que o Google Research mediu em +80,9% sobre um único agente em raciocínio financeiro paralelizável em janeiro de 2026, justamente porque a tarefa se decompunha de forma limpa. Evite no momento em que o passo n+1 depender da saída do passo n; paralelizar uma cadeia de dependências só reordena as respostas erradas mais rápido. A latência é a outra metade do ganho: chamadas independentes rodam concorrentemente, então o tempo total cai mais ou menos com o número de trabalhadores enquanto o gasto total de tokens fica igual.
from concurrent.futures import ThreadPoolExecutor
from anthropic import Anthropic
client = Anthropic()
def run(subtask: str) -> str:
msg = client.messages.create(
model="claude-sonnet-4-5",
max_tokens=1024,
messages=[{"role": "user", "content": subtask}],
)
return msg.content[0].text
def fan_out(subtasks: list[str]) -> list[str]:
with ThreadPoolExecutor(max_workers=len(subtasks)) as pool:
return list(pool.map(run, subtasks))
parts = fan_out([
"Summarize Q1 revenue drivers in two sentences.",
"Summarize Q1 churn drivers in two sentences.",
])
merged = run(f"Combine into one executive summary:\n{parts}")ReAct vs Plan-and-Execute: Qual Padrão de Raciocínio Você Deve Usar?
O ReAct intercala raciocínio com ação: o modelo pensa, chama uma ferramenta, observa o resultado e só então decide o próximo passo. O plan-and-execute escreve o plano completo antes de qualquer ferramenta rodar, e então executa as etapas em ordem. O ReAct se adapta a surpresas no meio da execução; o plan-and-execute paga por uma chamada grande de planejamento logo de cara e confia na rota.
O ReAct decide o próximo passo depois de cada observação; o plan-and-execute se compromete com a rota inteira antes da primeira chamada de ferramenta.
ReAct vem de Yao et al. (arXiv 2210.03629, v1 outubro de 2022, v3 março de 2023), que relatou +34% absolutos de sucesso no ALFWorld e +10% no WebShop sobre linhas de base de imitação e aprendizado por reforço, usando apenas um ou dois exemplos em contexto. É o loop padrão por trás da maioria dos agentes que usam ferramentas, e é uma lacuna no 3º resultado da SERP: a documentação de orquestração de 7.133 palavras da Microsoft Learn omite o ReAct por completo. Essa cadência observar-decidir é por que o ReAct lida melhor com tarefas abertas ("navegue até encontrar X") do que qualquer plano prévio: o plano teria que adivinhar o que as páginas contêm antes de lê-las.
Plan-and-execute vem de Wang et al., Plan-and-Solve Prompting (arXiv 2305.04091, ACL 2023), que primeiro elabora um plano dividindo a tarefa em subtarefas e depois as executa. O paper relata vitória sobre chain-of-thought zero-shot nos dez datasets avaliados; não citamos um número único porque o abstract do paper não publica nenhum. Use quando a rota for previsível e replanejar após cada etapa desperdiçaria tokens. O tradeoff é fragilidade: se a etapa três falha, um loop plan-and-execute precisa de um hook explícito de replanejamento, enquanto o ReAct replaneja por construção.
| ReAct | Plan-and-execute | |
|---|---|---|
| Como decide | Depois de cada observação | Uma vez, antes de qualquer chamada de ferramenta |
| Replaneja no meio? | Sim, a cada etapa | Não (replaneja só em caso de falha) |
| Perfil de tokens | Muitas chamadas pequenas | Uma chamada grande de planejamento, depois execução |
| Falha quando | O loop não tem condição de saída | O plano está errado e a execução não se recupera |
| Evidência medida | +34% ALFWorld, +10% WebShop (Yao et al., 2022) | Venceu zero-shot CoT em 10/10 datasets (Wang et al., 2023) |
A linha de evidência medida é o teste de honestidade. O ReAct tem um paper de 2022 com números por tarefa; o plan-and-execute tem uma varredura de dez datasets e nenhum número de manchete, o que é uma razão para ele ser citado mais do que benchmarkado.
from anthropic import Anthropic
client = Anthropic()
def react(question: str, tools: list, max_steps: int = 8) -> str:
messages = [{"role": "user", "content": question}]
for _ in range(max_steps):
msg = client.messages.create(
model="claude-sonnet-4-5",
max_tokens=1024,
tools=tools,
messages=messages,
)
if msg.stop_reason == "end_turn":
return msg.content[0].text
messages.append({"role": "assistant", "content": msg.content})
messages.append({"role": "user", "content": dispatch(msg.content)})
return "Stopped: hit the iteration cap with no final answer."Esse limite de iterações não é opcional. Um loop ReAct sem saída queima tokens até o seu orçamento acabar; max_steps é o guarda-corpo mais barato deste post inteiro. O plan-and-execute precisa do mesmo guarda um nível acima: limite os replanejamentos, não apenas as etapas, ou um plano falho vai se regenerar indefinidamente.
Os Padrões de Qualidade: Reflexão, Avaliador-Otimizador e Human-in-the-Loop
Padrões de qualidade gastam tokens extras para elevar a qualidade da saída, e só valem a pena quando a qualidade é mensurável. A reflexão (a Anthropic chama de avaliador-otimizador) roda um gerador e um crítico em loop: um modelo rascunha, outro critica, o rascunho melhora. Se você não consegue pontuar a saída com um teste, uma rubrica ou um modelo avaliador, o crítico é só token extra discutindo consigo mesmo. Construir esse pontuador é a parte difícil; nosso guia sobre avaliação de agentes em produção cobre o que uma função de pontuação utilizável exige. Quando a pré-condição se sustenta, o padrão é um seguro barato: a Anthropic descreve o avaliador-otimizador como duas chamadas de LLM em loop, uma gerando e uma criticando, o que compra um ganho de qualidade mensurável por alguns segundos extras de latência.
O modo de falha que ninguém diagrama é a reflexão desgovernada: o crítico e o gerador ficam em loop para sempre, ou pior, oscilam. A correção é um limite duro de iterações mais uma quebra por ausência de melhoria, escrita em código em vez de pedida no prompt:
def refine(task: str, score_fn, max_rounds: int = 4) -> str:
best = generate(task)
best_score = score_fn(best)
for _ in range(max_rounds):
critique = critic(task, best)
candidate = generate(f"{task}\n\nCritique:\n{critique}")
score = score_fn(candidate)
if score <= best_score:
break # no improvement: stop spending tokens
best, best_score = candidate, score
return bestHuman-in-the-loop é uma camada de controle, não um oitavo padrão. Ela envolve qualquer um dos sete: um humano aprova antes de uma etapa irreversível rodar. Apenas 2 dos 6 principais resultados da SERP a cobrem. Coloque o portão em ações irreversíveis, gastos reais e qualquer coisa que saia do seu sistema como comunicação externa. Todo o resto deveria rodar sem supervisão ou não rodar. O próprio portão deve ser código burro, não outro LLM: uma fila de aprovação, um limite de gasto, uma allowlist de domínios. Colocar um modelo para decidir se um humano deve olhar derrota o propósito.
Multiagente Vale 15× os Tokens? O Que os Benchmarks Realmente Dizem
Orquestrador-trabalhadores é o sétimo padrão: um agente líder decompõe uma tarefa, delega pedaços a agentes trabalhadores e mescla o que eles retornam. "Multiagente" é esse padrão levado ao extremo, não um formato separado, então a pergunta é realmente quando o orquestrador justifica seu overhead.
Quando você deve usar multiagente em vez de um único agente? Somente quando um único agente estagna abaixo de cerca de 85% de precisão na tarefa. Essa regra de bolso circulou no r/AI_Agents (2026-04-23) junto com o estudo do Google Research, e bate com os dados medidos: acima dessa barra, agentes adicionais somam custo e amplificação de erros sem somar precisão.
Aqui está cada número publicado que conseguimos verificar, lado a lado:
| Descoberta | Número | Fonte | Data | Medido em |
|---|---|---|---|---|
| Multiagente venceu o Opus 4 single-agent | +90,2% | Anthropic | 2025-06-13 | Avaliação interna de pesquisa (Opus 4 líder, subagentes Sonnet 4) |
| Coordenação centralizada venceu um agente | +80,9% | Google Research | 2026-01-28 | Raciocínio financeiro paralelizável, 180 configurações |
| Multiagente em planejamento sequencial | −39% a −70% | Google Research | 2026-01-28 | Tarefas sequenciais (−70% no PlanCraft) |
| Amplificação de erros | 17,2× independente vs 4,4× centralizado | Google Research | 2026-01-28 | 180 configurações |
| Uso de tokens versus chat | 4× agente único, 15× multiagente | Anthropic | 2025-06-13 | Tarefas de pesquisa |
| Predição de arquitetura | 87% das configs não vistas, R² = 0,513 | Blog do Google Research (2026-01-28) | 2026-01-28 | Configurações de tarefa não vistas |
Uma ressalva antes de você clicar: cada número do Google Research acima vem do post de blog de 2026-01-28, e o paper por trás dele (arXiv 2512.08296) foi revisado desde então, então a versão atual relata 260 configurações e R² = 0,373 em vez dos 180 e 0,513 do blog. A direção se sustenta de qualquer forma; os números exatos dependem de qual versão você está lendo.
Duas dessas linhas são frequentemente citadas errado, então aqui está a aritmética. O número de 15× da Anthropic é medido contra uma interação de chat, e o número de agente único deles é 4×. Então multiagente custa aproximadamente 15 / 4 = 3,75× os tokens de um único agente, não 15×. E a amplificação de erros de 17,2× do Google Research para agentes independentes versus 4,4× para centralizados significa que um orquestrador contém aproximadamente 17,2 / 4,4 = 3,9× menos amplificação de erros do que deixar agentes rodarem sem supervisão.
Lendo o relato da Anthropic contra os números do Google Research, nossa leitura é que a decomponibilidade, não a contagem de agentes, é a variável que decide. A tarefa de pesquisa da Anthropic se dividia de forma limpa em buscas paralelas, então mais agentes ajudaram. As tarefas de planejamento sequencial do Google não se dividiam, então mais agentes atrapalharam uns aos outros.
Isso bate com o que os praticantes dizem quando os sistemas chegam em produção. No r/AI_Agents, um thread intitulado "Multi agent systems are a total nightmare in production" (2026-04-23, 56 pontos, 68 comentários) veio de um OP que já embarcou mais de 20 sistemas para clientes: "Os que realmente continuam rodando… são quase constrangedoramente simples", e "toda vez que um agente fala com outro, você perde contexto. É como aquele jogo do telefone sem fio." O comentário principal destila a seção inteira: "tente resolver seu problema com um único agente. Se esse agente tem >85% de precisão, um sistema multiagente não vai agregar mais valor nenhum."
Antes de adicionar um agente, tente as correções baratas que a Anthropic mediu: uma descrição de ferramenta melhorada produziu uma queda de 40% no tempo de conclusão de tarefa, e chamadas de ferramenta paralelas cortaram o tempo de pesquisa em até 90%. Ambas vencem um segundo agente em custo. Se você realmente for de multiagente numa ferramenta real, os subagents do Claude Code são orquestrador-trabalhadores que você pode inspecionar linha por linha.
Mesmo Padrão, Cinco Nomes: Uma Tabela Rosetta de Frameworks
Os mesmos quatro formatos aparecem sob nomes diferentes na documentação de cada fornecedor, e a nomenclatura não se transfere entre frameworks. "Magentic" e "group chat" da Microsoft não significam nada no OpenAI SDK até você traduzi-los, e esse imposto de tradução é um custo real que esta tabela remove.
| Formato subjacente | Anthropic (2024-12-19) | Blog do Claude (2026-03-05) | OpenAI Agents SDK | Vercel AI SDK | Microsoft Learn | Google Cloud |
|---|---|---|---|---|---|---|
| Etapas encadeadas | Prompt chaining | Sequential | Code orchestration | Sequential processing | Sequential | Sequential |
| Classificar e despachar | Routing | n/a | Handoff | Routing | Handoff | Custom logic |
| Fan-out / fan-in | Parallelization (sectioning, voting) | Parallel (fan-out/fan-in) | Code orchestration | Parallel processing | Concurrent | Parallel |
| Líder mais trabalhadores | Orchestrator-workers | n/a | Agents-as-tools | Orchestrator-worker | Magentic | Coordinator, hierarchical task decomposition |
| Gerador mais crítico | Evaluator-optimizer | Evaluator-optimizer | LLM orchestration | Evaluator-optimizer | Group chat | Review-and-critique, iterative refinement |
| Loop razão-ação | Autonomous agents | n/a | LLM orchestration | n/a | n/a | ReAct |
| Portão humano | (camada de controle) | n/a | n/a | n/a | n/a | Human-in-the-loop |
Cinco fornecedores, cinco vocabulários, três ou quatro formatos reais. O custo prático aparece quando você troca de framework: um time migrando do Agent Framework da Microsoft para o OpenAI SDK precisa remapear "magentic" para agents-as-tools e "group chat" para um grafo de handoff antes de uma única linha de código ser transferida. A taxonomia de onze nomes do Google Cloud é a mais longa, a lista de sete nomes da Anthropic é a mais citada, e os três nomes do blog do Claude são os que você vai implementar primeiro. Leia o formato, depois leia o SDK. Os cabeçalhos das colunas são as próprias documentações: Anthropic, o blog do Claude, o OpenAI Agents SDK, o Vercel AI SDK, o Microsoft Learn e o Google Cloud. Depois que você enxerga os formatos, escolher um framework é uma decisão separada; nosso resumo dos melhores frameworks de agentes de IA em 2026 e a comparação LangGraph vs CrewAI vs OpenAI Agents SDK cobrem essa.
Quando Você NÃO Deve Usar um Workflow de Agente?
Com frequência, você não deve. A escada de decisão mais votada no r/AI_Agents (2026-03-09) coloca de forma simples: "Se instruções if…then resolvem, use isso. Depois, se workflows tradicionais resolvem, use isso. Caso contrário, use IA agêntica." Dois dos três principais resultados da SERP são documentação de cloud que estruturalmente não pode mandar você construir menos. Nós podemos. Os dados deste post apontam na mesma direção: os dois maiores ganhos medidos (+80,9% e +90,2%) vieram de tarefas que se decompunham de forma limpa, e a pior perda medida (−70%) veio de forçar agentes numa tarefa que não se decompunha.
Os modos de falha têm nome, e cada um agora tem um número associado:
- Perda de contexto nos handoffs: cada mensagem de agente para agente descarta estado (a reclamação do "telefone sem fio" no r/AI_Agents, 2026-04-23).
- Amplificação de erros: 17,2× para agentes independentes versus 4,4× centralizado (Google Research, 2026-01-28).
- Loops de reflexão desgovernados: limite as iterações e quebre quando não houver melhoria, como no código acima.
- Degradação de tarefas sequenciais: 39–70% pior quando você paraleliza trabalho que não se decompõe (Google Research, 2026-01-28).
- Estouro de custo: aproximadamente 15× os tokens de chat para um sistema multiagente (Anthropic, 2025-06-13).
Cada um desses modos de falha tem um limite que você escreve em dez linhas de código, e o limite é sempre mais barato do que o agente que você estava prestes a adicionar.
Walden Yan, da Cognition, fez a mesma defesa do lado de quem constrói em Don't Build Multi-Agents (2025-06-12): "Compartilhe contexto, e compartilhe rastros completos dos agentes, não apenas mensagens individuais", e "Ações carregam decisões implícitas, e decisões conflitantes carregam resultados ruins." A comparação do r/AI_Agents é aquela a que voltamos sempre: "multiagente começa a parecer muito com microsserviços. Poderoso quando os limites são reais, doloroso quando são inventados."
Como a Techsy Aborda a Escolha de Padrões
A escada abaixo é a nossa leitura dos achados do Google Research e da Anthropic mais os threads de praticantes, não um resultado medido nosso. Nós a percorremos de cima a baixo e paramos na primeira linha que se encaixa:
| Condição | Faça isso |
|---|---|
| O caminho é determinístico e conhecido? | Escreva código, sem LLM |
| Um agente já atinge ~85% de precisão? | Pare, embarque |
| As subtarefas são genuinamente independentes? | Paralelize |
| A qualidade da saída é mensurável? | Adicione avaliador-otimizador |
| Os domínios de contexto são genuinamente separados? | Só agora, orquestrador-trabalhadores |
Três coisas decorrem dos dados deste post. Comece sequencial, porque a Anthropic diz para fazer isso e nada na SERP desmente. Paralelize só o que se decompõe, porque a mesma mudança de coordenação medida em +80,9% também foi medida em −70%. E trate um segundo agente como último recurso, porque a conta de tokens é real e a amplificação de erros é medida. O fio condutor é que adicionar agentes é um movimento de escala, não de qualidade: os benchmarks recompensam isso só onde o trabalho se divide, e os threads de praticantes confirmam isso em todo o resto. Se você quer uma segunda opinião sobre uma arquitetura antes de construí-la, receba uma consultoria gratuita.
Perguntas Frequentes
Quais são os 7 padrões de agentes de IA?
Os sete são sequencial (encadeamento de prompts), roteamento (handoff), paralelização (fan-out/fan-in), orquestrador-trabalhadores, reflexão (avaliador-otimizador), ReAct e plan-and-execute. Eles se repetem sob nomes diferentes em toda taxonomia de fornecedor, da Anthropic ao Google Cloud. Human-in-the-loop é discutido junto com eles, mas é uma camada de controle que envolve qualquer um dos sete, não um oitavo padrão.
Quais são as 4 etapas de um workflow de agente de IA?
Planejar, agir, observar, refletir. O modelo planeja um próximo passo, age chamando uma ferramenta, observa o resultado da ferramenta entrando no contexto e então reflete se o objetivo foi atingido, repetindo o loop ou parando. Cada padrão deste post é uma forma diferente de conectar essas quatro etapas.
Qual é a diferença entre um workflow de IA e um agente de IA?
Um workflow segue caminhos de código predeterminados; um agente deixa o modelo dirigir seu próprio fluxo de controle. A regra da Anthropic: workflows para previsibilidade em tarefas bem definidas, agentes para flexibilidade quando decisões dirigidas pelo modelo são necessárias em escala. A maioria dos sistemas de produção são workflows com alguns passos de agente dentro.
ReAct vs plan-and-execute: qual devo usar?
Use ReAct quando o próximo passo depende do que a última ferramenta retornou e a rota pode mudar no meio da execução. Use plan-and-execute quando a rota é previsível de antemão e replanejar após cada etapa desperdiçaria tokens. O ReAct mediu +34% no ALFWorld (Yao et al., 2022); o plan-and-execute venceu zero-shot CoT em dez datasets (Wang et al., 2023).
Preciso de um framework como LangGraph para usar esses padrões?
Não. Cada bloco de código deste post é uma chamada simples de SDK, e os padrões são anteriores aos frameworks que os nomeiam. Um framework se justifica pela persistência de estado, retentativas e rastreamento, não pelo padrão em si. Se você está escolhendo um, nossa comparação de frameworks cobre os tradeoffs.
Como impeço um loop de reflexão de rodar para sempre?
Dois guardas, ambos em código: um limite duro de iterações (usamos 4 rodadas) e uma quebra por ausência de melhoria que para no momento em que a reescrita do crítico não pontua melhor que o rascunho atual. Não confie no prompt para encerrar o loop; o modelo não faz ideia do que as coisas custam.
Quando um único agente é suficiente?
Quando ele atinge aproximadamente 85% de precisão na tarefa. Essa heurística, que circulou no r/AI_Agents (2026-04-23) junto com o estudo do Google Research, bate com os benchmarks: acima dessa barra, agentes extras somam custo e amplificação de erros sem somar precisão. Meça a linha de base do agente único antes de desenhar qualquer coisa maior.
Onde encontro exemplos de padrões de workflow de agentes de IA com código?
Os cinco blocos Python acima cobrem sequencial, roteamento, paralelização, ReAct e reflexão, todos como chamadas simples de SDK que você pode copiar direto. Para exemplos com o sabor dos fornecedores, o Vercel AI SDK traz TypeScript executável por padrão e a documentação do OpenAI Agents SDK cobre handoffs e agents-as-tools. Os links para ambos estão na lista de Fontes abaixo.
Fontes
- Anthropic, Building Effective Agents (2024-12-19)
- Anthropic, How we built our multi-agent research system (2025-06-13)
- Google Research, Towards a science of scaling agent systems (2026-01-28); artigo: arXiv 2512.08296
- Yao et al., ReAct: Synergizing Reasoning and Acting in Language Models (v3 2023-03-10)
- Wang et al., Plan-and-Solve Prompting (ACL 2023)
- Claude by Anthropic, Common workflow patterns for AI agents (2026-03-05)
- OpenAI Agents SDK, Orchestrating multiple agents
- Vercel AI SDK, Workflow Patterns
- Microsoft Learn, AI Agent Orchestration Patterns (atualizado em 2026-05-12)
- Google Cloud, Choose a design pattern for your agentic AI system (2026-05-28)
- Cognition (Walden Yan), Don't Build Multi-Agents (2025-06-12)
- r/AI_Agents, Multi agent systems are a total nightmare in production (2026-04-23); Wait, are workflows actually better than multi-agent systems? (2026-03-09)