Anthropic ensina Claude a montar sozinho o time de agentes que vai executar uma tarefa

Na AI Engineer New York 2026, a Anthropic detalhou o funcionamento dos dynamic workflows, recurso lançado na sexta-feira anterior ao evento que tira do desenvolvedor a tarefa de configurar manualmente quem coordena e quem executa em um time de agentes Claude.

O gargalo de quem já orquestra vários agentes

Na manhã de 12 de outubro de 2026, a Anthropic abriu os workshops da conferência AI Engineer New York falando sobre um problema que quem já colocou agentes Claude em produção conhece bem: o próprio desenvolvedor vira o gargalo. CJ Avilla e Harrison Stall, ambos Members of Technical Staff na Anthropic, descreveram a sensação de quem hoje coordena múltiplos agentes gerando pull requests o tempo todo.

Acho que muitos de nós que orquestramos e gerenciamos muitos agentes agora começamos a sentir essa sensação de ser o gargalo e o ponto de ruptura, com tantos agentes contribuindo com um monte e um monte de PRs.

I think a lot of us who are orchestrating and managing lots of agents now might start to feel this feeling of being the bottleneck and being the breaking point as we have lots of agents contributing tons and tons of PRs.CJ Avilla, Member of Technical Staff na Anthropic

A dupla recorreu a uma analogia histórica: o Unix de Ken Thompson e a evolução do Linux, que saiu de um único mantenedor (Linus Torvalds) para camadas de mantenedores de confiança. A tese da Anthropic é que agentes de IA precisam do mesmo tipo de estrutura organizacional para encarar projetos grandes, e não apenas tarefas isoladas.

Como o recurso flows organiza o trabalho por baixo do capô

O recurso, anunciado pela Anthropic na sexta-feira, 9 de outubro de 2026, três dias antes do evento, chama-se dynamic workflows, ou simplesmente flows no jargão dos apresentadores. Ele nasceu dentro do Claude Code como o conceito de "um harness para cada tarefa", mas os flows podem rodar por mais tempo que um único agente ou que um roster fixo de subagentes.

A diferença central em relação ao modelo anterior do Claude Managed Agents é onde mora a decisão de organização. Antes, o desenvolvedor configurava manualmente um agente coordenador e um roster de subagentes especializados. Com flows, é o próprio agente líder que cria um plano de como quer realizar a tarefa, escreve um programa de orquestração, lança os agentes necessários, coleta os resultados e gerencia o fluxo de informação entre eles.

Flows são essencialmente a próxima versão de orquestração multiagente, em que você deixa o Claude orquestrar totalmente sua própria topologia multiagente.

Flows are essentially the next version of multi-agent orchestration, where you can let Claude fully orchestrate the entirety of its own multi-agent topology.Harrison Stall, Member of Technical Staff na Anthropic

Isso não significa perda total de controle. Avilla destacou que o desenvolvedor ainda pode passar subagentes pré-configurados na configuração do agente, para casos em que já existe um especialista definido (um agente de revisão de segurança, por exemplo) que não faz sentido deixar a cargo da decisão automática. O recurso fica disponível no Claude Console, a interface voltada a quem acessa o Claude via API, que é o público alvo de todo o pacote Claude Managed Agents.

O exemplo prático: um scanner de ações em duas fases

Para ilustrar o padrão, os apresentadores mostraram um workflow deliberadamente simples: um scanner de watchlist de ações, bem distante dos "projetos grandes e ambiciosos" que a Anthropic diz mirar com flows. Ainda assim, o exemplo deixa claro o formato básico.

1. Fase de varredura: tickers individuais são distribuídos para agentes com contextos isolados entre si, cada um analisando sua fatia do mercado.
2. Fase de revisão: um agente examina os achados de todas as varreduras antes de produzir o relatório final consolidado.

O padrão de duas fases (dividir o trabalho, depois revisar o que voltou) é o que a Anthropic espera que se repita em escala muito maior, com o lead agent decidindo quantas fases e quantos agentes paralelos cada fase precisa, em vez do desenvolvedor desenhar esse grafo à mão.

Quantos agentes disparar, e quem paga a conta

A plateia do workshop foi direto ao ponto que mais preocupa quem já sofreu com custo de API: se o Claude decide sozinho quantos agentes lançar, o que impede uma tarefa simples de disparar centenas de subagentes? Stall respondeu que o controle vem de duas frentes: evals (avaliações) que calibram o comportamento esperado, e defaults mais conservadores, que exigem incentivo explícito do desenvolvedor para que o sistema aumente a paralelização em tarefas realmente ambiciosas.

Sobre orçamento, a resposta foi direta: o agente líder não sabe quanto dinheiro tem disponível enquanto está rodando. Quem define isso é o desenvolvedor, através de um orçamento de sessão (session budget) configurado de antemão. Stall comentou, entre risos da plateia, que informar o orçamento ao modelo em tempo real pode deixá-lo "um pouco ansioso", e por isso a Anthropic optou por manter esse número fora da visão do agente durante a execução.

Sobre visibilidade, Avilla garantiu que nada fica opaco: a função de graphing dentro do Claude Console permite inspecionar cada transição do grafo gerado pelo lead agent.

Você consegue ver: o que o agente líder realmente passou para o subagente? Dá para olhar esse payload aqui para entender profundamente o que está de fato acontecendo em cada transição desse grafo inteiro.

You can tell, what did the lead agent actually pass to the sub-agent? You can look at that payload here to deeply understand what is actually happening for every transition in this entire graph.CJ Avilla, Member of Technical Staff na Anthropic

Uma pergunta técnica relevante para quem desenha arquitetura multiagente: os subagentes conversam diretamente entre si? Stall foi claro que não, pela API. Eles compartilham um sistema de arquivos e podem trocar informação por ali, mas não existe um canal de mensagem direta programável de um subagente do workflow para outro.

O que ainda não existe: autoaperfeiçoamento automático

Uma das perguntas mais interessantes da sessão de perguntas e respostas foi se o próprio workflow do scanner de ações consegue perceber que seu modelo de varredura está ruim e ajustar a próxima execução agendada sozinho. Stall admitiu que isso não está embutido no recurso hoje.

O caminho sugerido pela dupla combina duas peças: hill-climbing (ajuste iterativo testando variações) e um recurso batizado de dreaming, descrito na documentação da Anthropic como um research preview, ou seja, uma funcionalidade experimental sujeita a mudança. Segundo a documentação citada na sessão, dreaming funciona assim:

Um dream lê um banco de memória existente junto com transcrições de sessões passadas, e então produz um novo banco de memória reorganizado.

A dream reads an existing memory store alongside past session transcripts, then produces a new, reorganized memory store.Documentação da Anthropic sobre Claude Managed Agents

Nesse processo, duplicatas são mescladas, entradas obsoletas ou contraditórias são substituídas e novos insights são expostos. Avilla resumiu a ideia dizendo que dreaming serve para "cristalizar e basicamente melhorar o banco de memória relacionado àquelas sessões". Na prática, é a Anthropic reconhecendo que hoje a melhoria de um loop de flows ainda depende de intervenção do desenvolvedor pedindo uma análise de custo ou disparando um dream, não de um mecanismo automático de autocorreção.

Quanto custa e até onde a ambição chega

Sobre custo, a comparação feita no próprio exemplo do scanner de ações foi qualitativa: Avilla afirmou que flows custam "muito mais" que uma abordagem com agente único, mas são "muito mais eficazes em encontrar todos os detalhes". A Anthropic não divulgou nesta sessão um número de custo por chamada ou por token para flows especificamente, o que reforça por que definir um orçamento de sessão antes de rodar qualquer workflow ambicioso deixou de ser opcional e virou uma etapa chave do processo.

A pergunta mais ambiciosa veio de alguém na plateia que citou a prova recente da OpenAI sobre o problema Navier-Stokes, um dos Problemas do Milênio, e perguntou se dynamic workflows poderiam sustentar pesquisa científica desse porte. Stall não quis comentar especificamente como a Anthropic computa problemas científicos grandes internamente, mas foi direto sobre a meta do produto.

Flows são basicamente uma forma de jogar computação em tempo de inferência contra problemas difíceis e extrair mais capacidade, mais rápido, dos modelos. Achamos que, especialmente como um serviço de API, destravar esse poder é o primeiro passo para tornar esse tipo de descoberta, ou progresso científico, amplamente acessível ao público em geral.

Flows are basically a way to throw test-time compute at hard problems and get more capability faster out of the models. We think, especially as an API service, that unlocking the power of this is the first step for us making these types of discoveries, or scientific progress, broadly doable by the general public.Harrison Stall, Member of Technical Staff na Anthropic

Para quem constrói agentes em produção hoje, o recado prático é duplo. Primeiro, flows resolve um problema real de escala (coordenação manual de dezenas de PRs gerados por agente), mas troca controle explícito por confiança na capacidade do modelo de planejar sua própria topologia, o que exige evals próprios antes de soltar em produção sem supervisão. Segundo, nada aqui é gratuito: sem orçamento de sessão definido, a conta pode crescer rápido justamente porque o sistema foi desenhado para jogar mais computação no problema quando julgar necessário.

Fonte: Latent Space