DIL R5.0-AG: pastorear agentes IA con Herdr, GitHub y un Director que despierta solo
Este fin de semana ocurrió algo discreto, pero importante. Mientras yo estaba fuera de casa, el Director en ChatGPT siguió coordinando una implementación iniciada en mi entorno de desarrollo.
No tomó autoridad sobre el proyecto. No decidió publicar ni fusionar nada. Coordinó un trabajo acotado, recibió evidencia durable y pudo reanudar el proceso cuando el sistema le avisó de que había algo verificable.
Para mí, ahí está el punto de inflexión. El trabajo dejó de consistir sólo en escribir cada paso de implementación y empezó a parecerse más a diseñar el sistema donde esos pasos pueden delegarse con límites claros.
«Pastorear agentes IA» no significa soltarlos
Uso la metáfora con cuidado. Pastorear agentes IA no es lanzar una manada de procesos y esperar que aparezca software correcto.
Es definir intención, contratos, autoridad, evidencia y fronteras de intervención. Es saber qué puede hacer cada actor, cómo demuestra lo que hizo y en qué punto debe detenerse.
El cambio de oficio se parece a esto:
antes
escribir → comprobar → corregir → entregar
ahora
definir intención y límites
→ delegar una implementación acotada
→ exigir evidencia verificable
→ intervenir en los gates de decisiónSigo programando. Pero una parte creciente del valor está en diseñar el terreno: rutas seguras, estados observables, contratos de handoff y mecanismos de recuperación.
R4.6 puso las fronteras; R5.0 conecta el circuito
R4.6-AG separó desarrollo, calificación, integración, entrega y cierre.
También fijó el Implementer Delivery Pack: Evidence Pack, Acceptance Checklist, Acceptance Surface y feedback del harness. El Implementer construye y se detiene; el humano acepta; el Director audita y decide.
R5.0-AG no sustituye ese contrato. Añade la infraestructura para mover el trabajo entre esos límites sin convertir una conversación abierta o un proceso vivo en fuente de verdad.
La identidad durable sigue siendo sencilla:
Draft PR
+ exact HEAD
+ canonical Implementer Delivery Pack
= delivery verificableSi falta una de esas piezas, no hay candidato fiable para el Director.
La arquitectura, de extremo a extremo
El flujo promovido durante dotfiles v0.6 y v0.7 queda así:
Humano define intención y autoridad
│
▼
Director emite un Handoff Order
│
▼
devx aplica policy y despacha
│
▼
Herdr transporta y supervisa la ejecución
│
▼
Implementer trabaja en sandbox
│
▼
Draft PR + exact HEAD + Delivery Pack
│
▼
callback verificado por el repositorio
│
▼
dil-director-ready:v1 en GitHub
│
▼
GitHub → ChatGPT despierta al Director
│
▼
auditoría + CI + aceptación humana
│
▼
READY, integración, entrega y cierreCada caja tiene una responsabilidad distinta. La potencia no viene de borrar fronteras, sino de conectarlas sin confundirlas.
Herdr ejecuta; no decide qué es verdad
Herdr aporta el puente de dispatch y el cockpit de ejecución. Su resident bridge puede informar de salud, recuperar transporte y mantener disponible el camino hacia los workers.
Pero Herdr no es la autoridad de delivery. Un proceso activo no demuestra que haya una entrega, y un resultado de transporte incierto no significa que el trabajo durable no exista.
Por eso R5.0 separa tres estados:
transport_state → qué ocurrió al despachar
worker_state → qué sabemos del proceso
delivery_state → qué evidencia exact-head existeEsta separación parece pequeña hasta que algo falla. Si un comando termina como uncertain, el sistema inspecciona PR, HEAD y Delivery Pack antes de repetir una ejecución que quizá ya produjo resultados.
Es recovery basado en evidencia, no en intuición.
Un Implementer fluido, pero acotado
El perfil Codex DIL funciona sin interrupciones de aprobación durante la implementación. Eso evita que un trabajo autorizado quede bloqueado esperando clics rutinarios.
«Approval-free» no significa «sin límites». El agente sigue dentro de un sandbox, un workspace canónico, una rama concreta, un scope explícito y unas stop conditions.
Cursor existe como continuación para clases de fallo acotadas. No es un segundo Implementer compitiendo ni una excusa para relanzar trabajo ante cualquier duda.
La regla sigue siendo un slice, un dueño de implementación y una historia durable.
El callback que convierte actividad en señal
El salto importante no es que un worker termine. Es que el repositorio pueda verificar lo que afirma ese worker.
El callback verifier pertenece al repositorio consumidor. Comprueba que la Draft PR, el HEAD publicado y el Delivery Pack canónico describen la misma entrega.
Sólo entonces aparece la señal dil-director-ready:v1.
La señal no dice «todo está bien». Dice algo más preciso: «existe evidencia durable, coherente y lista para que el Director la audite».
Esa precisión permite conectar GitHub con ChatGPT de forma event-driven. El Director despierta por un hecho verificable; no necesita consultar GitHub continuamente ni mantener un agente mirando CI.
Despertar no es recibir autoridad
Aquí está la frontera que evita convertir automatización en autonomía descontrolada:
wakeup
≠ aceptación humana
≠ auditoría del Director
≠ CI aceptada
≠ Ready for Review
≠ permiso de merge, release o deployEl Director recupera el contexto exact-head, interpreta las validaciones y respeta el gate humano. Despertar sólo reanuda su responsabilidad; no amplía sus permisos.
Desktop Commander ocupa otra posición. Es el brazo operativo local del Director para inspeccionar y actuar sobre la máquina, pero no es el mecanismo que observa GitHub ni el que decide cuándo despertar.
GitHub conserva la coordinación y el audit trail. Tampoco es autoridad editorial: el contenido sigue obedeciendo a la fuente canónica de cada dominio.
CI sigue siendo CI
Los agentes no reemplazan la integración continua. El Implementer valida localmente; la PR ejecuta su CI; el Director interpreta el resultado del HEAD exacto.
El main-sentinel ligero cumple otra misión: comprobar de forma independiente que el commit integrado conserva invariantes básicos sin repetir toda la suite de la PR. No es la señal de wakeup y no sustituye ni la CI completa de la PR ni la verificación posterior de la entrega.
Separar señal de gate evita una tentación frecuente: usar cualquier automatización disponible como prueba de corrección.
Lo que no construimos
No construimos un swarm. No hay una multitud de agentes repartiéndose el repositorio sin ownership claro.
No entregamos merge, release o deploy a un webhook. Esas acciones permanecen detrás de aceptación humana y autoridad explícita del Director.
No sustituimos CI por opiniones de agentes. Tampoco pedimos al Director que haga polling de GitHub o que mantenga watchers consumiendo atención sin trabajo útil.
Y no incluimos aquí la línea Python-first de dotfiles v0.8. Es otro hilo arquitectónico, con su propio problema y su propia evidencia.
Una escena pequeña que cambia el trabajo
Lo memorable del fin de semana no fue ver un agente escribir código. Eso ya no es nuevo.
Fue comprobar que, mientras yo estaba fuera, el sistema podía conservar intención, ejecutar dentro de límites, publicar evidencia y devolver el control al Director en el momento adecuado.
Mi ausencia no otorgó autonomía adicional. La arquitectura mantuvo quietas las decisiones que me correspondían y permitió avanzar sólo donde ya existía autoridad.
Eso se acerca más a una organización técnica que a un chat inteligente.
La competencia está en el sistema, no en el espectáculo
Diseñar este circuito obliga a practicar arquitectura de IA aplicable: modelar estados, separar autoridad de transporte, diseñar idempotencia y recovery, proteger sandboxes y producir observabilidad útil.
También obliga a integrar piezas heterogéneas: CLI, agentes, GitHub, CI, callbacks, eventos y herramientas locales. El reto no es hacer que hablen, sino impedir que una conversación suplante un contrato.
Ésa es la capacidad profesional que me interesa desarrollar. No «usar IA» como etiqueta, sino construir sistemas donde agentes y humanos puedan colaborar con responsabilidades legibles.
R5.0-AG en una frase
R4.6 enseñó dónde terminaba cada responsabilidad. R5.0 conecta esas fronteras mediante un fabric de ejecución y un wakeup verificable, sin entregar a la automatización la autoridad que pertenece a personas y gates.
El mapa durable del harness vive en el proyecto Dotfiles. Esta revisión cuenta el momento en que ese mapa dejó de ser sólo infraestructura local y empezó a sostener una coordinación agentic realmente event-driven.