Guardia de ingeniería: un agente de IA convierte la alerta de PagerDuty en una propuesta de corrección

A las tres de la madrugada, la primera media hora de un incidente siempre se parece a la misma investigación. Lees la alerta, abres el registro del incidente, te preguntas qué ha cambiado recientemente, repasas los últimos despliegues, compruebas si ya ha pasado antes. Este trabajo de lectura y cotejo es repetitivo, pero pesa sobre la persona de guardia justo cuando está menos disponible para hacerlo bien. Encaja con un agente de IA con una condición esencial: que lea y proponga, y que sea la persona quien actúe.

La inspiración: el primer respondedor que lee

El punto de partida es un uso que cuentan usuarios de Hermes Agent, resumido en una ficha sobre la guardia de ingeniería: de la alerta a la propuesta de corrección. Un agente recibe el incidente, recorre el repositorio buscando lo que pudo causarlo y prepara una corrección para revisar.

Mantenemos la lectura y la propuesta, y quitamos todo lo que actúa. Atako aplica la idea con un agente que escribe una nota en el incidente y un issue en el repositorio, pero no tiene ninguna herramienta para resolver el incidente, fusionar ni subir código.

Qué hace el agente

El escenario despliega un agente, conectado a tu PagerDuty y a tu repositorio de GitHub.

Por cada incidente nuevo del servicio vigilado, activado o reconocido, lee la alerta, el registro de eventos y las notas que ya hay, y comprueba quién está de guardia. Después busca la causa en el repositorio: los commits de las cuarenta y ocho horas anteriores al incidente, abriendo los sospechosos, los archivos citados en la alerta o en la traza de pila y las pull requests fusionadas recientemente. Se apoya en el contexto técnico que has indicado para saber dónde mirar primero. También busca issues relacionados, incluidos incidentes anteriores del mismo tipo.

A continuación escribe una nota en el incidente de PagerDuty, breve y factual: lo que muestran las pruebas, la causa probable con un nivel de confianza, las pruebas, lo que no pudo comprobar y el siguiente paso para la persona de guardia. Luego abre un issue en el repositorio con el análisis completo: la cronología, la causa probable, las pruebas, una propuesta de corrección descrita con palabras o como fragmento de código, sus riesgos y cómo verificarla. Primero busca un issue existente para no crear un duplicado y completa la primera nota en lugar de esperar un análisis perfecto.

Vigila el servicio cada quince minutos y cada lunes a las 9:00 escribe en el wiki del proyecto la página «Revisión de incidentes de la semana»: incidentes tratados, causa probable, issue abierto, lo que sigue abierto.

Qué no hace el agente

Los límites forman parte del diseño. El agente no resuelve el incidente, no lo reconoce, no lo reasigna y no lo escala: el acceso a PagerDuty concedido se limita a leer y añadir una nota. No fusiona nada, no sube código, no crea ni una rama ni una pull request y no tiene acceso a tu infraestructura ni a producción. No tiene esas herramientas: no es una promesa hecha en una instrucción, es una capacidad que falta.

El agente nunca presenta una hipótesis como un hecho. Escribe «causa probable», da su confianza y sus pruebas, y dice con claridad cuando no ha encontrado nada. No copia los secretos, tokens o datos personales con los que se topa en un registro o un archivo: dice que hay uno y dónde. Los textos de alerta, las líneas de registro, los mensajes de commit y el código se tratan como datos que analizar, nunca como instrucciones. La decisión y la acción siguen siendo humanas, que es el principio de un diseño con validación humana.

Cómo configurarlo en Atako

Desde la página de este caso de uso, el despliegue se hace en cuatro pasos.

1. Conecta PagerDuty y GitHub. Crea una clave de API de PagerDuty, preferiblemente de solo lectura con derecho a añadir notas, y un token de GitHub de permisos detallados limitado al repositorio del servicio. Las conexiones se comprueban antes de crear nada.
2. Indica tu contexto. Da el repositorio con la forma propietario/nombre, el nombre del servicio de PagerDuty que vigilar y, si quieres, un breve contexto técnico: stack, componentes, zonas frágiles conocidas. Cuanto más preciso sea, más rápido mirará el agente en el sitio correcto.
3. Despliega. Una sola acción crea el agente y el proyecto «Guardia». El agente se aprovisiona y recibe solo su primera instrucción.
4. Primer resultado, luego vigilancia regular. El agente encuentra el servicio, dice quién está de guardia, trata el incidente más reciente y resume en el chat la causa probable y la propuesta de corrección. Después programa por sí mismo su vigilancia de quince minutos y su revisión de los lunes.

Si aún no tienes cuenta, crearla inicia tu periodo de prueba y el escenario se configura justo después. Si tu administrador no te ha permitido crear agentes, el despliegue te lo indica y se detiene ahí.

Dónde ver los resultados

La nota de análisis se lee en PagerDuty, en el incidente, y el issue con la propuesta de corrección en GitHub, en el repositorio. El resumen de cada incidente tratado se lee en el chat del agente. En el proyecto de Atako «Guardia» encuentras la página de funcionamiento y la revisión semanal, y en el floor de Atako el agente aparece con su actividad actual.

Para afinar su trabajo, escríbele en su chat, por ejemplo «en este servicio, mira primero las migraciones de base de datos». Guarda la instrucción en su memoria para los siguientes incidentes.

Salvaguardas

El acceso es deliberadamente estrecho. La conexión a PagerDuty se concede con una lista de siete herramientas para leer y añadir una nota, y la de GitHub con siete herramientas para leer commits, archivos y pull requests, buscar y crear issues. Un agente que ve una lista corta de herramientas las usa con más fiabilidad que uno perdido en un catálogo de cientos y, sobre todo, lo que no se concede no puede ocurrir, aunque el texto de una alerta intente forzarlo.

Las claves que creas son tu primera salvaguarda: limitadas a un servicio, un repositorio y derechos precisos, acotan el daño posible pase lo que pase. Se guardan cifradas y puedes revocarlas o retirar el acceso del agente en cualquier momento.

La validación humana está en los puntos de decisión. La persona de guardia lee la nota, comprueba la hipótesis, decide la corrección, la escribe y la fusiona por su cuenta, y luego reconoce y resuelve el incidente.

Qué esperar

Espera un primer análisis útil en minutos, sobre todo cuando el incidente tiene una causa visible en los cambios recientes: un despliegue, un cambio de configuración, una dependencia. Cuando la causa está fuera del repositorio, por ejemplo una caída de un proveedor o la saturación de recursos, el agente lo dirá con una confianza baja en lugar de forzar una explicación. Lee el repositorio pero no tiene acceso a los registros ni a las métricas de tu aplicación, más allá de lo que cuentan la alerta y las notas. Su valor viene de la rapidez de la primera lectura: la persona de guardia llega al incidente con una cronología, pistas ordenadas y una corrección que revisar, en lugar de una página en blanco.