Agente READY, uso 0%: cuando el cableado miente

El agente reportaba READY. El panel del proveedor reportaba 0% de uso. Ambas señales venían de la misma corrida.

Si ese día me preguntabas si el pipeline funcionaba, te daba dos respuestas seguras según qué pantalla estuviera viendo. El incidente me obligó a hacer una distinción que hoy trato como innegociable cuando orquesto modelos: cableado, despacho e inferencia sustantiva son tres afirmaciones distintas, y solo una de ellas es un resultado.

Qué estaba construyendo

En ese momento tenía un pipeline de delegación para trabajo de implementación: un planificador raíz que entregaba tareas acotadas a subagentes, cada uno con un tipo de agente personalizado, un modelo fijado por rol y un brief autocontenido — objetivo, no-objetivos, archivos objetivo, criterios de verificación. Un proveedor experimental estaba cableado para experimentos de implementación, y el ejecutor validaba cada diff devuelto contra una lista exacta de archivos permitidos, ejecutando git apply --check antes de que nada tocara el espacio de trabajo.

Sobre el papel, la configuración tenía todo lo que un pipeline serio de delegación necesita. Lo que no tenía todavía era respuesta a una pregunta más simple: ¿cómo sé que la inferencia ocurrió?

Qué se rompía

Durante una corrida, el agente reportó READY mientras el medidor de uso del proveedor se quedaba en 0%. Nada se había caído. No se lanzó ningún error. Por todas las señales que el sistema producía, el ida y vuelta se veía exitoso.

READY es una señal real, pero angosta. Dice que la inicialización completó y que el despacho básico ocurrió. No dice que se facturara un token ni que se consultara un solo peso del modelo. El riesgo que dejé asentado después del incidente lo dice sin rodeos: confundir cableado, despacho e inferencia sustantiva permite que una llamada de red exitosa esconda que ninguna inferencia corrió.

El mismo experimento destapó un segundo modo de falla, un nivel más profundo. Una sesión reportó que agentes genéricos heredaron el modelo del planificador raíz, y el medidor de uso semanal siguió bajando mientras el trabajo destinado al proveedor experimental corría sobre el modelo equivocado. Mandar otro mensaje a un agente ya creado no migra su modelo — debo aclarar que este segundo incidente es reportado por el usuario, sin bitácoras preservadas, así que lo trato como un reporte, no como una traza. Pero la forma de la falla es la misma: una señal de una capa, sosteniendo la prueba de otra.

Diagnóstico

La corrección empezó por nombrar las capas y qué prueba produce cada una:

• Configuración estática. El ejecutor declara el modelo y el endpoint y exige la clave de API. Eso prueba el cableado — nada más.
• Despacho. El ejecutor recibió el brief con una lista exacta de archivos permitidos, o la llamada nativa usó un tipo de agente explícito. Eso prueba que la tarea llegó al rol correcto.
• Inferencia. El proveedor devolvió usage y una salida verificable — un diff que valida contra la lista permitida. Eso prueba que hubo trabajo.

Medido contra esos niveles, una respuesta READY cubre el nivel uno y parte del nivel dos. No demuestra tokens consumidos ni facturación. Y la falla corta en ambos sentidos: si falta la clave de API, el despacho no está probado, y el protocolo documentado es reportar el error exacto y no inventar una confirmación del proveedor en ningún sentido. Ni verde inventado cuando faltan señales, ni rojo inventado cuando están en verde.

La corrección

La corrección fue una llamada verificable. El medidor de uso pasó de 0% a 1%.

Uno por ciento es el número menos impresionante que he visto con gusto. También es el único número de ese pipeline que no puede existir si la inferencia no corrió. Desde entonces, la verificación por nivel se volvió la regla: smoke tests con marcadores fechados por nivel, evidencia registrada por nivel — la verificación documentada de ese pipeline usó marcadores explícitos para que cableado, despacho e inferencia tuvieran cada uno su prueba fechada.

La regla que dejó el incidente, casi textual del expediente: separar cableado, despacho e inferencia sustantiva. Un estatus en verde no es un resultado hasta que cada capa se observa de forma independiente.

La regla general

No necesitas mi pipeline para usar esto. Si orquestas modelos — agentes, evaluadores, cadenas multi-paso — la regla se traduce en tres preguntas por capa:

• ¿Qué prueba la señal en verde de esta capa?
• ¿Qué la refutaría?
• ¿Qué número se mueve si hay trabajo real?

Luego, observar las capas de forma independiente, al menos una vez, por cada cambio de configuración. Una configuración queda probada al nivel que observaste, y no más arriba.

Dos cautelas salen derechito del expediente. Primera: una respuesta observada no prueba que el modelo produzca salida útil — la llamada que movió el medidor a 1% probó que la inferencia corrió, no que el resultado fuera bueno; para eso están la revisión de diffs y las auditorías. Segunda: la evidencia se fecha por nivel: una prueba de una versión anterior del entorno de ejecución no se transfiere automáticamente cuando ese entorno se actualiza. Vuelve a correr las verificaciones baratas antes de volver a confiar en las caras.

Cuándo no aplica esta regla

Honestidad sobre el alcance, porque este patrón puede pudrirse en ceremonia:

• Si llamas a un solo proveedor directo con una petición síncrona y de verdad lees el cuerpo de la respuesta, no necesitas una bitácora de despacho. La separación en tres capas vale su costo cuando la capa que reporta éxito no es la capa que hace el trabajo.
• La separación de capas no sustituye la verificación. Te dice que la inferencia corrió; solo leer la salida te dice si valió la pena.
• Y no es excusa para desconfiar de las señales baratas. READY sí es útil — como disparador de la verificación del siguiente nivel, no como sustituto de esa verificación.

Epílogo

El experimento del que salió este incidente terminó: el plan del proveedor se canceló, el proveedor se eliminó de la configuración, y los documentos de despacho se conservan como referencia histórica. Lo que sobrevivió a la cancelación es el hábito.

El pipeline en el que ahora confío es aburrido en esto. Cada delegación tiene nombre, brief, lista permitida, condición de paro y puntero a evidencia — y ninguna de esas cosas es una luz verde.

Este incidente está documentado, con su corrección y su regla aprendida, en el expediente de Sistemas de agentes, junto a seis incidentes que moldearon ese flujo. Su pareja natural es la regla de seguimiento para cuando la salida llega pero llega rota: detén la unidad al primer error de esquema.