Que hace
El agente de IA está de guardia junto con el ingeniero on-call: lee las alertas de Slack y del observability stack, recopila el contexto de diagnóstico y prepara un pull request con la corrección. No reemplaza al ingeniero de guardia, sino que reacciona primero ante el incidente — para que en el momento de la escalación el contexto ya esté recopilado y, en los casos conocidos, ya se haya propuesto un fix. En modo productivo, esto libera al equipo de 675 horas al mes y cierra 28 PR sin intervención humana.
Qué hace el agente
- Escucha el canal de guardia y los webhooks de monitoreo — captura una nueva alerta en segundos, no después de que el ingeniero abra la notificación.
- Extrae el stack trace, las métricas, los enlaces a los dashboards relacionados y los últimos despliegues para obtener el panorama completo.
- Busca incidentes similares en el historial de hilos de Slack y en los runbooks — extrae el conocimiento que normalmente permanece en la mente de los ingenieros experimentados.
- Formula una hipótesis sobre la causa del incidente y la publica en el hilo como primer mensaje, indicando el nivel de confidence.
- Si el incidente corresponde a un patrón conocido — abre un pull request con la corrección y asigna revisores.
- Adjunta al PR las evidencias: logs, trace, enlaces a casos similares, diff con las correcciones anteriores.
- Permanece en el hilo y responde a las consultas del ingeniero de guardia hasta que el incidente se cierre — una única fuente de verdad en lugar de la copia manual del contexto.
- Tras la resolución, redacta un borrador breve de postmortem y registra el nuevo patrón para futuros incidentes — la base de conocimiento se actualiza automáticamente.
El ingeniero de guardia cambia de contexto con menos frecuencia: en lugar de la cadena «alerta → métricas → código → Slack → repositorio», lee un resumen preparado y toma la decisión. Según los datos de la implementación de referencia, el 66% de las propuestas del agente reciben positive feedback, y el costo de una interacción es de $0,30.
Qué NO hace el agente
- No fusiona el pull request sin aprobación de un humano — todos los cambios pasan por el code review estándar y el CI.
- No resuelve incidentes para los que no existe un runbook documentado o un caso anterior similar — escala al ingeniero de guardia con el contexto ya recopilado.
- No toma decisiones arquitectónicas, no refactoriza componentes ni toca el código fuera de los servicios permitidos — solo correcciones puntuales según patrones conocidos.
Como funciona
El agente está construido sobre el patrón de orquestación multietapa: el LLM gestiona el ciclo «observación → hipótesis → acción → verificación» hasta encontrar una solución o decidir escalar. El núcleo es un modelo de lenguaje con tool use a través de un agent framework.
Arquitectura
El agente opera en tres capas de integración, cada una con sus propios tool calls:
Capa | Qué da al agente | Ejemplos de operaciones |
|---|---|---|
Observability / monitoring | Señal y métricas | Lectura de alertas, pull de métricas por instance/service, exportación de stack traces |
Code repository | Código e historial de cambios | Búsqueda de archivo por error, revisión de los últimos commits, creación de branch y PR |
Communications | Contexto del equipo | Lectura de hilos de Slack sobre el incidente, registro de respuesta, mención del responsable de guardia |
Flujo de gestión del incidente
- Triggering event. La alerta del sistema de observability llega al canal de Slack de los responsables de guardia. El webhook transmite el evento al agente con payload: severity, servicio, métrica.
- Context gathering. El agente realiza una serie de tool calls: lee las últimas líneas de logs, el gráfico de métricas de las últimas 24 horas, el deploy history de las últimas 6 horas.
- Pattern search. El agente, mediante búsqueda vectorial en el historial de incidentes de Slack y los runbooks, encuentra casos similares con sus resoluciones.
- Hypothesis. El LLM formula una hipótesis del tipo «latencia elevada en el service X causada por el release Y — rollback o hotfix Z» con una estimación de confianza.
- Diagnosis post. El agente publica el primer mensaje en el hilo: summary, hipótesis, enlaces a las evidencias. El responsable de guardia ve un resumen, no logs en bruto.
- Remediation path. Si el patrón es conocido y el confidence es alto, el agente crea una rama, aplica el fix según la plantilla, abre un PR con descripción y asigna revisores. Si no, se detiene y pide al responsable de guardia que confirme la dirección.
- Human-in-the-loop. El responsable de guardia revisa el PR, lo acepta o solicita cambios. El agente responde a los comentarios: añade logs, corrige el fix, explica la elección.
- Post-mortem draft. Tras el incidente, el agente recopila el timeline —qué ocurrió, qué se hizo, cuánto tiempo tomó— y deposita el borrador en el canal para su edición.
Cómo se despliega en el proyecto
- Conexión de observability: webhook desde Datadog, Grafana, New Relic, Sentry o Prometheus Alertmanager al servicio del agente.
- Integración con el repository: GitHub App o GitLab access token con permisos de create branch, open PR, read commit history.
- Instalación del bot de Slack en el canal de los responsables de guardia: lectura de eventos, registro de respuestas, threading.
- Importación de incidentes históricos: parsing de hilos de Slack y runbooks existentes en un índice vectorial, el núcleo de conocimiento del agente.
- Definición de patrones de auto-remediation: lista de tipos de incidentes en los que el agente tiene permiso para abrir PR (rollback deploy, cambio de feature flag, bump de límites).
- Guardrails: lista de servicios y repositorios donde el agente solo lee, y una lista separada donde puede escribir.
- Piloto: una semana en modo «el agente solo escribe diagnóstico, sin PR». El equipo evalúa la calidad de las hipótesis.
- Ampliación: tras un positive feedback estable, los patrones de auto-remediation se activan de uno en uno.
Dónde reside el valor
El agente convierte tres pares de manos en un único primer respondedor que siempre está en línea. Según los datos de la implementación de referencia, 28 PR al mes se fusionan sin intervención humana: son fixes de bajo riesgo que antes consumían el tiempo de los ingenieros senior y los apartaban de sus tareas en curso.
Requisitos previos
Para lanzar el On-call AI agent, el equipo necesita tres grupos de preparación: accesos, datos históricos y proceso operativo. Sin ellos, el piloto se dedica a depurar integraciones en lugar de trabajar realmente con incidentes.
Accesos e integraciones
- Stack de Observability con webhooks: Datadog, Grafana, New Relic, Sentry o Prometheus Alertmanager.
- Repositorio Git con CI configurado y code review (GitHub, GitLab, Bitbucket).
- Slack o similar con un canal de guardia y permiso de instalación del bot.
- Acuerdo técnico: read-only para la mayoría de los repositorios, write (create branch + open PR) para la lista de permitidos.
Datos históricos
- Hilos de Slack sobre incidentes de los últimos 6–12 meses — cuantos más haya, más preciso funciona el pattern-matching.
- Runbooks en cualquier formato (Confluence, Notion, markdown en el repositorio).
- Lista de patrones auto-remediation conocidos: qué tipos de incidentes el equipo está dispuesto a delegar al agente (rollback, feature-flag toggle, bump de límites).
Preparación del equipo
- El On-call rotation ya está establecido: hay un guardia de turno y un proceso de escalación.
- El code review es obligatorio para todos los PR — el agente no hace merge por sí solo.
- Se designa un propietario: senior SRE o tech lead, que valida los patrones y analiza los falsos positivos durante las primeras semanas.
Plazos de implementación
Complejidad — media. Lanzamiento completo desde el contrato hasta producción — 6–10 semanas:
- Semanas 1–2: integraciones, accesos, indexación del historial de incidentes.
- Semanas 3–5: piloto en modo diagnóstico, configuración de patrones.
- Semanas 6–8: activación de auto-remediation por un patrón, calibración.
- Semanas 9–10: entrega al equipo y playbook del propietario.
Problemas
- Conocimiento en cabezas, no en documentos
- Cambio constante de contexto
- Respuesta lenta a clientes
FAQ
¿Cuánto tiempo lleva la implementación?
El lanzamiento completo lleva 6–10 semanas. Las primeras 2 semanas se destinan a las integraciones con observability, el repositorio y Slack. Las siguientes 3–4 semanas corresponden al piloto en modo «solo diagnóstico», donde el equipo calibra la calidad de las hipótesis. Las últimas 2–4 semanas incluyen la activación de auto-remediation por un patrón y la entrega al propietario. La parte de diagnóstico puede iniciarse más rápido si los incidentes están bien documentados en los hilos de Slack.
No tenemos runbooks actualizados — ¿funcionará el agente?
Parcialmente. El agente compensa la ausencia de runbooks con el historial de hilos de Slack: si el equipo debate los incidentes en los canales, esos datos son suficientes para el pattern-matching. En las primeras semanas, el agente escala con mayor frecuencia en lugar de auto-remediation, pero al mismo tiempo enriquece la base de conocimiento. Tras 1–2 meses de operación, se genera un índice estructurado de incidentes: la correspondencia se convierte automáticamente en un equivalente de runbook.
¿Cuáles son los riesgos y qué puede salir mal?
El principal riesgo son las hipótesis incorrectas que llevan al ingeniero de guardia en una dirección equivocada. Por eso el agente muestra el nivel de confidence y las evidencias, y auto-remediation se activa solo para patrones con historial de éxito. El segundo riesgo es un PR con un fix incorrecto, pero el code review y el CI detienen dichos cambios. El agente no hace merge por sí solo y no toca código fuera de los servicios autorizados.
¿Es adecuada la automatización para nuestro sector?
El perfil principal es SaaS y Tech, donde existe un stack de observability y on-call rotation. También es adecuado para e-commerce, fintech, gaming: en cualquier entorno donde production requiere turno de guardia. No es adecuado para equipos sin monitoreo o sin proceso de code review. La especificidad sectorial se incorpora en los patrones de auto-remediation: para fintech son importantes las verificaciones de compliance, para gaming, la velocidad de rollback.
¿El agente reemplazará al ingeniero de guardia?
No. El agente es el primer respondedor, no un sustituto. Recopila contexto, propone una hipótesis y en casos simples abre un PR, pero las decisiones recaen en el ser humano. La implementación de referencia muestra un 66% de positive feedback y 28 PR al mes sin human intervention: se trata de fixes de bajo riesgo que antes consumían el tiempo de los ingenieros senior. Los incidentes complejos los escala el agente con el contexto ya recopilado.
¿Es posible iniciar solo la parte de diagnóstico sin auto-remediation?
Sí, es el inicio habitual. En modo diagnóstico, el agente redacta un resumen, una hipótesis y los enlaces a las evidencias, pero no abre un PR. De este modo se elimina el principal problema: el context-switching y la búsqueda de incidentes similares, sin riesgo de intervención en el código. Auto-remediation se activa en una etapa separada, tras 1–2 meses de piloto, cuando el equipo observa una calidad estable de las hipótesis.
¿Sobre qué modelo funciona el agente?
El núcleo es un LLM con tool use a través de un agent framework. El modelo gestiona el ciclo «observación → hipótesis → acción» y realiza llamadas a observability, al repositorio y a Slack. La elección se debe a la calidad del code-reasoning y a la estabilidad de los contextos largos: el stack trace, los logs y el diff caben en una sola ventana. Grow2.ai se encarga del prompt engineering, los patrones de herramientas y el monitoreo del comportamiento del agente.
Quieres esto en tu negocio?
Reserva una auditoria gratuita — te mostraremos como funcionara esta automatizacion para ti.