Claude Managed Agents oferece hoje três formas de um agente receber ajuda. Os subagentes servem para delegar trabalho ao qual você quer voltar depois. Os dynamic workflows são para tarefas grandes que se dividem em muitas peças paralelas. O advisor é para quando um único agente faz o trabalho mas precisa do critério de um modelo mais capaz em momentos-chave. Os dynamic workflows são o mais novo dos três: Anthropic os lançou em beta pública em 9 de outubro de 2026. Com eles, o agente escreve um programa que executa até 1.000 agentes por fases e combina seus resultados.
O que é Claude Managed Agents?
Claude Managed Agents é o harness de agentes hospedado da Anthropic na Claude Platform, em beta desde 8 de abril de 2026. O loop do agente não roda no seu código. Você define um agente (modelo, system prompt, ferramentas, servidores MCP, skills), inicia uma sessão, e Anthropic executa o loop, o sandbox e as ferramentas integradas nos seus servidores. Você acompanha o que acontece através de um stream de eventos (server-sent events). Todos os endpoints requerem o beta header managed-agents-2026-04-01.
Não é Claude Code. A distinção importa porque os dois produtos têm agora uma funcionalidade chamada “dynamic workflows” (explico a diferença abaixo).
Qual é a diferença entre subagentes, dynamic workflows e advisor?
A diferença está em quem decide o próximo passo.
- Subagentes (subagents). O agente delega uma tarefa, lê o que o subagente reporta e decide ele mesmo o que fazer depois. Cada subagente mantém sua própria thread persistente, então o agente pode enviar-lhe mensagens de acompanhamento depois. A delegação tem um único nível de profundidade, e uma sessão pode ter no máximo 25 threads filhas ao mesmo tempo, contando as inativas.
- Dynamic workflows. O agente escreve um workflow: um programa que executa muitos agentes por fases, passa os resultados de um agente para o próximo e os combina. O servidor o executa em background como um workflow run. Enquanto roda, o agente fica livre para conversar com você ou revisar o progresso. Uma vez que o run começa, Claude não intervém em cada passo: o programa decide qual agente executar a seguir e escreve seu prompt.
- Advisor. Um único agente faz todo o trabalho e consulta um modelo mais capaz no meio da sua vez, por exemplo para planejar uma abordagem ou revisar o trabalho antes de terminar. O advisor nunca faz o trabalho.
A documentação oferece uma regra prática. Use workflows para a maioria do trabalho que precisa mais de um agente, como:
- auditorias
- migrações
- pesquisa aprofundada
- verificação cruzada de muitas fontes
Use subagentes quando o agente precisa voltar a conversar com um especialista depois que esse reporta. Use um advisor quando um único agente deve fazer o trabalho mas precisa de melhor critério em alguns momentos-chave.
Você não precisa escolher apenas um. Com o tipo multiagent_20261001, os três podem estar ativos ao mesmo tempo, e cada um é ativado ou desativado separadamente.
Como criar um agente de IA com dynamic workflows?
Coloque multiagent.type em multiagent_20261001 na definição do agente. Com a CLI ant, o exemplo da documentação é este:
---
name: Contract Reviewer
model: claude-opus-5-5
tools:
- type: agent_toolset_20260401
multiagent:
type: multiagent_20261001
workflows:
type: enabled
---
You review contracts. When you're asked to review more than a few contracts, start a workflow run that reads them in parallel and combines the findings. Review one or two contracts yourself, without a run.
Depois execute ant apply contract-reviewer.md.
Com este tipo, workflows e subagents vêm ativados por padrão. Se você quer apenas dynamic workflows, também precisa colocar subagents em {"type": "disabled"}. O advisor é o único dos três que começa desativado.
Como o agente decide quando iniciar um workflow run?
Não existe uma chamada à API para iniciar um run. Você descreve o trabalho em uma user.message, e o agente decide se vale a pena um run.
Essa decisão é guiada a partir do system prompt, como no exemplo anterior: nomeie as tarefas que justificam um run e as tarefas pequenas que o agente deve fazer ele mesmo. Você também pode definir como um run funciona. A documentação sugere instruções como estas:
- “Use um agente por contrato e depois faça com que um segundo agente revise todos os contratos.”
- “Um agente falhar não deve fazer falhar o run; liste o que ficou descoberto.”
- “Dê ao run um limite de uma hora.”
Quais são os limites de um workflow run?
No momento da publicação desta nota, a documentação lista estes limites:
| Limite | Valor |
|---|---|
| Threads funcionando ao mesmo tempo em um run | 64 (não garantido) |
| Agentes que um workflow inicia durante toda a vida do run | 1.000 |
| Duração de um run | 24 horas por padrão, ou a que o agente definir |
| Runs abertos ao mesmo tempo em uma sessão | 10 por padrão |
Além disso:
- Os runs não são aninhados. Apenas o agente da thread principal da sessão pode iniciar um.
- Você não pode ver o código do workflow diretamente. Você pode pedir ao agente que o imprima quando o run terminar.
O que pode dar errado com dynamic workflows?
Estos são os detalhes da documentação que vão te surpreender em produção.
Não há etapa de aprovação. O agente inicia o run na mesma vez em que escreve o workflow. “Descreva o plano e aguarde minha aprovação” é apenas uma instrução no prompt, e a documentação diz claramente que nada a força a ser cumprida.
completed não significa que o trabalho saiu bem. Um run pode terminar com {"type": "completed"} mesmo que o trabalho tenha falhado em algumas de suas threads. Para encontrar as falhas, leia os eventos de cada thread e peça ao agente que reporte o que falhou.
As ferramentas podem ser chamadas duas vezes. Se um agente falhar, o servidor normalmente o executa novamente uma vez em uma nova thread. A documentação indica que qualquer ferramenta que seus agentes chamem deve ser capaz de executar duas vezes sem problema.
Os agentes inline herdam tudo. Por padrão, um workflow pode definir seus próprios agentes. Estes agentes inline usam o modelo, as ferramentas, os servidores MCP e as skills do agente da sessão, e você não pode limitar seu acesso MCP por agente. Se isso for um problema, coloque inline_agents em {"type": "disabled"} e liste apenas os agentes que você aprova:
{
"multiagent": {
"type": "multiagent_20261001",
"workflows": {
"type": "enabled",
"inline_agents": { "type": "disabled" },
"predefined_agents": [
{ "type": "agent", "id": "agent_01Lm4cV8yQ2tNs7XbKdR5h", "version": 2 }
]
}
}
}
Com os agentes inline desativados, a lista predefined_agents deve ter pelo menos um agente, ou a requisição falha com um erro 400. Listar seus próprios agentes também permite que um run use outro modelo para alguns deles, porque os agentes inline sempre usam o modelo do agente da sessão.
Migrar de coordinator ativa as coisas. O tipo anterior, coordinator, permite delegar em subagentes que você lista e consultar um advisor, mas não permite workflow runs nem subagentes inline. Quando você atualiza um agente para multiagent_20261001, tudo o que você não envia toma seu valor padrão, então workflows e agentes inline são ativados. Se você não quer isso, desative-os na mesma atualização. As sessões que já existem não mudam.
Quanto custam os dynamic workflows?
Um run não tem preço próprio. Cada agente dentro do run cobra tokens à tarifa normal do seu modelo, e esses tokens somam ao total da sessão. É por isso que vale a pena definir um orçamento de sessão (session budget), que limita o gasto da sessão, runs inclusos.
Há dois detalhes:
- O orçamento só pode ser definido ao criar a sessão. Você não pode adicioná-lo a uma sessão existente.
- Quando a sessão atinge o orçamento, os runs abertos são pausados. Cada thread que estava funcionando termina a requisição ao modelo que já havia iniciado, então a sessão pode ultrapassar o limite por uma requisição por thread.
O tempo de vida de um run pausado continua passando, então um run que fica pausado por muito tempo termina com timeout_error.
O advisor cobra à tarifa do modelo advisor. Cada consulta envia toda a conversa até esse momento, então as consultas no final de uma sessão longa usam mais tokens de entrada.
São os mesmos dynamic workflows do Claude Code?
Não. Claude Code lançou seus próprios dynamic workflows em 28 de maio de 2026, e rodam localmente dentro da sua sessão de Claude Code. A versão de Managed Agents roda nos servidores da Anthropic, então um run continua avançando mesmo que você feche seu laptop, e você a controla a partir da definição do agente e do stream de eventos. Começam da mesma ideia, mas são produtos separados: a configuração, os limites e a disponibilidade de um não se aplicam ao outro. (Cobrimos a versão de Claude Code aqui: Agent View + Dynamic Workflows.)
Quando vale a pena um sistema multiagente e qual escolher?
- Muitas peças independentes (centenas de documentos, uma auditoria de toda uma codebase, verificar muitas fontes): use dynamic workflows, com um session budget desde o início.
- Alguns poucos especialistas com os quais você precisa voltar a conversar (um revisor, alguém que escreve testes): use subagentes.
- Um agente que precisa de melhor critério, não mais mãos: use um advisor.
O erro mais comum vai ser deixar tudo nos valores padrão: workflows ativados, agentes inline ativados, sem orçamento, e um system prompt que nunca diz quando não iniciar um run.
E você? Qual tarefa do seu time você daria primeiro a um workflow run de centenas de agentes?
- Dynamic workflows
- Subagentes
- Advisor
- Prefiro outra opção (nos conte qual)
Comente abaixo ou, se este artigo chegou para você por email, responda diretamente ao email: sua resposta é publicada aqui.
Relacionado: Sub Agents em Claude Code: A Funcionalidade que Muda seu Fluxo de Desenvolvimento