Orquestração de agentes: deixar o modelo decidir ou escrever um script?

Fala aí, beleza? A pergunta que separa quem só usa agente de quem monta fluxo com agente é uma só: quem segura o volante, o modelo ou o código?

Ela aparece sempre no mesmo ponto, quando a tarefa fica grande demais pra caber em um agente só

Aqui a gente compara os dois lados por três réguas que doem no dia a dia: previsibilidade, repetição do resultado e em que tipo de tarefa cada abordagem quebra

O que muda quando o controle de fluxo sai do modelo e vai para o código

A régua não é minha, é da própria Anthropic, e ela é bem seca

No guia de engenharia sobre agentes eficazes, workflow é o sistema em que LLMs e ferramentas são orquestrados por caminhos de código predefinidos

Já agente é o sistema em que o LLM dirige dinamicamente o próprio processo e o próprio uso de ferramentas

Ou seja: a diferença não está no modelo, está no LUGAR onde mora o controle de fluxo

Que padrões existem quando o fluxo é definido em código?

O mesmo guia cataloga cinco formatos de workflow:

• prompt chaining (encadeamento)
• routing (roteamento)
• parallelization (paralelização)
• orchestrator-workers
• evaluator-optimizer

Se você já brincou de orquestração multi-modelo no n8n, a ideia é bem semelhante: alguém precisa dizer o que vai antes, o que vai depois e o que roda junto

A diferença é que ali o fluxo é um canvas, e aqui o fluxo é código

E a forma concreta disso no Claude Code?

Os Dynamic Workflows chegaram em 28 de maio de 2026, no mesmo anúncio do Opus 4.8

Na prática, um dynamic workflow é um arquivo JavaScript que orquestra vários subagentes com um conjunto PEQUENO de primitivas, segundo a documentação oficial de workflows: agent, parallel, pipeline e phase

Quatro peças, só isso

O script não é um segundo cérebro conversando com o primeiro: ele é o coordenador, e o modelo vira operário de etapa

Fluxo decidido pelo modelo x orquestração por script: comparação direta

Repara na última linha da tabela, porque ela é a mais subestimada

Validação de schema e resume não moram no seu script, moram no runtime

E tem um detalhe que muda o jogo do contexto: no modelo de dynamic workflow, o orquestrador guarda apenas a resposta final verificada, e não o rastro de cada etapa intermediária

Muito massa isso, porque é exatamente o rastro intermediário que entope o contexto quando o agente decide tudo sozinho

Em que tipo de tarefa cada abordagem quebra

Onde o script ganha:

A Anthropic cita como casos de uso justamente as tarefas grandes demais para um agente só:

• migrações em escala de base de código
• auditorias de segurança
• caça a bugs espalhados
• revisão de performance
• análise de arquitetura

O padrão comum aqui? Você JÁ SABE a lista de itens antes de começar

50 arquivos, 12 rotas, 8 módulos… quando existe uma lista, existe fan-out, e fan-out é trabalho de código, não de improviso

Onde o script atrapalha:

Tarefa exploratória, de caminho desconhecido, ou simplesmente pequena

Se o próximo passo depende do que a rodada anterior descobrir, escrever etapas e condições antes de saber o que existe é complexidade sem retorno

E isso bate com a recomendação mais repetida do guia: buscar a solução mais simples possível e aumentar a complexidade só quando necessário, o que pode significar não construir um sistema agêntico nenhum

Como rodar orquestração por script no Claude Code hoje

1. Confira a versão: dynamic workflows exigem Claude Code v2.1.154 ou posterior

O erro comum deste passo é tentar debugar o prompt achando que ele está mal escrito, quando o problema é versão antiga que simplesmente não conhece o recurso

2. Confira o acesso: está disponível em todos os planos pagos, com acesso à API da Anthropic, e também em Amazon Bedrock, Google Cloud Agent Platform e Microsoft Foundry

3. Pra transformar UMA tarefa específica em dynamic workflow, escreva a palavra literal ultracode em qualquer ponto do prompt:

varrer os módulos de autenticação atrás de uso inseguro de chave de API, ultracode

O erro comum deste passo é achar que isso mudou a sessão inteira: não mudou, o nível de esforço da sessão continua igual

4. Pra sessão inteira, aí sim, rode o comando de esforço:

/effort ultracode

Esse ajuste combina raciocínio xhigh com planejamento automático de workflows

5. Acompanhe as execuções pela interface:

/workflows

6. Gostou de uma execução? Selecione ela e pressione s pra salvar

O workflow salvo vira um slash command, ou seja, você chama de novo sem reescrever nada

7. Os salvos ficam em .claude/workflows/ (escopo do projeto) ou em ~/.claude/workflows/ (uso pessoal entre projetos)

Tome cuidado aqui: salvar no escopo errado é o clássico "funcionava no outro projeto" 😅

O que aparece quando o modelo dirige sozinho: teste real

No vídeo abaixo eu rodo um modelo alternativo dentro do Claude Code, sem script nenhum, deixando o agente escolher a ordem das coisas

E o começo foi ótimo: no primeiro prompt ele montou sozinho uma lista de tarefas e PAROU pra pedir aprovação do plano antes de executar, coisa que eu não via em outros modelos

O plano veio em inglês mesmo com meu prompt em português, sem eu ter pedido isso, detalhe curioso

Aí veio a parte que interessa pro nosso tema: o fluxo travou no terminal e eu tive que intervir com um prompt manual, porque o modelo ficou parado decidindo o NOME do projeto… sendo que o prompt inicial já trazia essa informação

Esse é o ponto que eu peço pra você vigiar: quando o agente decide sozinho, ele consegue gastar tempo em decisão já resolvida no enunciado

Na etapa de integração foram muitas idas e voltas entre alterações, e isso puxou o consumo de tokens pra cima

Os números do meu teste: a primeira versão levou cerca de 20 minutos, contra os cerca de 10 minutos que eu considero normal pro setup inicial de projeto

O servidor subiu na porta 3000 e o projeto ficou em torno de 70% pronto, ainda pedindo muitos prompts

Teve até decisão executada de forma literal e pobre: pedi algo de produto e veio só a expressão regular na linguagem pedida, quando o útil ali seria uma função de teste, o que na prática deixou aquele pedaço sem serventia

Uma coisa eu fiz na mão e recomendo: escrevi no prompt as regras que NÃO podiam ser quebradas (chave de API só no servidor, nunca no navegador) em vez de deixar a decisão pro modelo

E conferi o consumo direto no painel do provedor pra ter certeza de qual modelo estava sendo disparado, porque perguntar pra IA sobre ela mesma não é fonte 😀

Amarrando no tema: quando o modelo escolhe a ordem, o começo é rápido e o fim é indeterminado

É exatamente esse último trecho que o script tenta tornar repetível

Veredito: quando vale escrever o script de orquestração

Sem meio-termo: script de orquestração NÃO é upgrade automático

É troca de liberdade por previsibilidade, e toda troca tem preço

Vale quando a tarefa se repete, tem itens claros pra distribuir e precisa entregar resultado igual em duas rodadas

Não vale quando o próximo passo depende do que a rodada anterior descobrir, porque aí você está escrevendo condição pra um caminho que ainda não conhece

E a régua final continua sendo a mais chata e a mais certa: complexidade só quando necessário

Se um prompt bem escrito resolve, orquestração de agentes ali é peso morto

Conclusão

Workflow é fluxo por caminhos de código predefinidos, agente é o LLM dirigindo o próprio processo, e a escolha entre os dois é sobre previsibilidade, não sobre modernidade

Meu próximo passo sugerido pra você é bem concreto: pegue uma tarefa real, deixe o modelo decidir sozinho primeiro, e abra /workflows pra observar onde a ordem ficou instável

Aí sim, com a instabilidade mapeada, salve aquela execução como workflow reutilizável e rode de novo

Faça o teste e compare as duas rodadas, é onde a ficha cai 🙂

até o próximo post!