Flows da Anthropic: Claude orquestra agentes sozinho

Quando orquestrar agentes vira o gargalo

Dynamic workflows chegaram para resolver um problema que todo operador de agentes já sentiu na pele. Você coloca cinco, dez, vinte Claudes para trabalhar em paralelo e de repente o seu trabalho vira revisar PR, aprovar execução, juntar resultado parcial e impedir que um agente pise no outro. A promessa da Anthropic é simples e incômoda ao mesmo tempo. E se o próprio Claude decidisse como dividir o trabalho, quantos agentes chamar e como conectar tudo?

Foi isso que CJ Avilla e Harrison Stall, do time técnico da Anthropic, mostraram no AI Engineer New York 2026. O recurso, batizado de flows, foi lançado na sexta anterior ao evento e posicionado como um novo tipo de orquestração multiagente para workloads mais ambiciosos. Não é mais um harness fixo por tarefa. É o Claude escrevendo o próprio programa de orquestração.

O fato sem hype

A ideia central é direta. Nos Claude Managed Agents, antes você precisava configurar um coordenador e um roster de subagentes. Você definia quem faz o quê, em qual ordem, com qual contexto. Com dynamic workflows, o agente líder recebe o objetivo, cria um plano e depois gera o código de orquestração que lança agentes, coleta resultados e gerencia o fluxo de informação entre fases.

Na demo mostrada no palco, o exemplo foi propositalmente simples. Um scanner de watchlist de ações. Uma fase de scan distribuía tickers individuais para agentes com contextos isolados. Depois, uma fase de review consolidava os achados e gerava um relatório. Longe de ser o caso de uso ambicioso que a Anthropic quer vender, mas útil para mostrar o padrão. Dividir em unidades de trabalho discretas e verificáveis, executar em paralelo e depois reduzir tudo em uma etapa de controle.

Os apresentadores fizeram questão de puxar a analogia com sistemas operacionais. Do Unix original de Ken Thompson até o Linux sair das mãos de Linus Torvalds para camadas de mantenedores confiáveis. O recado é claro. Agentes também precisam de organização para sair de tarefas de um prompt só e encarar projetos grandes, longos e com dependências.

Como funciona na visão de operador

Pensa em flows como uma camada acima do agent loop. Em vez de você codificar o DAG de tarefas, o Claude escreve esse DAG em tempo de execução. Na prática, isso deve funcionar em três movimentos. Primeiro, decomposição do objetivo em fases. Segundo, geração de um programa de orquestração que define paralelismo, inputs e critérios de conclusão por fase. Terceiro, execução com coleta de resultados e passagem de contexto resumido, não do histórico inteiro, entre agentes.

O ponto crítico aqui é contexto isolado. Cada subagente trabalha com um escopo pequeno, o que reduz contaminação e alucinação cruzada. O agente líder atua mais como um planejador e redutor. Isso é bom para latência, porque permite paralelizar bem, e bom para qualidade, porque evita aquele monólito de prompt gigante que tenta fazer tudo de uma vez.

O que ainda não está totalmente claro é custo e controle. Pelo que surgiu no Q and A, o número de agentes não é mágico. Depende de evals e de defaults mais conservadores, com paralelização maior só quando você pede explicitamente. Faz sentido. Sem limite, até um scan bobo de tickers poderia explodir em centenas de subagentes e estourar seu budget de tokens em minutos. Você ainda pode injetar subagentes especialistas pré-configurados via agent config, o que é essencial para ancorar comportamento em produção.

Onde o custo mora

Minha inferência técnica, e aqui é inferência, não documentação oficial. O custo extra vai estar na camada de planejamento e na redução. O líder vai gastar tokens raciocinando sobre topologia, e cada handoff entre fases vai exigir sumarização. Isso é overhead que não existia num script fixo. Em troca, você economiza engenharia manual de orquestração e ganha adaptabilidade quando a tarefa muda no meio do caminho. Para jobs curtos e previsíveis, esse overhead provavelmente não compensa. Para jobs longos, com ramificações e necessidade de replanejar, pode compensar muito.

O que isso muda na prática

Quem ganha primeiro é o time que já vive de multiagente e sente o peso de ser o bottleneck. Se você hoje mantém um roster na unha, com prompts de coordenação frágeis e lógica de retry espalhada, flows tiram um pedaço desse trabalho braçal. O Claude passa a cuidar das interconexões entre fases e entrega unidades de trabalho verificáveis. Isso reduz código boilerplate e acelera experimento.

Quem perde, pelo menos no curto prazo, é quem construiu tooling em volta da orquestração manual. Frameworks caseiros de roteamento, filas customizadas para agentes, dashboards que assumem topologia fixa. Tudo isso vai precisar de ajuste quando a topologia passa a ser decidida pelo modelo em runtime. Observabilidade vira ainda mais importante. Você vai precisar logar não só o que cada agente fez, mas por que o líder escolheu aquela divisão.

Na prática, ajuste uma coisa agora. Defina orçamento por flow, não por agente. Limite de agentes paralelos, limite de tokens por fase e critério de parada claro. Depois rode em modo conservador com uma tarefa que você já conhece bem e compare com seu pipeline fixo em três métricas. Custo total, latência p95 e taxa de retrabalho. Se o flow não ganhar em pelo menos duas, ele ainda é demo para o seu caso.

• Ação prática: crie um flow piloto com defaults baixos de paralelismo, fixe dois subagentes especialistas para as etapas críticas e exija output estruturado e verificável por fase antes de liberar escala.
• O que medir: tokens por unidade concluída, número de agentes spawnados por execução e quantas vezes o líder replanejou no meio do job.

A tensão que fica

Aqui está a minha dúvida real. Isso escala ou só move o gargalo de lugar. Antes o gargalo era você conectando agentes. Agora o gargalo pode virar o líder alucinando uma topologia ruim, paralelizando demais ou de menos, ou perdendo informação crítica na sumarização entre fases. Auto-orquestração soa autônoma, mas na prática exige evals melhores, não piores. Sem evals por fase, você só descobre o erro no relatório final, quando já gastou o budget.

Tem também a questão da depuração. Quando um pipeline fixo quebra, você sabe onde olhar. Quando um programa de orquestração gerado pelo modelo quebra, o bug pode estar no plano, no particionamento ou na junção. Isso pede um novo tipo de trace, quase como debug de sistema distribuído, com replay por fase. Sem isso, time de plataforma vai sofrer para colocar flows em produção com SLA.

Conclusão

Dynamic workflows são a evolução natural dos Claude Managed Agents. Menos configuração manual, mais decisão em runtime pelo próprio modelo. Para workloads longos e ramificados, vale testar já com limites rígidos. Para fluxos simples e repetitivos, o roteador fixo ainda deve vencer no custo. A pergunta que fica é direta. Você confiaria no Claude para desenhar a sua arquitetura de agentes em produção, ou vai manter o líder sob rédea curta por mais um ciclo.