El sucesor de Loop Engineering y el flujo de trabajo que ejecuta tus agentes 10 veces más amplio...
La mayoría de la gente que construye un agente multi-paso termina con una línea recta
paso uno, paso dos, paso tres. Cada uno esperando a que el último termine antes de empezar
Esto es lo que casi nadie comprueba:
la mitad de esos pasos nunca necesitaban 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 desde esa línea hasta un grafo que se despliega a través de una flota y revisa su propio trabajo.
Cinco pasos. En 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 empiezan las partes difíciles.
antes del alpha - suscríbete a mi substack para más alpha fresco ↓
Capítulo 0 - Qué es realmente la ingeniería de grafos
Hace un mes, el campo hablaba de bucles (loops).
Peter Steinberger lo capturó en nueve palabras:
https://x.com/steipete/status/2078277297791189132
Un bucle es un ciclo de mejora:
intentar algo → comprobar el resultado → ajustar → repetir
Ese es el átomo: un solo agente mejorando una cosa de forma repetitiva.
(Si has leído mi artículo sobre Loop Engineering, esto es eso)
https://x.com/0xCodila/status/2072329149520232639
Pero el bucle simple tiene un fallo conocido: un equipo de soporte vincula un bucle de retroalimentación a una sola métrica: 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 preguntarse si el objetivo es correcto, ni notar que su propia medición está derivando.
La respuesta no es un bucle mejor. Es un grafo de bucles - una red donde los ciclos se observan y se corrigen mutuamente.
Para los agentes, eso significa una cosa:
Deja de escribir un agente que lo 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 esto directamente: flujos de trabajo dinámicos
Paso 1 - Ver 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 anterior por 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 es sí → arista real. Mantén el orden.
- Si es no → no hay arista. La espera es una pérdida de tiempo. Ejecútalos en paralelo.
Si no hay datos que crucen entre dos cajas, son independientes.
Esa independencia es lo que explotarás durante 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 única cadena 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+ (compruébalo 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 (cortesía de Anthropic):
1Create a workflow to audit every route file under src/routes/2for missing auth checks. Spawn one agent per file, then run an3independent verifier on each finding before reporting.4Analyze a maximum of 20 files to start.
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." Eso 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 primero las fases. Léelas, elige "Sí, ejecútalo".
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, despliegue, verificar, sintetizar.
6. Lee la única respuesta.
No veinte chats separados. Un solo informe - porque los resultados intermedios vivían 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 vuelve a gastar contexto como 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 "comprobaciones 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 desplegarse hasta 1,000 agentes, con un máximo de 16 trabajando a la vez.
De ahí viene eso de "más de 1000 bucles en una ventana" - no es una metáfora, es el límite real de la funcionalidad.
- Y la escala es el punto. Mil agentes significan un trabajo que ningún contexto individual podría contener jamás: una base de código completa auditada a la vez, una migración que toca todos los archivos, una búsqueda que ejecuta mil enfoques en paralelo.
El límite de 16 a la vez solo significa que la flota se mueve en oleadas, procesando los mil sin que tengas que supervisar ni uno solo.
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
Has construido un grafo. Aquí es donde los reales se caen.
Dos fallos importan más
- Fallo uno: el grafo está de acuerdo consigo mismo
Cuando un agente revisa su propio trabajo, se lo pone fácil. Los modelos prefieren sus propias salidas.
Por eso pones un verificador en la arista - un nodo separado que confirma un hallazgo antes de que fluya hacia abajo.
El truco que nadie menciona: el verificador necesita un contexto limpio.
Si le pasas la misma conversación que tuvo el ejecutor, no está verificando. Está asintiendo con otro nombre.
Un grafo de agentes que comparten un mismo contexto es un bucle único disfrazado. Falla de la misma manera - más tarde, más caro, con más luces verdes en el camino.
Por lo tanto, el verificador es un nodo nuevo - Contexto propio - Comprobando una señal real - no "dijo el agente que está hecho", sino "¿la prueba realmente pasa?"
- Fallo dos: agentes pisándose unos a otros
Esto no es hipotético
Cuando el equipo de Bun desplegó por primera vez un gran port en muchos agentes, la ejecución falló operativamente - los agentes usaban comandos git compartidos en un mismo espacio de trabajo y se sobrescribían entre sí.
La solución fue estructural, no un prompt ingenioso. Prohibieron los comandos inseguros y 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 desplegarte, responde a tres preguntas:
- ¿Dónde trabaja cada agente?
- ¿Cómo se fusionan los resultados?
- ¿Qué pasa 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: encontrar las aristas reales → desplegar → verificar en contexto independiente → aislar a los trabajadores.
///
Cada uno de estos es la misma forma, apuntando a un nuevo trabajo. Cambia la línea de tarea y hazlo:
- Barrido de seguridad - un agente por archivo buscando autenticación faltante, un verificador confirmando cada acierto (el que ya construiste).
- Informe citado con /deep-research - ya se envía: divide tu pregunta en ángulos, busca en paralelo, los agentes se refutan entre sí antes de escribir.
- Portar un módulo - archivo por archivo, pruebas como puerta de acceso, fallos devueltos al bucle.
- Revisión adversarial de diffs - enrutado por tamaño: cambio pequeño → una pasada; cambio grande → auditoría paralela completa.
- Escaneo programado del ecosistema - guarda una vez, vuelve a ejecutar por nombre.
- Descubrimiento de tamaño desconocido - buscadores se ejecutan en paralelo, cada resultado verificado contra todo lo visto, en bucle hasta que dos rondas no encuentren nada nuevo.
///
Cómo se ve el techohttps://simonwillison.net/2026/Jul/8/rewriting-bun-in-rust/
El port de Zig a Rust de Bun se ejecutó exactamente con esta maquinaria.
Alrededor de 50 flujos de trabajo, con 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 USD en uso. Necesitó un humano diseñando y supervisando todo el proceso.
Y atrajo críticas públicas sobre si esa cantidad de código escrito 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 unos a otros, sin que ninguno toque nada real, falla exactamente igual que el bucle simple - solo que con más piezas móviles.
El grafo necesita anclajes: nodos con los que no se puede discutir.
- 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 solo 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 añade formas de fallar.
Saltate el grafo cuando:
- La tarea es pequeña o aislada. Añadir una función, corregir un error. Un flujo de trabajo es pura sobrecarga aquí - un solo agente es más rápido y barato.
- Necesitas una 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 paralelo 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 dependen genuinamente unos de otros. Si cada paso lee la salida del paso anterior, es una cadena real. El paralelismo no tiene nada que agarrar. Forzar un grafo en una tarea verdaderamente secuencial solo añade coste de coordinación sin aceleración.
La pista está en el Paso 1. Si no puedes encontrar dos cajas sin 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, hecho a la vez.
Cuando el trabajo no es amplio, la línea nunca fue el problema...
El cambio
Un prompteador hace una pregunta. Un arquitecto dibuja un grafo.
El agente lineal nunca fue el techo.
Fue la primera forma - la que todos usan 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:
- Despliega donde el trabajo es independiente.
- Controla las aristas donde la confianza importa.
- Congela los nodos que contienen la verdad.
La mayoría de la gente 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.
Empieza con el requisito previo:
- el bucle simple en el que se basa esto
