Nitric revoluciona la gestión de incidentes con agentes de IA especializados y colaboración compartida

Un equipo de ingenieros de Nitric ha reducido drásticamente las interrupciones nocturnas y mejorado la resolución de fallos utilizando agentes de IA especializados que trabajan de forma colaborativa en un espacio compartido, favoreciendo así un proceso más eficiente y confiable en la detección y solución de problemas en producción.

En un equipo formado por cinco ingenieros, la rutina solía incluir despertarse tres o cuatro veces por semana debido a incidentes en producción. La mayoría de estas alertas resultaban ser ruido sin importancia, pero a altas horas de la noche la prudencia era prioritaria para evitar pasar por alto fallos reales.

Para reducir estas interrupciones innecesarias y solucionar los problemas recurrentes, el equipo ha implementado un proceso basado en agentes de inteligencia artificial especializados. Estos agentes colaboran investigando los incidentes, organizando las tareas posteriores y preparando correcciones, mientras los ingenieros revisan y ajustan su trabajo durante todo el flujo.

Lo más sorprendente para ellos fue la creciente confianza que depositaron en este proceso. Los ingenieros podían examinar las evaluaciones realizadas por los agentes, cuestionar sus suposiciones y utilizar estas correcciones para optimizar la gestión de futuros incidentes. Al abordar eficazmente los problemas recurrentes, pudieron decidir con mayor seguridad cuándo era realmente necesario alertar al ingeniero de turno.

Patrocinado

Esto les llevó a reconsiderar la distribución de responsabilidades entre los agentes de IA. En lugar de depender de un único agente que abordara todas las tareas, optaron por especializar agentes para cada función concreta del proceso, facilitando así la mejora continua y la evaluación específica del desempeño en cada etapa.

Un espacio compartido para ingenieros y agentes

Para implementar esta metodología, desarrollaron Sugabots, una plataforma de código abierto autohospedada que permite a un equipo trabajar simultáneamente con varios agentes en un mismo caso. Los ingenieros pueden formular preguntas, aportar evidencias, revisar conclusiones y sumar nuevos agentes, con todas las interacciones disponibles para todos los participantes.

El trabajo se organiza en entornos compartidos denominados «pods», que se conectan a sistemas externos mediante el Protocolo de Contexto del Modelo (MCP). Cada agente dispone de su propio modelo e instrucciones, mientras que las conexiones y políticas de acceso del pod determinan los permisos compartidos. Esta configuración facilita asignar a cada agente responsabilidades específicas y ajustar sus instrucciones conforme los ingenieros evaluan sus resultados. La experiencia en el manejo de incidentes les ayudó a identificar cuáles responsabilidades se benefician de esta división.

Gestión de triage de incidentes en Sugabots

El flujo de trabajo de incidentes se basa en que tanto los ingenieros como los agentes puedan continuar la investigación desde el historial de evidencias, decisiones y correcciones acumuladas.

Un agente dedicado al triage en Sentry se encarga de analizar nuevos problemas, regresiones o incidencias que escalan, y decide si es necesario alertar al ingeniero de guardia, solicitar una revisión durante horario laboral, entregar una corrección menor a un agente de implementación, o mantener el problema en observación en Sentry. Además, registra el trabajo pendiente en Linear, donde otro agente organiza los tickets, y el agente de implementación puede preparar propuestas de cambios en GitHub para revisión.

Los ingenieros participan activamente revisando las conclusiones, cuestionando la gravedad, corrigiendo errores y decidiendo si se debe aplicar alguna solución. Toda la investigación permanece accesible mientras el trabajo avanza entre personas y agentes.

Se aplican medidas de seguridad para garantizar que los problemas que puedan causar una caída real en producción se escalen urgentemente, mientras las alertas consideradas ruido se archivan hasta que se vuelvan más críticas. Sentry cuenta además con un canal de emergencia directo a incident.io como respaldo.

El seguimiento posterior es tan importante como la evaluación inicial. Antes, el ingeniero podía investigar una alerta y considerar que podía esperar, dejando el problema pendiente. Ahora, registrar el problema en el backlog y priorizarlo permite al equipo abordarlo antes de que otro ingeniero tenga que enfrentarlo de nuevo.

Especialización alrededor de decisiones concretas

Cada agente se configura para asumir una responsabilidad concreta, seleccionando el modelo de IA y las instrucciones adecuadas, definiendo claramente qué resultados son útiles.

Para el triage en Sentry eligieron el modelo Opus 5.5, cuyas instrucciones abarcan la obtención de evidencias, clasificación de incidentes, escalado, asignación y recuperación ante fallos en herramientas. Entre las decisiones que debe tomar están:

  • Urgente: si existe daño activo a clientes que requiere atención inmediata, alerta al ingeniero de guardia.
  • Revisión en horario: defectos que requieren juicio técnico pero pueden esperar, notificando a baja prioridad.
  • Corrección automática: cambios menores no urgentes fuera de áreas sensibles, delegando al agente de implementación para preparar la propuesta.
  • Sin acción: ruido esperado o transitorio que se archiva hasta que escale.

El agente debe justificar sus decisiones con evidencias y explicar cualquier incertidumbre. Las propuestas de implementación deben ser autónomas e incluir hallazgos y enlaces relevantes.

El agente que gestiona el backlog organiza el trabajo de seguimiento, verifica duplicados, identifica ciclos actuales y diferencia tareas claras de aquellas que necesitan intervención directa de un ingeniero para definir alcance o decisiones de diseño. Esto permite reglas por defecto y a la vez mantiene la libertad del equipo para ajustar prioridades y asignaciones, sin afectar a los criterios de urgencia del triage.

La comparación entre triage e implementación resulta clave: el primero decide si merece la pena interrumpir al ingeniero y escalar, el segundo qué cambios solucionan el problema y cómo verificarlo. Ambos procesos tienen distintos riesgos de fallo, desde incidentes urgentes pasados por alto hasta interrupciones innecesarias o soluciones que generan nuevos errores.

Separar estas responsabilidades permite refinar cada parte del flujo sin comprometer las demás, facilitando así la mejora continua. Cada rol tiene preguntas concretas de evaluación, como la precisión del triage en la detección o si el trabajo pendiente está correctamente registrado y respaldado con evidencias sólidas para las implementaciones.

Permisos acordes a cada responsabilidad

La división de roles también ayuda a definir qué acciones debe poder realizar cada agente y cuándo precisa la aprobación de un ingeniero. Por ejemplo, las instrucciones del agente de triage incluyen crear tickets, enviar alertas o archivar problemas, por lo que debe contar con acceso restringido acorde a estas acciones.

En Sugabots, las políticas de acceso (denegado, consulta o permitido) se configuran a nivel de pod para todas sus conexiones, asegurando así reglas consistentes para acciones automáticas, aprobaciones humanas y herramientas deshabilitadas. Cada agente hereda estas políticas y sus instrucciones definen responsabilidades dentro de esos límites.

Cuando existen diferencias significativas en accesos, se utilizan pods diferentes con políticas específicas. Las autoridades para fusiones o despliegues también requieren políticas explícitas y credenciales adecuadas.

Separar contexto de trabajo e investigación compartida

Es importante distinguir tres elementos con vidas útiles diferentes:

  • Configuración: conjunto mantenido de modelo, instrucciones, herramientas y expectativas para cada responsabilidad.
  • Contexto de ejecución: mensajes y resultados disponibles para el agente durante una tarea concreta.
  • Historial compartido: registro acumulativo de evidencias, hipótesis, correcciones y decisiones de personas y agentes.

Durante una investigación, un agente puede descartar que un problema sea una caída y concluir que puede esperar. En ese caso, tras muchas llamadas a herramientas, el contexto puede compactarse para conservar sólo la conclusión relevante, eliminando detalles que confirmen lo descartado.

Sin embargo, para que un ingeniero pueda cuestionar la evaluación, el historial completo debe mantenerse accesible para revisar el razonamiento y evidencias originales. El nuevo agente que retome la investigación recibe entonces un resumen acompañando la información que necesita y recupera datos del historial cuando procede.

Involucrar siempre a las personas

La colaboración humana sigue siendo fundamental cuando el trabajo se pasa entre ingenieros. Estos pueden detectar patrones no percibidos por agentes o anticipar que una solución podría causar regresiones en el código. Es imprescindible que estas contribuciones y correcciones estén disponibles para quien continúe la investigación o prepare la solución.

En chats separados, las responsabilidades de transferir correcciones suelen recaer en las personas. No obstante, aunque todos los agentes puedan consultar repositorios y tickets, cada conversación refleja una versión distinta del aprendizaje colectivo.

Con Sugabots, los ingenieros pueden dejar sus aportaciones directamente en la discusión compartida junto a resultados previos, haciendo que los cambios en la dirección de la investigación sean visibles para todos y accesibles para agentes que continúen el trabajo.

¿Cuándo merece la pena otro especialista?

Cada nuevo agente especializado añade configuración y requiere un cuidadoso traspaso del contexto. Dividir agentes por lenguaje, servicio o entorno de despliegue resulta positivo cuando facilita el mantenimiento y evaluación del flujo.

En Nitric, las especializaciones actuales reflejan responsabilidades ya existentes: el ingeniero de guardia evalúa la urgencia, el equipo organiza el backlog y los ingenieros preparan y revisan las correcciones. Contar con configuraciones distintas para cada función permite mejorar cada fase del proceso independientemente.

Para un equipo interesado en adoptar este enfoque, se recomienda comenzar con una responsabilidad recurrente fácil de describir en términos de resultados útiles y errores reconocibles. Definir criterios de éxito, seleccionar evidencias necesarias, configurar accesos adecuados y determinar cuándo un humano debe revisar las acciones. Mantener el historial para continuar la investigación y analizar correcciones ayuda a identificar oportunidades de mejora y comprobar que no se introducen nuevos fallos.

El planteamiento es definir claramente las responsabilidades de ingeniería de modo que cada investigación, corrección y autorización permita mejorar el manejo de la siguiente.

Prueba Sugabots

Si quieres probar este sistema con tu equipo, Sugabots es una plataforma open source y autohospedada. Empieza con una tarea recurrente y un compañero que revise el trabajo del agente, usando la conversación compartida para pulir su desempeño.

Si el proyecto te resulta útil, puedes apoyar con una estrella en GitHub y compartirlo para llegar a más equipos que puedan beneficiarse y contribuir.

Add a Comment

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Patrocinado