El sucesor de Loop Engineering y el flujo de trabajo que multiplica por 10 el alcance de tus agentes...
La mayoría de las personas que construyen un agente de múltiples pasos terminan con una línea recta
paso uno, paso dos, paso tres. Cada uno esperando a que el anterior termine antes de comenzar
Esto es lo que casi nadie verifica:
la mitad de esos pasos nunca necesitaron esperar
Simplemente se ponen en cola, un trabajo a la vez, hasta que la ventana de contexto se llena y el agente olvida lo que estaba haciendo.
- No era lento porque el modelo fuera débil.
- Era lento porque dibujaste una línea donde el trabajo era un grafo
Esta guía te lleva de esa línea a un grafo que se despliega a través de una flota y verifica su propio trabajo.
Cinco pasos. Para el Paso 2 ya habrás construido uno -
Te da un grafo funcional y nombra las trampas que rompen los reales, y te señalaré dónde comienzan las partes difíciles.
antes del lanzamiento - suscríbete a mi substack para más contenido exclusivo ↓
Capítulo 0 - Qué es realmente la ingeniería de grafos
Hace un mes, el campo hablaba de bucles.
Peter Steinberger lo resumió en nueve palabras:
https://x.com/steipete/status/2078277297791189132
Un bucle es un ciclo de mejora:
intentar algo → verificar el resultado → ajustar → repetir
Ese es el átomo: un solo agente mejorando una cosa en repetición
(Si has leído mi artículo sobre Loop Engineering, esto es eso)
https://x.com/0xCodila/status/2072329149520232639
Pero el bucle único tiene una falla conocida - un equipo de soporte vincula un bucle de retroalimentación a una métrica: la tasa de resolución de tickets
El número sube durante meses mientras la satisfacción baja. El bot aprendió a cerrar tickets rápido en lugar de resolverlos.
Eso es la ley de Goodhart. Un bucle solo puede ver su propia métrica. No puede preguntar si el objetivo es correcto, ni notar que su propia medición se desvía.
La respuesta no es un mejor bucle. Es un grafo de bucles - una red donde los ciclos se observan y se corrigen entre sí.
Para los agentes, esto significa una cosa:
Deja de escribir un solo agente que hace todo en línea recta - diseña la
forma
del trabajo - qué se ejecuta antes de qué, qué se ejecuta al mismo tiempo, qué espera.
Los nodos hacen el pensamiento. Las aristas transportan los resultados
Y Claude Code lanzó las herramientas para construir estos directamente: dynamic workflows
Paso 1 - Ve las aristas que no están ahí
Un grafo tiene dos partes:
- Un nodo es una unidad de trabajo: un agente, un trabajo, una entrada, una salida.
- Una arista es una dependencia: la salida de este nodo alimenta la entrada de ese nodo.
El error que todos cometen es tratar "y luego" como una arista.
"Resume este archivo
y luego
dime el clima"
El clima no lee el resumen.
Esos son dos trabajos independientes que un script lineal encadena sin razón. Cada uno espera al otro para nada.
El hábito que lo inicia todo:
Para cada "y luego", pregúntate: ¿el siguiente paso realmente lee la salida del paso anterior?
- Si sí → arista real. Mantén el orden.
- Si no → no hay arista. La espera es inútil. Ejecútalos en paralelo.
Si no cruzan datos entre dos casillas, son independientes.
Esa independencia es lo que explotarás en el resto de esta guía.
Tu agente simple de "haz A, luego B, luego C" ya es un grafo - solo que el más triste: una cadena única donde si C se atasca, D nunca ocurre.
Paso 2 - Construye tu primer grafo (de principio a fin)
Suficiente teoría. Construye uno y míralo funcionar.
Antes de empezar:
- Claude Code v2.1.154+ (verifica con claude --version)
- Un plan de pago. En Max, Team o Enterprise, los flujos de trabajo están activados por defecto. En Pro, activa la fila Dynamic workflows en /config
1. Abre un repositorio que conozcas.
Uno real, para que el resultado signifique algo.
2. Pega este prompt (basado en Anthropic):
1Crea un flujo de trabajo para auditar cada archivo de ruta bajo src/routes/2en busca de verificaciones de autenticación faltantes. Genera un agente por archivo, luego ejecuta un3verificador independiente en cada hallazgo antes de informar.4Analiza un máximo de 20 archivos para empezar.
Cambia src/routes/ por donde vivan tus archivos. La línea de "máx. 20" mantiene tu primera ejecución económica.
3. Observa cómo se ilumina "workflow".
Claude Code lo resalta: "Dynamic workflow requested." Esa es tu señal de que se está construyendo un grafo, no un chat normal.
4. Aprueba el plan.
Claude escribe un script de orquestación en JavaScript y muestra las fases primero. Léelas, elige "Yes, run it."
5. Deja que la flota se ejecute.
Un agente por archivo, en paralelo, mientras tu sesión permanece libre.
Escribe /workflows para verlo en vivo: alcance, expansión, verificación, síntesis.
6. Lee la única respuesta.
No veinte chats separados. Un solo informe - porque los resultados intermedios vivieron en las variables del script, no en tu contexto.
Eso es un grafo.
Una docena de agentes, desde una sola frase.
Sobre la afirmación de "cero tokens" que escucharás
El script de coordinación es código.
Por lo tanto, pasar resultados entre agentes no gasta contexto de la misma manera que lo haría una transferencia de chat.
Pero los agentes siguen costando uso. Un flujo de trabajo cuesta significativamente más que una sesión normal.
El ahorro está en la coordinación, no en el trabajo. Empieza con un alcance pequeño, vigila el uso, luego amplía.
- Hazlo tuyo
Cuando una ejecución sea buena, presiona s.
Se guarda en ~/.claude/workflows, y se puede volver a ejecutar por nombre.
Ahora cambia la tarea y mantén la forma. Cambia "verificaciones de autenticación faltantes" por "promesas no manejadas", o "funciones de más de 100 líneas".
Hasta dónde escala esto (nombre del artículo)
Una ejecución de flujo de trabajo puede expandirse a 1,000 agentes, con hasta 16 trabajando a la vez.
De ahí viene eso de "1000+ bucles en una ventana" - no es una metáfora, es el límite real de la función.
- Y la escala es el punto. Mil agentes significan un trabajo que ningún contexto individual podría contener - una base de código completa auditada a la vez, una migración que toca cada archivo, una búsqueda que ejecuta mil ángulos en paralelo.
El límite de 16 a la vez solo significa que la flota se mueve en oleadas, devorando los mil sin que tú tengas que supervisar ninguno.
Empieza con 20 para ver cómo se comporta una ejecución y cuánto cuesta - luego ábrelo - porque este es el techo contra el que nadie más está construyendo
Paso 3 - La parte que realmente se rompe
Construiste un grafo. Aquí es donde los reales fallan.
Dos fallos importan más
- Fallo uno: el grafo se contradice a sí mismo
Cuando un agente verifica su propio trabajo, se lo toma con calma. Los modelos prefieren sus propias salidas.
Por lo tanto, pones un verificador en la arista - un nodo separado que confirma un hallazgo antes de que fluya río abajo.
El detalle que nadie menciona: el verificador necesita un contexto limpio
Entrégale la misma conversación que tuvo el ejecutor, y no está verificando. Está contradiciéndose a sí mismo con una fuente diferente.
Un grafo de agentes que comparten un contexto es un solo bucle disfrazado. Falla de la misma manera - más tarde, más caro, con más luces verdes en el camino hacia abajo.
Por lo tanto, el verificador es un nodo nuevo - Contexto propio - Verificando una señal real - no "dijo el agente que está listo", sino "¿la prueba realmente pasa?"
- Fallo dos: agentes pisándose entre sí
Esto no es hipotético
Cuando el equipo de Bun expandió por primera vez un puerto grande a través de muchos agentes, la ejecución falló operativamente - los agentes usaron comandos compartidos de git en un solo espacio de trabajo y se sobrescribieron entre sí.
La solución fue estructural, no un prompt ingenioso. Prohibieron los comandos peligrosos y le dieron a cada grupo su propio árbol de trabajo aislado
Esa es la verdadera lección del paralelismo: dos agentes escribiendo el mismo archivo compiten.
Antes de expandirte, responde tres preguntas:
- ¿Dónde trabaja cada agente?
- ¿Cómo se fusionan los resultados?
- ¿Qué sucede cuando dos no están de acuerdo?
Un grafo sin ese plan no escala - Falla más rápido
Paso 4 - Seis grafos para construir esta semana
El método: encuentra las aristas reales → expande → verifica en contexto independiente → aísla los trabajadores
///
Cada uno de estos tiene la misma forma, apuntando a un nuevo trabajo. Cambia la línea de tarea y adelante:
- Barrido de seguridad - un agente por archivo buscando autenticación faltante, un verificador confirmando cada acierto (el que construiste)
- Informe citado con /deep-research - ya listo: divide tu pregunta en ángulos, busca en paralelo, los agentes se refutan entre sí antes de escribir
- Migrar un módulo - archivo por archivo, pruebas como puerta, fallos en bucle de regreso
- Revisión de diff adversaria - enrutada por tamaño: cambio pequeño → una pasada; grande → auditoría paralela completa
- Escaneo programado del ecosistema - guarda una vez, ejecuta de nuevo por nombre
- Descubrimiento de tamaño desconocido - los buscadores se ejecutan en paralelo, cada resultado se verifica contra todo lo visto, en bucle hasta que dos rondas no encuentren nada nuevo
///
Cómo se ve el techo https://simonwillison.net/2026/Jul/8/rewriting-bun-in-rust/
La migración de Bun de Zig a Rust se ejecutó exactamente con esta maquinaria.
Alrededor de 50 flujos de trabajo, un pico de 64 agentes en paralelo. Aproximadamente 535,000 líneas de Zig convertidas en más de un millón de líneas de Rust, en 11 días.
También costó alrededor de $165,000 en uso. Necesitó un humano diseñando y monitoreando todo el proceso.
Y atrajo críticas públicas sobre si esa cantidad de código generado por IA puede ser revisado de forma segura.
La escala es real. También lo son el precio y la supervisión.
Paso 5 - Los anclajes que mantienen honesto a un grafo
La topología por sí sola no compra la verdad
Una red de agentes que se confirman mutuamente, sin que ninguno toque nada real, falla exactamente como lo hizo el bucle único - solo que con más piezas móviles.
El grafo necesita anclajes: nodos que no pueden ser discutidos.
- Pruebas que realmente se ejecutaron - no "deberían pasar", pasaron
- Un verificador basado en evidencia, no en sensaciones
- Reglas congeladas que los agentes nunca pueden ajustar - porque son las que un optimizador debilitaría
El grafo es tan honesto como las cosas que contiene que se niegan a moverse
Cuándo un grafo es la elección equivocada
La mayoría de las tareas no son grafos. Recurrir a uno cuando no lo necesitas solo quema dinero y agrega formas de fallar.
Omite el grafo cuando:
- La tarea es pequeña o aislada. Agregar una función, corregir un error. Un flujo de trabajo es pura sobrecarga aquí - un solo agente es más rápido y más barato.
- Necesitas supervisión estricta. Si quieres leer y aprobar cada paso antes de que se ejecute el siguiente, el objetivo principal de un grafo (ejecutarse en amplitud sin ti) juega en tu contra.
- Aún no sabes lo que buscas. El trabajo exploratorio quiere un agente que puedas dirigir, no una flota comprometida con un plan antes de que entiendas el problema.
- Los pasos realmente dependen unos de otros. Si cada paso lee la salida del paso anterior, es una cadena real. El paralelismo no tiene nada que aprovechar. Forzar un grafo sobre una tarea verdaderamente secuencial solo agrega costo de coordinación sin aceleración.
La señal es el Paso 1. Si no puedes encontrar dos casillas sin una flecha entre ellas, no hay grafo que construir. Es un bucle, y un bucle está bien.
Un grafo es una herramienta para la amplitud - trabajo independiente, realizado a la vez.
Cuando el trabajo no es amplio, la línea nunca fue el problema...
El cambio
Un creador de prompts hace una pregunta. Un arquitecto dibuja un grafo.
El agente lineal nunca fue el techo.
Fue la primera forma - la que todos eligen porque coincide con cómo escribimos: una línea, una cosa a la vez.
Una vez que ves los nodos y las aristas, dejas de pedirle al agente que haga más y empiezas a pedirle al grafo que lo haga más amplio:
- Expande donde el trabajo es independiente
- Controla las aristas donde la confianza importa
- Congela los nodos que contienen la verdad
La mayoría seguirá poniendo pasos en cola en una línea.
Los pocos que aprendan a dibujar el grafo, y a respetar lo que lo rompe, ejecutarán una flota.
Dibuja el grafo. Sigue siendo el arquitecto.
Comienza con el requisito previo:
- el bucle único en el que se basa esto
