El 16 de agosto, mi agente de explotación, el que supervisa los servidores y despliega las actualizaciones, se bloqueó seis veces a lo largo del día. Cada vez informaba de lo mismo: sus herramientas ya no respondían, ni siquiera a un comando trivial.
No eran sus herramientas. Nunca llegaba al momento de llamarlas.
Un fallo que se repite de forma idéntica
Un mensaje antiguo de su conversación contenía un bloque dañado, rechazado por la API del modelo. Como cada petición reproducía todo el historial, el fallo era determinista: tres reintentos automáticos, tres rechazos y un turno terminado sin salida visible. Visto desde el teléfono, parecía un bloqueo; técnicamente, era un rechazo reproducible.
Un fallo que se repite de forma idéntica parece inestabilidad cuando solo se ven sus efectos. La diferencia depende de una sola pregunta: ¿falla siempre en el mismo punto?
Una magnitud invisible
- 80 llamadas fallidas en el día, en 20 ejecuciones distintas;
- una cadencia regular, cada treinta minutos;
- un desencadenante interno: un control rutinario del propio agente.
Y ese control rutinario verificaba… rutas de archivos de un servidor antiguo, retirado once días antes durante una migración. El propio archivo de instrucciones llevaba en la primera línea una advertencia: «escrito en el servidor antiguo, volver a verificar antes de usar». Nadie la leyó, porque no aparecía en ningún informe.
Durante once días, cada treinta minutos, el agente verificó concienzudamente una máquina muerta. Y cada verificación se facturaba, porque reproducía toda la conversación: casi 2 MB de contexto en cada disparo.
La corrección, sobre las tres causas
- El trabajo inútil: se retiraron las instrucciones obsoletas.
- El coste: los controles rutinarios se ejecutan ahora en una sesión aislada, sin el historial.
- El daño: la conversación dañada se archivó.
Verificado, no supuesto: tras la corrección, cero errores y cero llamadas inútiles. De ochenta llamadas facturadas a ninguna.
La conclusión equivocada que estuve a punto de sacar
Mi propia documentación atribuía este tipo de daño a los reinicios del agente, y ese día hubo ocho. La cronología lo descartaba: el daño era seis horas anterior al primer reinicio. Una causa plausible, ya escrita, compatible con los hechos del día. Bastó con alinear las marcas de tiempo para descartarla.
Lo que un directivo debe retener
El coste no era la cuestión: unas decenas de euros. La cuestión es que diez horas de silencio y ochenta llamadas facturadas no generaron ninguna alerta. El objetivo «el coste sigue siendo marginal» figuraba en el pliego de requisitos. No se medía en ninguna parte. Mientras un objetivo no está instrumentado, no se cumple: se espera.
Antes de confiar una tarea a un agente, pregunte a su proveedor: ¿cuántas ejecuciones fallaron ayer y cuánto costaron? Si no puede responder en un minuto, el sistema no está en producción. Está en libertad condicional.