Si alguna vez corriste más de una sesión de Claude Code al mismo tiempo, conocés la situación: una pestaña de terminal para la migración, otra para la cobertura de tests, una tercera para ese refactor que empezaste y te olvidaste. Sumale un grid de tmux encima y de golpe la mitad de tu cabeza está solo rastreando qué agente está haciendo qué, cuál está esperando que le respondas, y cuál terminó calladito hace veinte minutos.
Claude Code lanzó dos features que atacan exactamente este problema desde puntas opuestas. Agent view te da una sola pantalla para ver todas tus sesiones de un vistazo. Dynamic workflows deja que Claude levante y coordine docenas — o cientos — de subagentes por su cuenta, así el trabajo que antes repartías entre pestañas lo maneja un único script de orquestación. Una resuelve la visibilidad. La otra resuelve la coordinación. Juntas cambian lo que “correr agentes en paralelo” realmente se siente.
Agent view: una sola pantalla para todo lo que tenés corriendo
Corré claude agents y obtenés un dashboard de cada sesión de Claude Code que tengas activa. En vez de andar ciclando entre pestañas tratando de acordarte dónde quedó cada una, ves el panorama completo en un solo lugar: qué está corriendo, qué está bloqueado esperando tu input, y qué ya está listo.
Desde esa pantalla podés largar nuevos agentes, mandarlos al background, y entrar a cualquier sesión para responder inline o abrir la conversación completa. Los indicadores de estado hacen el rastreo mental por vos — una sesión que está procesando se ve distinta de una que necesita tu decisión, que a su vez se ve distinta de una que ya produjo un pull request y está lista para review.
El cambio es sutil pero real. Antes, los agentes en paralelo significaban que vos eras la capa de orquestación — el que sostenía el mapa de quién hacía qué. Agent view te saca esa carga de encima. Dejás de ser el dashboard.
Dynamic workflows: cuando una sola conversación no alcanza
Agent view maneja las sesiones que vos arrancás. Dynamic workflows maneja las que nunca querrías arrancar a mano.
Un workflow es un script de orquestación que Claude escribe para tu tarea y después corre a través de muchos subagentes en el background. La idea es para trabajos que son simplemente demasiado grandes para que una sola conversación los coordine: una auditoría a nivel de todo el codebase, una migración grande, una pregunta de research que necesita cross-checking desde varios ángulos. En vez de que vos descompongas el trabajo y cuides cada pieza, Claude lo descompone, levanta los subagentes, y los corre — escalando de docenas a cientos según la tarea.
Los runs los manejás con /workflows. Esa es tu superficie de control: largás uno, chequeás el progreso, ves qué están produciendo los subagentes.
El modelo mental que conviene tener: agent view es para paralelismo que vos manejás, un puñado de sesiones que estás dirigiendo activamente. Dynamic workflows es para paralelismo que maneja Claude, donde delegás un objetivo grande y dejás que la orquestación pase por debajo. La mayoría de los workflows reales van a mezclar ambos — unas cuantas sesiones hands-on en agent view mientras un workflow grande muele una migración en el background.
Por qué esto importa para cómo trabajás
La versión honesta: ninguna de las dos features hace que tus agentes sean más inteligentes. Lo que cambian es el overhead de correr muchos a la vez — y ese overhead era el verdadero techo del trabajo en paralelo, no los modelos.
Si te venías limitando a una o dos sesiones porque tres se sentían como demasiado para rastrear, agent view sube ese techo. Si venías partiendo a mano una migración grande en pedazos y metiéndolos de a uno, dynamic workflows es la herramienta que faltaba.
Un par de notas prácticas. Agent view llegó primero (está dando vueltas desde mediados de mayo); dynamic workflows apareció junto con el cambio a Opus 4.8 por default y es la más nueva de las dos. Dynamic workflows está pensada para tareas genuinamente grandes — usarla para un trabajo chico es overkill, y le vas a sacar más jugo a una sesión normal. Y como siempre con los runs en background y autónomos: cuanto más grande y menos supervisado el trabajo, más conviene definir condiciones de finalización claras desde el arranque, así estás revisando resultados y no desenredando un run largo que se fue de tema.
Para equipos que shippean rápido, la ganancia es operativa. Menos tiempo gastado en context-switching entre pestañas de terminal, y más del trabajo pesado — auditorías, migraciones, expansión de tests — manejado en paralelo sin un humano haciendo de controlador de tráfico.
¿Ya probaste correr varios agentes en paralelo con agent view, o te quedás con una sola sesión por la carga mental? ¿En qué tipo de tarea largarías un dynamic workflow?
Docs: