Diseño de bucles de agentes autónomos ── Arquitectura más allá del prompt

※Este artículo se basa en material interno (formato con diagramas) que ha sido estructurado en forma de manuscrito. El tema es el diseño de una arquitectura resiliente de múltiples agentes "Generator-Evaluator" que permite que el trabajo de escribir código, revisarlo e integrarlo continúe incluso mientras las personas duermen.

El fin del "reloj humano"

El uso tradicional de IA funcionaba bajo el "reloj humano". El agente espera entrada, la persona presiona Enter, se generan tokens, se detiene. Esta es la repetición. En junio de 2026 llegó un punto de inflexión. Peter Steinberger (OpenClaw), Boris Cherny (Claude Code) y Addy Osmani (Chrome) convergieron independientemente hacia la misma conclusión dentro de la misma semana. Las herramientas han superado el umbral.

La esencia del cambio es esta: dejar de ser la persona que escribe indicaciones para un agente y convertirse en la persona que diseña un sistema que lo haga en su lugar. El motor de bucle autónomo posee tres características: (1) se activa mediante un temporizador (se despierta según un cronograma), (2) genera subagentes paralelos (ayudantes), y (3) se alimenta a sí mismo (la salida de ayer se convierte en la entrada de hoy).

Pila de protocolo de IA de 4 capas

Las capas del uso de IA se pueden organizar en cuatro niveles, y cuanto más arriba está la capa, mayor es el radio de explosión del impacto de la falla.

Capa	Preocupación central	Unidad de límite	Radio de impacto de falla	Posición de la persona
Capa 1: Indicación	Qué comunicar al modelo	Un intercambio	Error evidente de inmediato	Mecanógrafo
Capa 2: Contexto	Qué poner en la ventana	Una sesión	Razonamiento erróneo con confianza	Editor
Capa 3: Arnés	Armar una ejecución (herramientas/acciones)	Una tarea	Diferencia defectuosa capturada antes del envío	Revisor
Capa 4: Bucle	Programación del arnés	Iteración desatendida	Corrosión que erosiona la estructura en el transcurso de días	Arquitecto

Anatomía de un bucle que sigue girando

El bucle autónomo consta de cinco nodos.

1. Descubrimiento (Discovery) ── Respaldado por Skills (SKILL.md). Conocimiento permanente del proyecto que devuelve el "débito de intención".

2. Traspaso (Handoff) ── Respaldado por Worktrees. Directorios git independientes para ejecución paralela.

3. Verificación (Verification) ── Respaldado por subagentes. Separación Generator-Evaluator. "Una entidad que puede decir que no".

4. Persistencia (Persistence) ── Respaldada por conectores (MCP) y memoria. El estado se coloca en archivos en disco (como ./state/triage.md). Los agentes olvidan, pero el repositorio no.

5. Programación (Scheduling) ── Respaldada por la infraestructura de automatización (cron local, GitHub Actions, rutinas en la nube). Cierra el ciclo.

Paralelización con Worktree

Problema: Dos agentes que editan el mismo directorio de trabajo es lo mismo que dos ingenieros que confirman la misma línea. Las colisiones rompen un pipeline desatendido. Primitivo: Separa directorios de trabajo independientes como claude --worktree fix/auth-test 'draft the fix'. Efecto: Convierte la paralelización de "funciona pero es desordenado" a "funciona y está limpio". Múltiples directorios de trabajo independientes dentro de un único repositorio permiten un triaje de problemas de alto rendimiento.

Burbuja de autopersuasión ── Separar Generator y Evaluator

El antipatrón es que el generador se califica a sí mismo. El generador no está mirando su código, está mirando una cadena de su propia autopersuasión. La separación GAN divide al generador y al evaluador, asignando al evaluador el papel de revisor de código adversario. "Asume que este código está roto hasta que se refute. No lo elogies. Encuentra dónde falla".

La perspectiva central: Afinar un evaluador independiente para ser un escéptico riguroso es matemática y prácticamente mucho más factible que lograr que el generador sea crítico con su propio trabajo.

Juicio mediante ejecución externa

Defecto: Si el evaluador solo lee código, el juicio es "¿se ve correcto?" en lugar de "¿funciona correctamente?". Cambio: Conecta el evaluador a un entorno de ejecución externo (por ejemplo, Playwright MCP). Nuevo estándar: El evaluador hace clic en botones, fuerza transiciones de pantalla, obtiene el estado del DOM, ejecuta pruebas. El juicio se desplaza de "intención" a "comportamiento". El flujo es: agente evaluador → conector Playwright MCP → inspección del DOM/capturas de pantalla/ejecutor de pruebas → veredicto de aprobado/rechazado.

Condiciones de parada de Maker-Checker

¿Cuándo debe terminar el bucle? El primitivo /goal expresa "girar hasta que se cumplan las condiciones" (por ejemplo: /goal todas las pruebas en test/auth pasan y lint está limpio). Generator (modelo pesado) escribe código, Evaluator (modelo pesado) ejecuta pruebas a través de MCP, Gatekeeper (modelo rápido y fresco) evalúa /goal. Si se cumple, sale del bucle; si falla, devuelve la razón del rechazo a Generator.

Principio: El juicio de finalización debe ser hecho por un modelo fresco que no lleve ningún equipaje del contexto del modelo que realizó el trabajo. Y hay una frase para recordar. El piso del bucle es el evaluador. El generador decide el techo de lo que se produce, el evaluador decide el piso de lo que no se produce.

Cinco formas en que falla el bucle

Elemento faltante	Antipatrón	Síntoma	Corrección requerida
Falta de verificación	Bucle que solo asiente	100 turnos aprobando su propio basura	Implementación de separación Generator-Evaluator
Falta de persistencia	Bucle amnésico	Redescubre el mismo trabajo exacto cada mañana	Fuerza escritura de archivo de estado a disco
Falta de programación	Bucle manual	No ha funcionado desde el día que lo demostré	Conecta cron/disparadores de eventos
Falta de descubrimiento	Bucle ciego	Todavía dedica 30 minutos cada vez pegando "arregla este error"	Incrustra heurística en SKILL.md
Falta de traspaso	Bucle enredado	5 agentes paralelos corrompen un directorio git	Fuerza separación con --worktree

Intercalado determinista a escala empresarial

El pipeline "Minions" de Stripe sigue el flujo: disparador (Slack) → orquestador de contexto (Sourcegraph/Jira) → generación de código (LLM) → puerta de linter obligatoria → corrección de Lint (LLM) → commit de Git → revisión humana (1.300 PR por semana), fusionando 1.300 PR generadas por máquina por semana (impulsado por el framework de código abierto Goose).

El secreto es hacer trabajo determinista con sistemas deterministas. La recopilación de contexto y el linting están codificados rígidamente, y el LLM está completamente confinado dentro de guardias de reglas duras. El entorno se trata como "ganado, no mascotas (Cattle, Not Pets)", y los Devbox en EC2 se descartan e intercambian de inmediato para evitar corrupción de estado.

Topología de ejecución ── ¿Dónde vive el bucle?

Topología	Estado de máquina	Sesión	Intervalo mínimo	Acceso a FS local
Nube (Cloud Routines / GitHub Actions)	Posible con máquina OFF	No requerido	1 hora	Ninguno (clon limpio) → Ideal para triaje nocturno
Escritorio (macOS cron)	Máquina ON	No requerido	1 minuto	Sí → Ideal para mantenimiento periódico de repositorio
Local (/loop comando)	Máquina ON	Requerido	1 minuto	Sí → Ideal para verificaciones de alta frecuencia durante desarrollo

Llamar a la reejecución local "funcionando mientras dormimos" es una exageración. La programación local compra frecuencia; la programación en la nube compra verdadera autonomía. No puedes obtener ambas con un solo programador.

Ciclo vicioso de bucles desatendidos

Hay cuatro riesgos en los bucles desatendidos. Débito de verificación (fusión de código que pasa pruebas pero contiene defectos lógicos sutiles) → Corrupción de comprensión (el mapa mental del codebase se desvía de la realidad) → Rendición cognitiva ("no entiendo cómo funciona, pero aceptemos el PR") → Desperdicio de tokens (el agente desatendido genera ayudantes toda la noche, reintentando correcciones de errores inútiles). Estos no son cuatro riesgos separados, sino un único modo de fallo compuesto. Un bucle sin un evaluador riguroso ha delegado la autoridad de gasto a su propio error.

Economía de la generación de costo cero

Lo que se vuelve abundante: Generación. El costo del código, planes, correcciones y solicitudes de fusión tiende a cero, y el trabajo mecánico colapsa. Lo que sigue siendo escaso: Juicio. El bucle puede generar 100 candidatos de implementación, pero la selección se basa en "parece correcto" en lugar de "es realmente correcto". El bucle como amplificador: El bucle es un signo de multiplicación fiel. Si llevas comprensión, amplifica comprensión; si llevas negligencia, amplifica desastre.

Disyuntores operativos

1. Siempre lee muestras (defensa contra corrupción de comprensión): Cada día, verifica si puedes explicar un PR generado por máquina elegido al azar en tus propias palabras. Si no puedes, tu mapa mental ya es antiguo.

2. Establece límites antes del envío (defensa contra desperdicio de tokens): Los límites de presupuesto por ejecución o números máximos de reintentos no son para ahorrar, sino para convertir riesgos abiertos en riesgos acotados, disyuntores.

3. Deja una puerta abierta (defensa contra rendición cognitiva): Crea al menos un punto de control que ponga pausa para humanos. No para intervenir cada vez, sino para garantizar que la intervención sea posible.

Desplegar el bucle resiliente mínimo

La configuración mínima funciona así: Se dispara por cronograma (cron: automatización en la nube), ejecuta habilidad (morning-triage: descubrimiento), escribe el resultado en ./state/triage.md (persistencia). Los arreglos descubiertos se ejecutan con worktree (fix/$finding: traspaso), se juzgan con /goal "pruebas pasan y lint está limpio" (verificación). Las carpetas de salida se dividen en ./inbox/ (todo lo no verificado), ./state/, ./src/, con la regla de que nunca realices fusión automática. Todo lo no verificado aterriza en ./inbox/.

Finalmente, cierro con esta frase.

«Crea bucles. Pero hazlo como alguien que seguirá siendo ingeniero. No como alguien que solo presiona botones.»