Hay una tensión que quien ya integró agentes a su flujo conoce bien: el mismo modelo que resuelve un refactor complicado en tres minutos te mete un bug silencioso si lo sueltas sobre una tarea mal acotada. Funciona cuando el problema está cercado. Falla cuando tiene que decidir el orden de los pasos. Y el “orden de los pasos”, en un feature real, es casi todo el trabajo.
Archon entra exactamente ahí. La propuesta es sencilla de enunciar y tramposa de ejecutar: describir el proceso como un DAG en YAML, y que el agente sólo decida dentro de cada nodo. Quitarle al modelo la parte en la que peor rinde — la planificación global — y dejarle la parte en la que brilla: ejecutar tareas delimitadas, una a la vez, con contexto recortado.
Antes de instalarlo dedicamos una tarde a entenderlo desde afuera. Esto es lo que encontramos.
Qué hace realmente
Archon es un runner de DAGs pensado para AI coding. Un DAG — grafo dirigido acíclico — es simplemente un conjunto de nodos conectados por aristas, donde no hay ciclos: el flujo avanza, nunca vuelve. Es el mismo modelo mental que GitHub Actions, Airflow o make, trasplantado al territorio donde los nodos no son builds ni ETL, sino llamadas a un LLM, comandos de shell y bucles sobre listas.
La apuesta filosófica es el determinismo. En un workflow imperativo con agente — “resuelve este issue” — el modelo decide qué pasos dar, en qué orden, y con qué contexto. Dos ejecuciones del mismo prompt producen dos rutas distintas. Eso está bien para explorar; es horrible para auditar. Cuando algo se rompe en producción, quieres saber qué pasos corrieron, en qué orden, con qué inputs. Un DAG en YAML te da esa propiedad gratis: el grafo es el mismo siempre, versionado en git, revisable en PR. Lo único no determinista es el contenido que genera cada nodo AI — y eso ya lo sabías.
La diferencia práctica con “dejar que Claude Code orqueste el feature” es la misma que hay entre una receta y una improvisación. Ambas pueden salir bien. Sólo una se puede repetir.
Cómo funciona por dentro
Cada nodo tiene un tipo: ai (llamada a LLM con prompt template), bash (comando), command (acción interna de Archon, tipo abrir PR), loop (iterar sobre una lista) y parallel (ejecutar varios en simultáneo). Las aristas describen dependencias: un nodo espera a que sus predecesores terminen, y recibe sus outputs como variables.
El detalle clave es el contexto. Los nodos AI no reciben toda la historia del workflow. Reciben lo que el YAML les pasa explícitamente. Eso te obliga a diseñar los inputs de cada paso, que es exactamente la disciplina que falta cuando uno deja al agente correr libre. Pensar qué ve cada nodo es la mitad del trabajo bien hecho.
Un ejemplo plausible, tipo refactor-auth.yml:
name: refactor-auth
description: Migra módulo de auth a nuevo provider
nodes:
plan:
type: ai
prompt: |
Analiza {{ files }} y propón plan de migración
a {{ target_provider }}. Devuelve lista de subtareas.
inputs:
files: "src/auth/**/*.ts"
target_provider: "clerk"
implement:
type: loop
over: "{{ plan.subtasks }}"
parallel: 3
node:
type: ai
prompt: "Aplica subtarea: {{ item }}"
depends_on: [plan]
test:
type: bash
cmd: "bun test src/auth"
depends_on: [implement]
open_pr:
type: command
action: github.create_pr
title: "refactor(auth): migrate to {{ target_provider }}"
depends_on: [test]Cuatro nodos, una dependencia clara por arista, un loop paralelo limitado a 3, y un gate de tests antes del PR. Nada mágico. Eso es justamente la gracia.
Pros
- Determinismo estructural. La forma del trabajo es la misma cada vez. Si el PR salió raro, abres el YAML, no adivinas qué pensó el modelo.
- Paralelismo real. El runner ejecuta ramas independientes en simultáneo, con aislamiento por git worktree cuando toca archivos. Cinco fixes a la vez sin pisarse.
- Trazabilidad. Cada nodo deja log con inputs, outputs y duración. Auditar un fallo es leer, no reconstruir.
- Versionable. Los workflows viven en el repo. Los revisas en PR como cualquier otro código. Un cambio de comportamiento del pipeline deja diff.
- Contexto recortado por diseño. Te fuerza a pensar qué ve cada paso. El resultado es mejor prompting por omisión.
- Extensible en YAML. No tienes que escribir plugins en TypeScript para tu propio flujo. Escribes otro YAML.
Contras
- Curva de YAML no trivial. Si nunca escribiste un Actions medianamente serio, los primeros workflows se te van a ir. Indentación, templating, dependencias: todo duele al inicio.
- Overkill para one-shots. Para “arregla este typo” no montas un DAG. Archon empieza a pagar cuando el proceso se repite.
- Rigidez vs exploración. El determinismo tiene precio. Cuando aún no sabes cuáles son los pasos, escribirlos en YAML es prematuro — vas a reescribir el archivo más que el código.
- Dependencia de runtime. Bun/TypeScript. No es drama, pero es una pieza más en tu stack y un upgrade más que vigilar.
- Sesgo hacia GitHub. Los comandos internos de automatización asumen ese flujo. Si tu shop vive en GitLab o Gitea, hay fricción.
Cuándo sí, cuándo no
Sí cuando tienes un feature que ya hiciste tres veces con variaciones: el mismo esqueleto, distintos detalles. Migraciones, refactors repetitivos, triage de issues, revisión multi-ángulo de PRs. Cualquier cosa donde el valor está en el proceso, no en el descubrimiento.
No cuando estás entendiendo el problema. Si todavía no sabes si el bug es de red, de estado o de concurrencia, no metas un DAG — abre una terminal y conversa con el agente. Archon es la fase de industrialización, no la de exploración. Confundir ambas es la forma más común de odiar una herramienta por razones que no son suyas.
La regla corta: si puedes escribir el workflow sin ejecutarlo, úsalo. Si necesitas ejecutarlo para saber qué debe hacer, todavía no.
Veredicto
Archon nos convenció como pieza de orquestación, no como reemplazo de la capa de ejecución. Encima de Superpowers, GSD o tu agente favorito, el DAG en YAML resuelve el problema que más nos ha mordido: que el mismo feature, ejecutado dos veces, termine siendo dos features. Debajo del DAG sigues necesitando un agente que implemente bien cada nodo. Archon no sustituye eso. Le pone rieles.
Para equipos pequeños con procesos repetibles y gusto por el audit trail, el costo de entrada se paga en el segundo workflow. Para lobos solitarios haciendo prototipos, probablemente no. Lo vamos a meter en nuestro flujo como capa opcional — los features grandes pasan por YAML, los ajustes chicos no — y ya veremos si se queda. La primera impresión, sin instalarlo, es que tiene más probabilidad de quedarse que de estorbar.
TL;DR — Archon no reemplaza al agente, le pone un grafo encima; úsalo cuando el proceso sea más valioso que el descubrimiento.