El agente que lee los errores de producción y no puede tocar un archivo

Este es otro post de la serie sobre la flota de agentes que opera mi infraestructura. El bug hunter escribe código. Este es el opuesto: diagnostica incidentes de producción y no tiene permitido cambiar un solo archivo.

El problema que resuelve

Mis monitores vigilan los deploys de dos plataformas de pago y de un producto propio. Cuando los errores se disparan, me llega una alerta al celular. La alerta dice que algo se rompió. No dice si es un bug mío, un proveedor en un mal día o una variable mal configurada, y eso es lo primero que necesito saber para decidir si me levanto.

Contestar esa pregunta era ponerme yo a leer logs y abrir archivos. Ahora esa lectura la hace el agente y la respuesta me llega como un segundo mensaje, un par de minutos después de la alerta.

Qué hace

Cuando un monitor manda una alerta, también deja un trabajo en una cola. Un worker toma un trabajo por vez, junta los logs recientes de ese deploy y corre un agente sobre una copia local del repositorio.

El agente devuelve cuatro cosas: una clasificación (bug nuestro, error externo, configuración o desconocido), una severidad, la causa probable con archivo y línea cuando puede señalarla, y una acción recomendada. Yo lo leo y decido.

Solo lectura es una propiedad de las herramientas

Al agente no le pido por favor que no edite nada. Corre con una lista de herramientas que solo leen, y las que escriben están negadas de forma explícita. No puede editar código, abrir un pull request ni hacer un deploy. Si una línea de log convenciera al modelo de que el arreglo es urgente, no tendría con qué hacerlo.

Acá importa más que en cualquier otra parte de la flota, porque la entrada son logs de producción, y los logs traen texto escrito por quien le esté pegando al endpoint.

Los otros límites son baratos y aburridos. Corre un diagnóstico por vez. Hay un tope diario, así una tormenta de errores no se convierte en una factura. Cada corrida tiene un límite de tiempo. Y el worker posterga el trabajo cuando al servidor le queda poca memoria, porque ese servidor ya se cayó una vez justo por eso.

Los números hasta hoy

Del log del propio worker, desde que arrancó en julio de 2026: 123 corridas, 109 diagnósticos entregados y 14 corridas en las que falló la llamada al agente.

De los últimos 25 diagnósticos que conserva, 11 se clasificaron como configuración, 6 como bug nuestro, 6 como error externo y 2 como desconocido.

El reparto me sorprendió. Armé esto esperando encontrar bugs, y el grupo más grande es configuración. Menos de un cuarto de las alertas apuntaba a código que yo tenía que arreglar.

Lo que no tengo es un número de precisión. Leo cada diagnóstico y la mayoría se sostiene, pero no los puntué uno por uno, así que no le voy a poner un porcentaje.

Por qué todavía no arregla nada

El paso obvio que sigue es dejarlo abrir un pull request con el arreglo. El diseño está listo: su propia copia de trabajo, solo pull requests, nunca un deploy, y la misma regla que el bug hunter para todo lo que mueve plata.

No lo prendí. Un agente que diagnostica mal me cuesta unos minutos. Un agente que arregla mal en una plataforma de pagos cuesta otra cosa. Sigue en solo lectura hasta que haya puntuado diagnósticos suficientes como para confiar en el paso siguiente.

Si estás armando algo parecido, o querés esto corriendo sobre tus propios deploys, escribime. El servicio está descripto en la página de agentes de IA.