🎯 Qué es el Agent Control Plane
Cole Medin construyó Agent Control Plane como respuesta directa a los problemas que identificó con el loop engineering puro. Y es un dashboard de código abierto en GitHub que funciona como el sistema nervioso central de cualquier configuración de loops: durabilidad, observabilidad y human-in-the-loop en un solo lugar.
"Construí este dashboard que me entusiasma mucho mostrarte ahora mismo. De hecho, lo publiqué como código abierto en GitHub. Lo hice para resolver muchos de los problemas que tenemos ahora con la ingeniería de loops."
🧩 Los tres pilares del dashboard
Durabilidad
Todos los loops, eventos y logs quedan en Postgres. Si el agente falla, el orchestrator retoma desde donde se detuvo leyendo el state de la base de datos.
Observabilidad
Ver en tiempo real las decisiones del orchestrator, el progreso de los workers y el costo acumulado por run.
Human-in-the-Loop
Pausar el loop entre rondas, validar los resultados y aprobarlos o rechazarlos antes de continuar.
Contexto: por qué existe esto
Cole es honesto al decir que esto es "more experimental". Pero la motivación es concreta: sin un dashboard, los loops son cajas negras. Los pones en marcha, te vas y, cuando vuelves, no sabes si el resultado es bueno o si gastó tokens en vano. Agent Control Plane es un intento de resolver esto de forma práctica y replicable.
💾 Postgres/Neon como almacén de estado
El corazón del sistema es una base de datos Postgres alojada en Neon (Postgres serverless). Todo el estado de los loops está ahí: en qué ronda estamos, qué workers se iniciaron, cuáles terminaron, cuáles fallaron y cuál es el costo acumulado.
"Gestionamos todo nuestro estado en una base de datos externa. Así no dependemos de que se conserve en una sesión de un agente de programación."
🔄 El ciclo orchestrator-state-workers
El orchestrator lee el state
Consulta la base de datos para saber: ¿qué tareas están pendientes? ¿Qué workers completaron su trabajo? ¿Cuál es el progreso general?
El orchestrator decide y asigna workers
Con base en el estado, planifica la siguiente ronda y lanza workers con prompts específicos.
Los workers actualizan el estado
Cada worker guarda su resultado en la base de datos. El orquestador ve el estado actualizado en la siguiente ronda.
El loop continúa hasta completarse
El ciclo se repite hasta que el orchestrator determine que todas las tareas están completas o hasta que intervenga una persona en el human-in-the-loop.
🔍 Observabilidad: decisiones en tiempo real
El verdadero poder del dashboard está en ver exactamente qué decide el orchestrator en cada round: cuántos workers inicia, qué prompts envía y cómo reacciona a los resultados que recibe. Sin esto, estás pilotando a ciegas.
"Poder ver exactamente las decisiones que se toman aquí hace que me resulte más fácil revisar todo esto, incluso hacer que mi agente de programación analice las ejecuciones en la base de datos y luego descubrir cómo mejorar el loop."
Lo que ves en el dashboard
- ✓Historial completo de ejecuciones con todas las rondas
- ✓Decisiones del orchestrator por ronda (cuántos workers, qué tareas)
- ✓Tokens consumidos por ronda y por worker
- ✓Estado de cada worker: completó, falló, en progreso
La demostración en vivo
Cole lo demostró en vivo en el video: creó un prompt para construir un tablero Kanban como single-page app y puso en marcha el loop. En el dashboard, se podía ver al orchestrator planificando, gastando 6.000 tokens en la planificación inicial y despachando tres workers en el primer round. "We can see that the orchestrator is deciding how to split up the work right now."
💡 Idea clave: el dashboard como herramienta de mejora
Cole señala que la observabilidad no sirve solo para monitorear, sino también para mejorar. Al analizar los logs en la base de datos, tú (o incluso tu coding agent) puedes identificar patrones de ineficiencia y ajustar el harness. El dashboard se convierte en una herramienta de aprendizaje continuo sobre el propio sistema.
💰 Seguimiento de costos por run
Uno de los recursos más prácticos del dashboard es el seguimiento de costos integrado. Cole construyó esto porque se dio cuenta de que, sin visibilidad de los costos, es imposible saber si el loop es eficiente o está quemando dinero.
"En una sola ejecución, gasté más de un millón de tokens solo para crear una aplicación relativamente sencilla. Y sí, estoy seguro de que podría optimizar muchas cosas. Pero creo que con solo mirar esto se entiende por qué sería tan caro."
📈 Lo que revela el seguimiento de costos
Costo del orchestrator frente a los workers
El orchestrator gasta tokens razonando sobre el estado y haciendo planes. Los workers gastan tokens ejecutando. Ver el desglose muestra dónde optimizar.
Costo por ronda
Si el costo por ronda está aumentando, puede indicar context bloat o un orchestrator ineficiente. Si se mantiene estable, el sistema está saludable.
Costo total de la ejecución
La pregunta final: ¿el valor que entrega el loop justifica el costo? Si un tablero Kanban costó 1M tokens, conviene replantear el enfoque.
⚠️ El número que asusta
1 millón de tokens para una app relativamente simple. Y Cole usa Kimi (el modelo más barato), no Opus. Sin seguimiento de costos, este tipo de gasto pasa desapercibido. El dashboard convierte un número invisible en algo sobre lo que se puede actuar.
✋ Intervención humana: pausa + aprobación
Cole considera el human-in-the-loop la el guardrail más importante para la ingeniería de loops. El dashboard permite pausar el loop después de cualquier round y exigir aprobación humana antes de continuar. Esto resuelve el problema clásico de los loops descontrolados.
"Incluso podemos incluir a una persona en el loop para revisar lo que pasó en la primera ronda antes de que el orquestador pase a la siguiente. Ese es el tipo de confiabilidad que creo que realmente necesitamos ahora."
Cómo funciona en la práctica
Pausa entre rondas
El loop completa un round, guarda el estado en la base de datos y se detiene. La persona recibe una notificación (o lo ve en el dashboard) y decide: aprobar y continuar, o intervenir y hacer ajustes.
Aprobar con identidad
El botón "approve and resume" del dashboard verifica la identidad del usuario mediante Retool. Solo quien tiene permiso puede aprobar la continuación del loop. Esto es esencial para el trabajo en equipo.
Verificación del estado mediante el orquestador
Mientras se ejecutan los workflows, puedes preguntarle al orchestrator cuál es el estado. "Incluso puedes pedir una actualización del estado mientras se ejecutan los workflows de Archon."
🎯 Punto de reflexión
El problema con muchos setups de loop engineering es que la gente "configura estos sistemas para que sigan y sigan y sigan. Y luego los dejas funcionando durante un día. Cuando vuelven, solo tienes basura". HITL no es una sobrecarga: es la diferencia entre un loop útil y uno destructivo.
❓ Preguntas y deploy con Retool
Cole demuestra cómo el dashboard local puede ser deployado en la cloud mediante Retool, convirtiendo una herramienta personal en infraestructura para el equipo. El proceso es simple: importar React, conectarse a Neon y tener una URL accesible desde cualquier lugar.
"También podemos implementar este tipo de dashboard en la nube. Así podemos acceder desde cualquier lugar e incluso empezar a compartir la configuración de nuestro loop con el equipo."
Deploy en 3 pasos
Importa el archivo zip del frontend React a Retool. El agente de Retool conecta todo automáticamente.
Conectarte a la base de datos Neon creando un recurso Postgres en Retool con las credenciales de conexión.
Configurar grupos de permisos para controlar quién puede aprobar/rechazar rondas del loop.
¿Es necesario que exista el dashboard?
Sí, si planeas usar loops en serio. Sin visibilidad, estás operando a ciegas. Cole fue directo: construyó el dashboard porque lo necesitaba, no como ejercicio académico. La observabilidad es un requisito, no algo simplemente deseable.
No tiene que ser sofisticado
El objetivo no es construir un dashboard empresarial. Es tener la visibilidad mínima: qué rondas se ejecutaron, cuánto costaron y dónde se equivocó el orchestrator. Incluso un script que consulta la base de datos y genera un informe es mejor que nada.
El futuro: dashboards como "second brain"
Cole menciona que está integrando dashboards como parte de su "second brain" para gestionar tareas autónomas. La idea es que el dashboard no es solo para loops de código, sino para cualquier sistema en el que los agentes trabajen de forma autónoma y necesiten supervisión.
📋 Resumen del módulo
Módulo siguiente:
3.4 - Optimización de costos: combinación de proveedores, enrutamiento de modelos, estado externo y métricas para mantener viables los ciclos