Ayer Anthropic lanzó Claude Opus 4.8. La función que se llevó los titulares se llama Dynamic Workflows: Claude Code planifica el trabajo solo y luego lanza cientos de subagentes en paralelo —hasta mil por corrida, dieciséis a la vez— que ejecutan, se refutan entre ellos y verifican el resultado antes de devolvértelo.

La lectura fácil llegó a mi correo esta mañana, en un newsletter que titulaba “termina tus proyectos en días en lugar de meses”. Es cierta. Y se queda corta.

Lo que cambió no es que ahora ejecutes más rápido. Es dónde quedó el cuello de botella cuando la ejecución dejó de ser el límite. Se movió a dos cosas que mil agentes no hacen por ti: decidir cuál problema vale la pena resolver, y responder por el resultado cuando ya está hecho.

Eso es el criterio. Y el criterio no se paraleliza.

Esa es la tesis. La pieza de IQ Source que vive en la primera mitad —decidir qué construir— es AI Maestro. La que vive en la segunda —responder por lo que queda corriendo— es Socio Tecnológico. El resto del post arma por qué esas dos no las absorbe ningún enjambre de agentes.

Qué lanzó Anthropic, sin el bombo

Quito el marketing y lo que queda es esto. Un flujo de trabajo dinámico es un guion que Claude Code escribe a partir de lo que le pides. Un entorno lo corre en segundo plano mientras tu sesión sigue respondiendo. Los subagentes atacan el problema desde ángulos independientes, otros agentes intentan refutar lo que encontraron, y la corrida itera hasta que las respuestas convergen. Anthropic lo resume en una línea: Claude Code “verifica sus salidas antes de reportarte”.

El número que importa para entender la escala: migraciones de código a escala de cientos de miles de líneas, del arranque al merge, usando tu batería de pruebas existente como vara. No es un asistente que te sugiere; es un equipo que ejecuta hasta que el verde de las pruebas le da permiso de parar.

Y no viene solo. El mismo modelo es, según Anthropic, unas cuatro veces menos propenso que el anterior a dejar pasar fallas en el código que él mismo escribe. El modo rápido bajó a un tercio del precio. O sea: más barato ejecutar, y un ejecutor que se revisa mejor a sí mismo. No es un truco de demo. Está en vista previa de investigación para planes Enterprise, Team y Max, y en IQ Source corremos Claude Code en la operación todos los días, así que esto no lo leo en un anuncio, lo veo en el monitor.

Todo eso es real y es útil. Y nada de eso toca el problema del que va este post.

El cuello de botella se movió otra vez

Cuando ejecutar era el límite, lo escaso era la capacidad. Manos, horas, gente que supiera. Por eso un proyecto técnico tomaba meses: no porque fuera difícil decidirlo, sino porque era caro hacerlo.

Dynamic Workflows borra esa restricción. La capacidad ahora se alquila por millar. Y cuando lo escaso deja de ser escaso, la restricción no desaparece, se muda hacia arriba. La nueva pregunta cara es: ¿cuál problema merece que le apuntes mil agentes?

Lo más honesto del newsletter que mencioné arriba fue una sola frase, casi al pasar: el cuello de botella se movió de la capacidad del equipo a decidir cuál problema resolver primero. Esa frase es una confesión. Está admitiendo que el valor ya no vive en ejecutar. Vive en elegir.

La mayoría de las empresas no tiene un proceso para elegir. Tiene una bandeja de pendientes y le apunta la IA a lo que grita más fuerte ese día. Eso funcionaba cuando ejecutar era caro, porque el costo mismo te obligaba a priorizar. Quita el costo y quitas la priorización forzada. Ahora puedes lanzar mil agentes sobre el módulo equivocado, llevarlo limpio hasta el merge, con la batería de pruebas en verde, y haber quemado mil agentes de cómputo en algo que nadie pidió.

Que las pruebas pasen no significa que valía la pena hacerlo. Esa distinción —entre “está bien hecho” y “valía la pena”— es exactamente el discovery. Ya lo toqué desde el lado de ciberseguridad, cuando Anthropic encontró diez mil vulnerabilidades en un mes y el problema pasó a ser cuáles parchar: el cuello de botella se había movido de encontrar a decidir. Dynamic Workflows lo vuelve a mover, ahora para todo el trabajo técnico, no solo para seguridad.

Mil agentes no responden por nada. Una persona sí.

Hay un segundo trabajo que tampoco se paraleliza, y es más incómodo que el primero.

En los comentarios del mismo newsletter, un asesor de estrategia escribió la pregunta correcta: cuando los agentes revisan valoraciones y documentos a esta escala, ¿quién es dueño del resultado de esas revisiones? No el agente. La persona con nombre y apellido que autorizó el despliegue y responde por lo que produjo.

Esa es la parte que la palabra “verifica” esconde. La capa de verificación de Dynamic Workflows —agentes que se refutan entre ellos hasta converger— atrapa la incoherencia interna. Atrapa que un subagente contradiga a otro. Lo que no atrapa es la premisa equivocada. Si entraste con la pregunta mal planteada, mil agentes no te salvan; se ponen de acuerdo más rápido en la respuesta equivocada y te la entregan con la confianza de algo que pasó mil revisiones.

Otro comentarista, un ingeniero, lo dijo más seco: ¿y si los supuestos del que implementa están mal, o los datos cambiaron porque el negocio es dinámico? A escala, ese error no se diluye. Se multiplica. La basura también escala.

Lo cual cambia qué significa “verificar”. No es que el sistema no falle. Es que la probabilidad de que una falla quede contenida sube, mientras que la probabilidad de que la pregunta fuera la correcta no cambia ni un punto. Esas dos cosas son distintas, y solo una de las dos te la resuelve el enjambre.

Por eso sigue haciendo falta un humano que pueda leer el resultado, saber si está bien, y poner su nombre encima. Ese rol no se reparte entre dieciséis subagentes. Es de una persona, y es el rol que casi ninguna empresa de tamaño medio en LatAm tiene cubierto cuando el agente ya está en producción.

¿Esto es nuevo? Sí y no.

Vale la pena tomarse en serio al escéptico, porque tiene la mitad de la razón. En esos mismos comentarios, un Chief Innovation Officer escribió: esto se podía hacer hace dos años con cualquier orquestador, un Zapier, un n8n, un Make. Es solo empaque.

Tiene razón en que orquestar no es nuevo. Llevo desde 1990 en esto y he visto la orquestación reempacarse varias veces, con nombres distintos cada cinco años. La idea de coordinar piezas que trabajan en paralelo es vieja.

Donde se equivoca es en qué se reempacó. Tres cosas pasaron a la vez, y ninguna existía en el Zapier de hace dos años: la ejecución se volvió barata, el sistema se verifica solo, y Claude escribe su propio guion de orquestación. El n8n necesitaba que tú diseñaras el grafo, nodo por nodo. Esto diseña el suyo a partir de una frase.

Pero —y aquí está la parte honesta— ninguna de esas tres novedades toca el problema de decidir y responder. Zapier tampoco decidía cuál flujo importaba. Lo que se automatizó es la parte que ya era medio barata: el cableado. La parte que siempre fue escasa, el juicio, sigue intacta. Así que “es solo empaque” se pierde lo que cambió, y “lo cambia todo” se pierde lo que no.

Hace un mes lo planteé desde el otro extremo: que el runtime se había vuelto un commodity y el moat (ventaja competitiva) era el flujo de trabajo que construías encima. Bueno, Dynamic Workflows acaba de empezar a escribir ese flujo solo. Así que el moat sube un escalón más: ya no está en diseñar el flujo, está en decidir cuál flujo merece existir y en responder por lo que produce. Cada vez que la herramienta sube un peldaño, el criterio sube con ella. No al revés.

Lo que hace IQ Source con esto

Las dos cosas que no se paralelizan son, casualmente, las dos en las que trabajamos.

AI Maestro es el discovery que decide cuál problema merece los agentes. Dos meses de consultoría donde mapeamos los procesos reales de tu operación —no los del organigrama—, les ponemos un Score de Oportunidad de IA, y al final hay una compuerta Go/No-Go proceso por proceso. Es la pieza que separa el módulo que merece mil agentes del que solo va a quemar tokens y dejarte las pruebas en verde sobre algo que nadie necesitaba.

Socio Tecnológico es el otro rol: el dueño del flujo cuando ya está en producción. La persona que lee lo que el enjambre produjo, detecta que la premisa estaba mal aunque las pruebas pasaran, y pone su nombre en el resultado frente a la junta. Es el rol que un Director de Tecnología bueno cubriría, y que la mayoría de las empresas B2B de tamaño medio no tienen internamente.

Fíjate que ninguno de los dos es “implementar”. La implementación es justo lo que Anthropic acaba de abaratar. Lo que no abarató, lo que probablemente nunca abarate, es el criterio de entrada y la responsabilidad de salida.

Antes de cerrar la semana, hazle a tu equipo una sola pregunta. Si mañana pudieras lanzar mil agentes sobre cualquier problema de tu operación, ¿cuál elegirías, y quién pondría su nombre en el resultado? Si no tienen respuesta rápida a las dos, el límite de tu empresa nunca fue la capacidad de ejecutar. Era el criterio. Y ese acaba de quedar más expuesto que nunca.

Decidir cuál problema merece los agentes