A maioria dos usuários do Claude Code ainda escreve seus fluxos de trabalho manualmente. Eles encadeiam prompts, copiam saídas, colam no próximo prompt, corrigem o que deu errado e repetem.
9 em cada 10 desenvolvedores nunca experimentaram os Fluxos de Trabalho Dinâmicos (Dynamic Workflows) nem uma vez, mesmo tendo sido lançados há duas semanas.
Eles escrevem 50 prompts quando um único fluxo de trabalho resolveria. Este é o roteiro de 14 etapas e os 6 padrões que os próprios engenheiros da Anthropic realmente usam — para migrações, pesquisa, classificação, causa raiz, triagem e avaliações.
Siga meu Substack para receber novidades frescas sobre IA:
Os Fluxos de Trabalho Dinâmicos foram lançados no Claude Code em 28 de maio de 2026. O ambiente padrão do Claude Code é construído para codificação — e funciona bem para a maioria das tarefas de codificação. Mas há classes de trabalho onde uma única janela de contexto começa a falhar: tarefas de longa duração, massivamente paralelas, altamente estruturadas ou adversariais.
Para essas, a Anthropic costumava construir ambientes personalizados (Research, Code Review, agent teams). Com os Fluxos de Trabalho Dinâmicos, o Claude escreve esse ambiente para você em tempo real, personalizado para sua tarefa, em JavaScript.
14 etapas. 6 padrões. Um fluxo de trabalho em vez de cinquenta prompts.
Parte 1 · O Modelo Mental
01. Um fluxo de trabalho é um ambiente que o Claude escreve.
O ambiente padrão do Claude Code faz o Claude planejar e executar na mesma janela de contexto. Para a maioria dos trabalhos de codificação, isso é ótimo. Para trabalhos de longa duração, paralelos ou adversariais, ele falha.
Um Fluxo de Trabalho Dinâmico é o Claude escrevendo seu próprio ambiente personalizado para a tarefa — um arquivo JavaScript com algumas funções especiais que criam e coordenam subagentes, além de JavaScript padrão (Math, JSON, Array) para processar os dados que fluem entre eles.
Três coisas que isso oferece e que o ambiente padrão não consegue:
- Isolamento por agente. Cada subagente tem sua própria janela de contexto com um objetivo focado. Sem contaminação cruzada.
- Escolha de modelo por agente. O fluxo de trabalho escolhe qual modelo cada subagente usa — Opus para raciocínio difícil, Haiku para exploração barata, Sonnet para o meio termo.
- Nível de isolamento por agente. Worktree (checkout git isolado) ou remoto (sem checkout). O fluxo de trabalho decide o que cada agente precisa.
Inicie um perguntando diretamente ao Claude ("crie um fluxo de trabalho que...") ou com a palavra de gatilho ultracode. Se um fluxo de trabalho for interrompido — ação do usuário, fechamento do terminal — retomar a sessão continua de onde parou.
02. Os 3 modos de falha que os fluxos de trabalho resolvem.
Para saber quando um fluxo de trabalho é a ferramenta certa, você precisa saber o que ele corrige. Quanto mais tempo o Claude trabalha em uma tarefa complexa em uma única janela de contexto, mais ele se torna suscetível a três modos de falha específicos — nomeados diretamente no artigo de lançamento da Anthropic:
- Preguiça do agente — O Claude para antes de concluir uma tarefa complexa e de várias partes e declara que terminou após progresso parcial. Aborda 20 dos 50 itens em uma revisão de segurança e chama o resto de "resolvido".
- Viés de autopreferência — O Claude prefere seus próprios resultados quando solicitado a verificá-los ou julgá-los com base em uma rubrica. Um verificador com interesse no resultado não pode ser um verificador justo.
- Desvio de objetivo — A perda gradual de fidelidade ao objetivo original ao longo de muitas interações, especialmente após compactação. Cada etapa de sumarização é com perdas. Restrições do tipo "Não faça X" desaparecem silenciosamente na interação 47.
Um fluxo de trabalho resolve todos os três estruturalmente: Claudes separados com seus próprios contextos, objetivos focados e estado isolado. Se sua tarefa sofre de algum desses padrões — esse é o sinal para recorrer a um fluxo de trabalho.
03. Fluxos de trabalho estáticos vs. dinâmicos.
Você pode já ter construído fluxos de trabalho estáticos usando o Claude Agent SDK ou claude -p — coordenando várias instâncias do Claude Code juntas.
- Fluxos de trabalho estáticos são genéricos: escritos uma vez para lidar com todos os casos extremos. Eles funcionam, mas precisam ser conservadores.
- Fluxos de trabalho dinâmicos são diferentes: o Claude escreve este fluxo de trabalho para esta tarefa. O ambiente é feito sob medida. Abaixo está a mesma pergunta tratada de ambas as formas:
A razão pela qual a versão dinâmica vence não é a etapa de busca — ambos podem buscar.
É que o fluxo de trabalho consegue se moldar ao seu contexto: ler seu código de faturamento, verificar cada recurso com a documentação real do novo provedor, precificar no seu volume de transações e executar uma passagem adversarial "por que não migrar" contra sua própria resposta emergente.
Um ambiente estático não pode fazer isso porque não sabe que seu código existe.
04. A API principal. agent(), parallel(), pipeline().
Três funções fazem a maior parte do trabalho em um fluxo de trabalho. Conhecê-las é suficiente para ler qualquer fluxo de trabalho que o Claude escrever para você e para orientar o Claude quando você quiser uma forma específica.
parallel() é uma barreira: ela se expande, depois espera por tudo antes de retornar. pipeline() é streaming: cada item flui por cada estágio de forma independente.
Escolha pela pergunta: preciso de todos os resultados antes de poder fazer algo em seguida? Sim → parallel. Não → pipeline (mais barato, mais rápido no geral).
05. Classificar e agir. Direcione o trabalho antes de fazê-lo.
Um agente classificador decide o tipo de tarefa, então o fluxo de trabalho direciona para diferentes agentes ou comportamentos com base na resposta. Ou um classificador é executado no final, classificando saídas brutas em grupos para o que vier depois.
Quando esse padrão se paga:
- A tarefa é heterogênea — subtipos diferentes precisam de tratamento diferente.
- Você quer gastar o modelo caro apenas onde a complexidade exige (classificador no barato, depois direcione para Opus apenas quando necessário).
- A decomposição do trabalho é em si não trivial e se beneficia de um modelo decidindo a forma.
Exemplo: "Explique como o módulo de autenticação funciona." Um subagente classificador lê o código primeiro, estima a complexidade, então direciona a tarefa real de explicação para Sonnet para um módulo de 10 arquivos ou Opus para um de 100 arquivos. O modelo certo para o trabalho, decidido depois que o trabalho é compreendido.
06. Expandir e sintetizar. Muitos passos pequenos, um resultado mesclado.
Divida uma tarefa em muitos passos menores. Execute um agente em cada passo em paralelo. Sintetize os resultados em uma resposta.
A etapa de sintetizar é uma barreira — ela espera por cada agente expandido, então mescla suas saídas estruturadas.
Por que esse padrão domina na prática: ele resolve a falha de "muitas coisas ao mesmo tempo" do trabalho em contexto único. Cada subagente vê apenas sua parte. O orquestrador nunca se distrai com 50 detalhes não relacionados.
Cada passo se beneficia de sua própria janela limpa para que não haja contaminação cruzada.
Use isso quando:
- Você tem uma lista claramente enumerável de itens de trabalho (50 arquivos, 200 endpoints, 100 revisões).
- Cada item é independente — nenhum item precisa da saída de outro para começar.
- Você quer uma única resposta consolidada no final, não uma pilha de relatórios parciais.
1// Expandir: um agente por arquivo. Barreira: esperar por todos.2const reviews = await parallel(3 files.map(file => () => agent(4 `Revisar ${file} para problemas de segurança`,5 { model: "haiku", schema: IssueList }6 ))7)89// Sintetizar: um agente Opus mescla tudo.10const report = await agent(11 `Mesclar estas revisões em um relatório priorizado:\n${JSON.stringify(reviews)}`,12 { model: "opus" }13)
07. Verificação adversarial
Esta é a correção estrutural para o viés de autopreferência. Para cada agente criado, execute um agente criado separadamente que verifique adversariamente sua saída contra uma rubrica. O verificador nunca viu o trabalho original; ele não pode favorecê-lo.
O padrão é mais importante para:
- Verificação de alegações — cada declaração factual em um relatório tem seu próprio subagente verificador, verificando contra a fonte original.
- Revisão de código — o agente autor escreve a correção, o agente revisor (contexto separado) a revisa. Nunca o mesmo Claude julgando a si mesmo.
- Portões de qualidade — antes que qualquer artefato seja enviado, um adversário tenta encontrar o caso mais fraco contra ele. Se o adversário não conseguir, você envia.
A regra de pareamento: o verificador deve saber apenas a rubrica e o artefato, não quem o produziu. Caso contrário, a autopreferência retorna através de dicas no prompt.
08. Gerar e filtrar.
Gere várias ideias sobre um tópico, depois filtre-as por uma rubrica ou por verificação. Remova duplicatas. Retorne apenas as ideias da mais alta qualidade e testadas.
Onde esse padrão brilha:
- Brainstorming — 30 nomes de produtos, depois um verificador elimina clichês, conflitos de marca registrada e fonéticas fracas. Você vê 3.
- Geração de hipóteses — 5 abordagens diferentes para um problema, depois cada uma é pontuada contra suas restrições. O vencedor mereceu.
- Design de solução — 5 abordagens diferentes para um problema, depois cada uma é pontuada contra suas restrições. O vencedor mereceu.
O oposto de pedir ao Claude "a melhor resposta". Pedir a melhor resposta faz o Claude se comprometer cedo. Gerar e filtrar faz o Claude se comprometer tarde, depois que cada opção foi desafiada.
09. Torneio. Comparação pareada supera a pontuação absoluta.
Em vez de dividir o trabalho, faça os agentes competirem nele. Crie N agentes que cada um tenta a mesma tarefa usando abordagens diferentes, depois julgue os resultados de forma pareada até que um vença.
O julgamento comparativo é mais confiável do que a pontuação absoluta — especialmente para trabalhos baseados em gosto.
Por que isso supera classificar por pontuação: tentar classificar 1.000 itens em um prompt falha em duas frentes — a qualidade degrada e não cabe no contexto. Um torneio divide a chave entre agentes novos, cada um comparando apenas dois itens.
A própria chave vive em código de loop determinístico, não no contexto. Cada comparação é rápida, justa e isolada. A mesma ideia funciona para classificação baseada em gosto: escolhas de design, seleção de candidatos, priorização de conteúdo.
10. Loop até concluir.
Para tarefas com uma quantidade desconhecida de trabalho, faça um loop criando agentes até que uma condição de parada seja atendida — nenhuma nova descoberta, nenhum erro nos logs, teoria verificada — em vez de executar um número fixo de passagens.
Este padrão é a resposta para "continue até que esteja realmente concluído":
- Depuração de teste instável — reproduza, forme teorias, teste-as, até que uma teoria se sustente.
- Caça a bugs — continue encontrando bugs até que uma passagem completa retorne zero.
- Mineração de padrões — agrupe, identifique regras, até que nenhum novo grupo apareça.
Combine este padrão com /goal para definir um requisito de conclusão difícil ("não pare até que uma teoria funcione") e com /loop se você quiser que o fluxo de trabalho inteiro seja executado em um cronograma recorrente.
A chave e a condição de parada vivem no código; apenas a iteração ativa permanece no contexto.
11. Componha padrões para casos de uso reais. Um fluxo de trabalho, vários padrões.
Os 6 padrões raramente aparecem sozinhos. Um fluxo de trabalho real compõe 2-4 deles. A matriz abaixo emparelha cada caso de uso do artigo de lançamento da Anthropic com os padrões que ele tende a usar:
- Migrações e refatorações. Expandir (um agente por local de chamada/teste com falha em um worktree) → verificação adversarial (um agente separado revisa cada correção) → loop até concluir. Este é o padrão que a Anthropic usou para reescrever o Bun de Zig para Rust.
- Pesquisa aprofundada (a habilidade /deep-research). Expandir (buscas na web em paralelo) → verificação adversarial (cada alegação verificada independentemente) → sintetizar (um relatório citado).
- Verificação aprofundada de um rascunho. Identifique todas as alegações factuais (um agente) → expandir (um verificador por alegação, cada agente verifica contra a fonte) → meta-verificador (verifica se as fontes do verificador são de alta qualidade).
- Classificar 1.000+ itens. Torneio (etapas 5-9) — comparação pareada, classificação por balde ou chave. Julgamento comparativo, nunca pontuação absoluta.
- Adesão à memória e regras. Verificador por regra (expandir) → persona cética revisa as próprias regras para evitar falsos positivos.
- Investigação de causa raiz. Gere teorias a partir de evidências desconexas (agentes diferentes leem logs, arquivos, dados) → painel de verificadores e refutadores para cada teoria → loop até que uma sobreviva.
- Triagem em escala. Classificar e agir → deduplicar contra tickets existentes → tentar a correção ou escalar. Combine com /loop para triagem contínua.
- Exploração e gosto (design, nomenclatura, escolhas de UI). Gerar e filtrar (5-20 opções) → torneio com uma rubrica → classificar ou escolher.
- Avaliações leves. Execute o candidato em um worktree → agentes de comparação avaliam contra a rubrica → refine e reavalie. Mesma forma de um torneio, mas para avaliação, não classificação.
A maneira certa de internalizar estes: identifique qual modo de falha sua tarefa atual está sofrendo, depois escolha o padrão que o previne estruturalmente.
Desvio → expandir. Autopreferência → verificação adversarial. Aberto → loop até concluir. Difícil de pontuar → torneio.
12. Combine com /goal, /loop e orçamentos de tokens.
Fluxos de trabalho podem ser caros. Três controles os transformam de "legais, mas caros" em "uma ferramenta que executo sem supervisão".
- /goal define um requisito de conclusão difícil. Combine com o padrão de loop: "não pare até que uma teoria funcione." Sem /goal, um fluxo de trabalho para em um ponto de conclusão suave. Com /goal, ele itera até que a condição final real seja atendida.
- /loop executa o fluxo de trabalho inteiro em um cronograma recorrente. Use para fluxos de trabalho que você quer executando continuamente — triagem, atualizações semanais de pesquisa, verificação recorrente.
- Orçamentos explícitos de tokens. Diga ao Claude no prompt: "use 10k tokens." Isso define um limite para a execução do fluxo de trabalho. Sem um limite, um fluxo de trabalho ambicioso pode inflar para 5–10× os tokens que você esperava.
1> ultracode revisão adversarial rápida desta suposição:2 "mudar para Postgres elimina nosso rebalanceamento de shards."3 Use 5k tokens. /goal não pare até que você tenha4 um contra-exemplo ou três confirmações independentes.
Citando diretamente a equipe do Claude Code: "As melhores práticas ainda estão em desenvolvimento. Fluxos de trabalho dinâmicos geralmente usam mais tokens, então pense cuidadosamente sobre quando e como usá-los." A maioria das tarefas tradicionais de codificação não precisa de um painel de 5 revisores.
Pergunte a si mesmo: esta tarefa realmente precisa de mais poder de processamento? Se uma sessão regular do Claude Code a concluiria em cinco minutos, você não precisa de um fluxo de trabalho.
13. Use o padrão de quarentena para entrada não confiável.
Qualquer fluxo de trabalho que leia conteúdo público não confiável — tickets de suporte, relatórios de bugs, feedback de usuários, dados raspados — precisa assumir que esse conteúdo pode conter injeção de prompt.
A correção: quarentena. Impeça os agentes que leem o conteúdo não confiável de tomar qualquer ação de alto privilégio. Agentes separados, sem exposição ao conteúdo bruto, fazem a ação.
Qualquer fluxo de trabalho que processe conteúdo enviado pelo usuário (tickets de suporte, relatórios de bugs, feedback de clientes, mídias sociais), raspe páginas da web públicas ou seja executado contra a saída de uma API de terceiros.
Se a entrada não foi escrita por você ou por um colega de confiança, coloque-a em quarentena. Um agente leitor somente leitura de 30 linhas custa quase nada e remove uma classe inteira de risco de injeção de prompt.
14. Salve fluxos de trabalho. Envie-os como Skills.
Depois que um fluxo de trabalho funciona, salve-o: pressione s no menu do fluxo de trabalho. Fluxos de trabalho salvos vão para ~/.claude/workflows. De lá, você tem dois caminhos:
- Mantenha local — reutilize em seus próprios projetos.
- Envie como uma Skill — empacote o arquivo JavaScript dentro de uma pasta Skill, referencie-o em SKILL.md, e qualquer um que instalar a Skill executará o mesmo fluxo de trabalho.
Uma nuance prática que vale a pena saber: quando você empacota um fluxo de trabalho em uma Skill, peça ao Claude para tratar o fluxo de trabalho como um modelo, não como um script para executar literalmente.
Isso deixa espaço para o Claude adaptar a forma do fluxo de trabalho à tarefa específica em questão, mantendo a estrutura geral intacta. Especialmente útil para fluxos de trabalho como "verificação aprofundada" ou "triagem" que precisam se adaptar por caso de uso.
Os erros que desperdiçam tokens em fluxos de trabalho
- Recorrer a um fluxo de trabalho quando uma sessão regular do Claude Code resolveria. A maioria das tarefas tradicionais de codificação não precisa de um painel de 5 revisores.
- Sem orçamento de tokens. Fluxos de trabalho ambiciosos inflam para 5–10× o que você esperava sem um limite explícito.
- Um agente fazendo tanto o trabalho quanto a verificação. O viés de autopreferência faz o verificador favorecer o trabalhador. Eles devem ser separados.
- Tratar parallel() e pipeline() como intercambiáveis. A barreira importa — parallel espera por todos, pipeline faz streaming.
- Pular /goal em padrões de loop. O fluxo de trabalho para cedo no primeiro ponto de conclusão suave. /goal força a conclusão difícil.
- Deixar conteúdo não confiável alcançar o ator. A quarentena não é opcional depois que você processa qualquer coisa enviada pelo usuário.
- Classificar com pontuações absolutas. O julgamento comparativo é mais confiável. Use um torneio.
- Nunca salvar fluxos de trabalho funcionais. Repromptar a mesma forma toda semana. Salve com s, envie como uma Skill.
