Agent Fleet Console

En algún punto dejé de tener “un asistente de IA” y pasé a tener una flota: un asistente conversacional al que le escribo desde el teléfono, un agente de código en la terminal, otro dentro del editor, y un modelo chico corriendo local en la misma máquina. Todos tocando los mismos repos, al mismo tiempo, sin hablarse entre ellos.

Agent Fleet Console es lo que hice para que eso fuera un sistema y no un desmadre: cómo se coordinan, cómo se despacha trabajo solo, y —la parte con más ingeniería adentro— cómo se mide lo que consumen sin contarme mentiras.

Qué hace

Coordina agentes que no pueden hablarse. No hay canal de mensajes entre un agente de Telegram y uno de terminal, así que la coordinación se hace donde sí coinciden: archivos compartidos en disco. Hay un punto de sincronización que cada agente lee al arrancar y escribe al terminar algo relevante, más un contrato de lineamientos de ingeniería que todos cargan —solo las secciones que aplican a su tarea— antes de escribir código. El archivo es la fuente de verdad; ninguno depende de que yo relayee mensajes entre ventanas.

Despacha trabajo solo. Hay tareas programadas por cron que arrancan un worker sin que nadie esté mirando, y que al terminar avisan por Telegram con el resultado y la ruta del log — no un “ya quedó” a ciegas, sino algo verificable. El patrón se repite: una tarea larga se despacha a un worker headless, se revisa su salida contra el repo real, y hasta entonces se da por cerrada.

Mide el consumo de la flota. Aquí vive llm-agent-spend-manager, un CLI en Go que da visibilidad de gasto y cuota entre los agentes que comparten la máquina. Su decisión de diseño más importante es la unidad: como todo corre sobre suscripción de precio fijo, el dólar nunca fue el recurso escaso. Lo que de verdad se acaba —y te deja tirado a media tarea— es la ventana de cuota del proveedor. Así que reporta cuánto queda de la ventana, quién se la está comiendo y qué palanca la estira más, y deja el equivalente en dólares abajo, con su rótulo de que es una equivalencia y no un cobro.

También clasifica la forma de cada carga de trabajo, porque dos sesiones que costaron lo mismo no son el mismo problema: una conversación larga que arrastró contexto miles de turnos se abarata cortándola; una ráfaga mecánica se abarata ruteándola a un agente más barato. Palancas distintas para números idénticos.

Bajo el capó

La regla dura del proyecto es una sola y lo ordena todo: no se inventa ningún número. Todo lo que el reporte afirma se deriva de datos medidos, y lo que no se puede derivar se dice —n/a, falta el dato, sin clasificar, con su motivo— en vez de rellenarse con un estimado que se leería igual que una medición. No hay modelo entrenado ni estado guardado entre corridas: mismos datos de entrada, mismo reporte.

Eso suena bonito hasta que cuesta cifras. Dos veces mordió de verdad, y son mis ejemplos favoritos de todo el proyecto:

• Una extrapolación de 45× que el propio sistema atrapó. La primera corrida del plan de ahorro por ruta decía que mover 44,373 turnos a un modelo más barato habría ahorrado $6,673 — habiendo observado a ese modelo cargar apenas 981 turnos de esa forma. Es aritmética disfrazada de evidencia. Con el tope de “solo puedes reclamar lo que la opción barata ya demostró cargar”, la cifra bajó a $147.21 sobre esos 981 turnos observados, y el reporte dice en voz alta que topó y por qué. Un resultado más chico y verdadero le gana a uno grande y sugerente.
• Una caída de 38.7% que se negó a reclamar como mejora. El costo por turno pasó de $0.1635 a $0.1002 y aun así el veredicto impreso es “sin cambio de nivel”: medido contra la dispersión diaria de la propia serie, ese escalón es −0.9σ, o sea que cabe en el ruido. Un reporte que titulara “bajamos 38.7%” estaría vendiendo varianza como resultado.

De la misma regla salen las demás decisiones: una jerarquía de confianza explícita entre agentes (los que exponen tokens reales se reportan como cifra única; los que solo dejan inferir actividad se reportan como rango, marcados y un escalón abajo, y nunca se cuelan a competir contra una cifra medida); un aviso obligatorio de que coincidencia temporal no es causalidad en cada atribución; y una lista explícita de lo que el sistema no puede saber — como cuánto pesa cada modelo contra la cuota, que el proveedor no publica y que aquí se imprime como “no derivable” con el motivo, en vez de un factor inventado con cara de hallazgo.

El techo de la ventana de cuota tampoco lo publica nadie, así que es un estimado calibrado contra agotamientos observados en la máquina, y se reporta como rango con su dispersión — por debajo de tres observaciones, el comando simplemente no imprime techo.

El stack

• Go — un solo binario, sin dependencias de npm ni servicios de terceros obligatorios. Comandos status, quota, advise y outcome, todos con --json para que otro agente los consuma.
• Dashboard web propio servido por el mismo binario: por defecto solo en localhost; para exponerlo a la red local hay que pedirlo explícitamente y entonces exige un token aleatorio de 128 bits en todas las rutas. Instalable como PWA desde el celular.
• Análisis determinista: parseo de transcripts JSONL, atribución de costo por bucket facturable, curva de contexto por sesión y detección de cambio de nivel tipo CUSUM sobre las series diarias. Sin ML.
• Orquestación: agentes sobre OpenClaw (Telegram) y CLIs de agente en terminal y editor, coordinados por archivos y despachados por cron.
• Cada método —cuota, clases de carga, bitácora de resultado— documentado en su propio archivo, para que las cifras se puedan rehacer con una calculadora.

Vale la pena mencionar

Este es el proyecto paraguas de los otros tres de esta lista, y no por casualidad: llm-budget-cap y chatarmor topan el gasto de un producto de cara al usuario, itza-rag mantiene barato y privado lo que se puede resolver en local, y esto mide y ordena a la flota que los construyó.

Si tuviera que quedarme con una sola idea de todo el trabajo con agentes, sería esta: lo difícil no es hacer que un modelo produzca un número, es hacer que se calle cuando no lo tiene. Un panel que siempre trae una cifra bonita es un panel en el que no puedes basar una decisión. Por eso las partes de las que estoy más orgulloso aquí son las que imprimen “no derivable”, “falta el dato” o “sin cambio de nivel” — cada una es un lugar donde el sistema pudo haberme dado la razón y prefirió no hacerlo.