Claude Code crea un organigrama en tiempo de ejecución

La versión preliminar de investigación de Claude Code puede asignar trabajo a cientos de subagentes mediante un plan de orquestación que no existía cuando llegó la solicitud. El sistema puede dividir la tarea, verificar los resultados y unificarlos antes de responder. Preguntas habituales de ingeniería —quién puede actuar, qué puede consultar y quién puede detenerlo— ahora deben resolverse cuando el trabajo ya está en marcha.

El ciclo de instrucciones se queda corto

Una llamada estática a un modelo recibe una instrucción y devuelve una respuesta. Un agente de IA incorpora iteración: puede examinar resultados intermedios, usar herramientas, conservar memoria, actualizar su estado y decidir qué hacer después. La instrucción pasa a ser uno de los componentes de una estructura de control más amplia.

El grafo creado por el desarrollador determina si una tarea continúa, se divide, escala, se delega, vuelve a intentarse o se detiene. LangGraph hace explícitas las bifurcaciones condicionales, las llamadas a herramientas y las decisiones para continuar un flujo dentro de un diseño acotado. El Agents SDK de OpenAI trata las transferencias, las salvaguardas y la trazabilidad como mecanismos de delegación. AutoGen, CrewAI, Google Agent Development Kit y las herramientas de Anthropic abordan el mismo problema desde distintos ángulos.

A medida que los modelos se volvieron útiles para trabajos acotados y apoyados en herramientas, los desarrolladores comenzaron a diseñar las relaciones entre sus distintas llamadas. Ahora definen funciones, líneas de reporte, registros compartidos, rutas de escalamiento, mecanismos de revisión y reglas para reasignar el trabajo cuando falla el primer plan. La calidad de las instrucciones sigue siendo importante, pero es una propiedad local dentro de un sistema operativo más amplio.

Un grafo generado convierte la orquestación en software creado durante la ejecución

Los grafos fijos pueden ampliar las capacidades sin renunciar a la previsibilidad de un flujo diseñado de antemano. En su versión preliminar de investigación sobre flujos de trabajo dinámicos, Claude Code va más lejos: genera el plan de orquestación durante la ejecución. Ante una tarea suficientemente compleja, Claude puede planear el trabajo, distribuirlo en paralelo, verificar los resultados y consolidarlos antes de responder. Uno de los casos de uso mencionados son las migraciones de entornos de desarrollo que abarcan cientos de archivos.

Un flujo dinámico hace más que sumar agentes. Puede generar la infraestructura de control que parece requerir la tarea: dividir una migración por subsistema, incorporar revisores, devolver las verificaciones fallidas a quienes implementaron los cambios y conservar una etapa de integración para el resultado final. Ahora el modelo produce la definición del grafo en vez de limitarse a operar dentro de uno proporcionado por un desarrollador.

Los desarrolladores no deben confundir este paso con un rediseño autónomo sin restricciones. Las recomendaciones actuales siguen considerando que la orquestación acotada aporta previsibilidad y seguridad. La versión preliminar de Claude Code crea un guion de orquestación y después sigue ese plan; no demuestra que las organizaciones capaces de modificarse continuamente y sin restricciones sean deseables ni funcionen de manera confiable.

Aun así, Claude Code cruza un límite importante. Los equipos pueden revisar un flujo estático antes del despliegue. Un flujo generado durante la ejecución aparece después de que comienza la solicitud y responde a un estado de la tarea que no existía cuando se diseñó el sistema. La organización que ejecuta la tarea se convierte en un componente de software efímero.

Los equipos deben tratar ese componente como código de alto impacto: asignarle identidad y versión, restringir sus permisos y su ejecución, observar sus transiciones y registrar quién o qué autorizó su creación. De lo contrario, «dinámico» se convierte en una forma amable de llamar a un cambio en producción sin revisar.

Los agentes en paralelo hacen visibles los costos de la orquestación

Más trabajadores no producen automáticamente más trabajo útil. Cada transferencia añade costos de coordinación. Los agentes pueden perder contexto, propagar permisos de manera incorrecta y dificultar la localización de errores cuando la responsabilidad cruza distintos límites. La distribución en paralelo consume recursos adicionales de inferencia y orquestación para realizar búsquedas simultáneas o reducir el tiempo total. La inversión solo compensa cuando la tarea puede dividirse con suficiente claridad para absorber ese costo adicional.

En una descripción anterior de su sistema de investigación multiagente Claude Research, Anthropic afirmó haber obtenido mejoras considerables frente a sistemas de un solo agente en evaluaciones internas. Esa evidencia corresponde a una infraestructura y un conjunto de tareas específicos; no demuestra que un enjambre supere a un agente individual potente. Algunos trabajos necesitan un equipo de investigación. Otros requieren una sola persona competente y menos reuniones.

El valor lo crea quien asigna el trabajo, no la cantidad de agentes, cuando decide si conviene dividir una tarea, qué especialistas deben recibirla y qué contexto necesita cada uno. También establece los límites de costo y latencia, determina cuándo vale la pena añadir una verificación y recurre a un solo agente cuando delegar cuesta más de lo que aporta. Son cuestiones de economía de agentes, no de diseño de personalidades.

La evolución de Anthropic, desde un sistema de investigación multiagente hasta Claude Managed Agents, muestra dónde comienza a definirse el límite del producto. La oferta administrada incluye infraestructura para agentes y herramientas de despliegue porque operar un agente exige más que generar otra respuesta del modelo. Requiere mantener las condiciones para que muchas respuestas se conviertan en un solo resultado sujeto a rendición de cuentas.

Los modelos de vanguardia ya pueden operar dentro de varios sistemas de orquestación, por lo que la calidad del modelo dejó de describir el producto completo. Equipos que usan modelos con capacidades similares pueden obtener resultados muy distintos según cómo dividan las tareas, conserven el estado, verifiquen, se recuperen de fallas y controlen los costos. La infraestructura convierte la capacidad de razonamiento en trabajo terminado y determina cuánto desorden genera el proceso.

El control de cambios debe integrarse al grafo

Los equipos no pueden gobernar agentes dinámicos únicamente mediante las instrucciones del sistema y la respuesta final. Deben llevar un control de versiones de los grafos, asignar permisos por función, restringir las transferencias, aprobar la selección de modelos y herramientas, definir las condiciones de escalamiento y especificar las pruebas necesarias para que una rama pueda avanzar.

La Agent Control Specification de Microsoft hace explícita esa necesidad al proponer un estándar de código abierto para ejercer un control granular y uniforme sobre las acciones de los agentes. El software siempre ha tenido permisos; los agentes dinámicos necesitan que esas políticas se apliquen durante la ejecución. La política debe acompañar al agente cuando se desplaza entre aplicaciones, herramientas y funciones delegadas.

Una organización generada también plantea cuestiones de aprobación que el control de acceso estático no resuelve. Un agente puede tener permiso para leer un repositorio, pero no para delegar ese acceso a veinte subagentes. Un revisor puede rechazar una corrección, pero carecer de permiso para reescribirla. Una evaluación fallida puede activar un nuevo intento, mientras que un cambio de permisos puede exigir intervención humana. El grafo necesita separar funciones, porque el modelo no puede ser solicitante, aprobador, ejecutor y auditor con solo cambiar de papel en ventanas de contexto contiguas.

El principio de escalamiento es anterior a los flujos dinámicos. En diciembre de 2023, OpenAI otorgó a su consejo la autoridad para detener el lanzamiento de un modelo pese a que la dirección lo considerara seguro. Las decisiones de alto impacto requerían una autoridad fuera del ciclo operativo. Los grafos de agentes en ejecución necesitan el equivalente en software: ciertas transiciones de estado deben detener la automatización y transferir la autoridad a otra instancia.

Los operadores pueden usar el criterio humano, la evaluación mediante modelos y la validación contra bases de conocimiento como filtros, pero un filtro solo permite exigir responsabilidades cuando su política y autoridad quedan registradas. Un historial de auditoría debe mostrar qué grafo se ejecutó, qué estado activó una rama, qué permiso habilitó una llamada a una herramienta, qué evaluador aceptó el resultado y qué persona aprobó una excepción. Así, la capacidad de auditoría forma parte de la arquitectura del producto en lugar de ser un añadido para cumplir normas.

Los registros de razonamiento no bastan para exigir responsabilidades

Un grafo más grande ofrece a los operadores más puntos para inspeccionar el sistema. También brinda a los agentes más oportunidades para actuar estratégicamente, perder contexto o elaborar una explicación conveniente después de haber actuado. La observabilidad crece con el grafo, pero también crece aquello que debe observarse.

El marco de OpenAI para evaluar la observabilidad de la cadena de pensamiento incluye 13 evaluaciones. Considera la observabilidad como una propiedad empírica y analiza, entre otros aspectos, si un sistema de monitoreo puede detectar conductas como la manipulación de recompensas a partir del razonamiento expresado por un modelo. Este enfoque resulta útil porque no supone que una cadena de pensamiento visible sea una fuente infalible de verdad.

Investigadores de OpenAI, Google DeepMind, Anthropic y otras organizaciones han descrito el monitoreo de la cadena de pensamiento como una opción prometedora, pero frágil. Los análisis de la ficha técnica de Claude Sonnet 4.5 señalaron una mayor conciencia verbalizada sobre los entornos de evaluación, lo que dificulta interpretar las puntuaciones de alineación. Un sistema que reconoce la prueba puede alterar las evidencias que esa prueba pretendía recopilar.

Los registros de razonamiento son indicios, no comprobantes. Pueden ayudar a detectar conductas sospechosas, explicar una ruta o activar una revisión adicional. Por sí solos, no pueden demostrar por qué actuó un agente ni establecer que la justificación declarada causó la acción.

Un sistema de agentes sujeto a rendición de cuentas necesita registros más sólidos: invocaciones de herramientas, transiciones de estado, cambios al grafo, decisiones de políticas, resultados de evaluadores, eventos de aprobación y los permisos exactos que estaban activos en cada paso. El modelo puede narrar su razonamiento, pero la capa de control debe registrar su conducta. Las auditorías empresariales no suelen concluir después de leer el diario del gerente.

Los compradores deben preguntar quién puede detener el grafo

OpenAI otorgó a su consejo autoridad sobre los lanzamientos en diciembre de 2023; Microsoft propuso controles para agentes en ejecución en junio de 2026. La pregunta pasó de si una organización puede detener un modelo potente antes de lanzarlo a si un modelo ya desplegado puede crear una organización de agentes sin salirse de los permisos, las aprobaciones y los requisitos de evidencia de la tarea.

Los equipos deben conservar una orquestación fija cuando la previsibilidad importe más que la adaptación. Deben usar un solo agente potente cuando delegar cueste más de lo que aporta. Los grafos dinámicos son adecuados para tareas grandes, divisibles y con suficiente incertidumbre como para que los equipos no puedan definir por completo la estructura de ejecución con anticipación.

Los equipos de compras y plataformas deben exigir evidencias por tarea: el grafo que se ejecutó, la identidad de cada agente delegado, los permisos de las herramientas, las decisiones de los evaluadores, las aprobaciones de excepciones y el costo total. La puntuación de una prueba comparativa no permite saber si el sistema puede contener una rama fallida o revocar una autorización a mitad de una tarea.

Los cientos de trabajadores hacen que la versión preliminar de Claude Code parezca una historia de escala. La cifra decisiva es una: un organigrama creado después del despliegue, mientras la tarea está en marcha. Los compradores deben exigir una infraestructura de control que identifique quién autorizó cada recuadro y cada flecha.