Qué llamo runner
Llamo runner a una máquina, un proceso o un servicio preparado para ejecutar tareas acotadas cuando un agente se lo pide. Puede correr pruebas, revisar un proyecto, abrir archivos, levantar un servidor, comprobar una respuesta HTTP o generar un archivo. La diferencia con un chat es que aquí la instrucción termina en una acción, y esa acción tiene límites que puse yo.
Por qué lo necesito
Muchas tareas no se resuelven con texto. Hay que abrir sistemas, cruzar datos, comprobar que algo funciona y dejar registro de lo que se hizo. Sin un runner, el agente solo puede decirme qué haría. Con un runner, lo hace, y yo puedo ver exactamente qué pasó.
Alguien pide «revisa por qué falló el reporte de ventas». El orquestador manda un runner a leer los logs, otro a abrir el archivo generado y otro a comparar los datos, y me devuelve un resumen con la evidencia de cada paso. Yo decido qué hacer con eso.
El runner no depende del modelo
El runner no depende del modelo que razona arriba. Su contrato es simple: recibe una instrucción acotada, la ejecuta dentro de los permisos pactados y devuelve evidencia. Ese contrato no cambia cuando cambio de modelo.
En mi sistema, el mismo runner que hoy ejecuta tareas dirigidas por un modelo, ayer las ejecutaba con otro, sin tocar su configuración. Los modelos se renuevan cada pocos meses. Los permisos, los logs y la forma de auditar no tienen por qué renovarse con ellos.
La inversión en la capa de ejecución no queda atada a un proveedor. Puedo cambiar de modelo cuando uno mejore o suba de precio, o probar dos contra la misma tarea y comparar. Y la gobernanza (quién aprueba, qué se registra, hasta dónde llega cada agente) sigue igual.
Tareas que hoy le delego
- Leer archivos, buscar referencias y resumir hallazgos.
- Correr pruebas, linters, builds o scripts internos.
- Levantar servicios locales para validar una pantalla.
- Generar reportes, CSV, documentos o assets.
- Consultar endpoints internos con permisos controlados.
- Registrar logs de cada acción para auditoría.
Dónde entra el orquestador
Sobre los runners va un orquestador; el mío sigue en desarrollo. Decide qué runner necesita cada paso, reparte el trabajo, espera resultados, pide aprobación cuando hay riesgo y arma la respuesta final. En vez de un solo agente para todo, hay unidades pequeñas que se auditan por separado.
Los controles que pongo antes de soltarlo
- Permisos por rol: un runner de lectura no debe poder modificar producción.
- Ambientes separados: pruebas, staging y producción no deben mezclarse.
- Confirmaciones humanas: cualquier acción sensible debe pedir aprobación.
- Logs completos: comando, entrada, salida, usuario, hora y resultado.
- Rollback: si algo falla, debe existir camino de reversa.
En pocas palabras
Un runner convierte una conversación en trabajo que se puede revisar. El razonamiento puede venir de cualquier modelo, hoy uno y mañana otro. La ejecución la hace el runner, dentro de límites definidos de antemano.