Se você já rodou mais de uma sessão de Claude Code ao mesmo tempo, você conhece a situação: uma aba de terminal para a migração, outra para a cobertura de testes, uma terceira para aquele refactor que você começou e esqueceu. Some um grid de tmux por cima e de repente metade da sua cabeça está só rastreando qual agente está fazendo o quê, qual está esperando você responder, e qual terminou silenciosamente vinte minutos atrás.
Claude Code lançou dois recursos que atacam exatamente esse problema de pontas opostas. Agent view te dá uma única tela para ver todas as suas sessões num piscar de olhos. Dynamic workflows deixa que Claude levante e coordene dezenas — ou centenas — de subagentes por conta própria, então o trabalho que antes você distribuía entre abas é gerenciado por um único script de orquestração. Um resolve a visibilidade. O outro resolve a coordenação. Juntos, eles mudam o que “rodar agentes em paralelo” realmente se sente.
Agent view: uma única tela para tudo que você está rodando
Rode claude agents e você obtém um dashboard de cada sessão de Claude Code que você tem ativa. Em vez de ficar ciclando entre abas tentando se lembrar de onde cada uma ficou, você vê o panorama completo em um único lugar: o que está rodando, o que está bloqueado esperando seu input, e o que já está pronto.
Dessa tela você pode lançar novos agentes, mandá-los para o background, e entrar em qualquer sessão para responder inline ou abrir a conversa completa. Os indicadores de status fazem o rastreamento mental por você — uma sessão que está processando se vê diferente de uma que precisa da sua decisão, que por sua vez se vê diferente de uma que já produziu um pull request e está pronta para review.
A mudança é sutil mas real. Antes, os agentes em paralelo significavam que você era a camada de orquestração — aquele que sustentava o mapa de quem fazia o quê. Agent view tira esse peso de cima de você. Você deixa de ser o dashboard.
Dynamic workflows: quando uma única conversa não é suficiente
Agent view gerencia as sessões que você arranca. Dynamic workflows gerencia as que você nunca gostaria de arrancar na mão.
Um workflow é um script de orquestração que Claude escreve para sua tarefa e depois roda através de muitos subagentes no background. A ideia é para trabalhos que são simplesmente muito grandes para que uma única conversa os coordene: uma auditoria a nível de todo o codebase, uma migração grande, uma pergunta de research que precisa de cross-checking de vários ângulos. Em vez de você decompor o trabalho e cuidar de cada pedaço, Claude decompõe, levanta os subagentes, e os roda — escalando de dezenas a centenas conforme a tarefa.
Os runs você gerencia com /workflows. Essa é sua superfície de controle: você lança um, checa o progresso, vê o que os subagentes estão produzindo.
O modelo mental que convém ter: agent view é para paralelismo que você gerencia, um punhado de sessões que você está dirigindo ativamente. Dynamic workflows é para paralelismo que Claude gerencia, onde você delega um objetivo grande e deixa a orquestração passar por baixo. A maioria dos workflows reais vai misturar os dois — algumas poucas sessões hands-on em agent view enquanto um workflow grande processa uma migração no background.
Por que isso importa para como você trabalha
Sendo honesto: nenhum dos dois recursos faz seus agentes serem mais inteligentes. O que eles mudam é o overhead de rodar muitos ao mesmo tempo — e esse overhead era o verdadeiro limite do trabalho em paralelo, não os modelos.
Se você vinha se limitando a uma ou duas sessões porque três se sentiam como demais para rastrear, agent view sube esse limite. Se você vinha partindo na mão uma migração grande em pedaços e colocando um de cada vez, dynamic workflows é a ferramenta que estava faltando.
Algumas notas práticas. Agent view chegou primeiro (está circulando desde meados de maio); dynamic workflows apareceu junto com a mudança para Opus 4.8 por padrão e é a mais nova das duas. Dynamic workflows é pensado para tarefas genuinamente grandes — usá-lo para um trabalho pequeno é exagero, e você vai tirar mais proveito de uma sessão normal. E como sempre com os runs em background e autônomos: quanto maior e menos supervisionado o trabalho, mais vale a pena definir condições de finalização claras desde o começo, assim você está revisando resultados e não desembaraçando um run longo que saiu do tema.
Para equipes que fazem ship rápido, o ganho é operacional. Menos tempo gasto em context-switching entre abas de terminal, e mais do trabalho pesado — auditorias, migrações, expansão de testes — gerenciado em paralelo sem um humano fazendo de controlador de tráfico.
Você já tentou rodar vários agentes em paralelo com agent view, ou você fica com uma única sessão pela carga mental? Em que tipo de tarefa você lançaria um dynamic workflow?
Docs: