Anthropic publicó el 18 de agosto de 2026 una experiencia sobre el uso de Claude como primer respondedor en incidentes de CI/CD. La empresa anuncia informes iniciales generalmente producidos en menos de quince minutos. Más allá de las cifras, el caso es interesante porque describe una arquitectura reproducible: acceso de solo lectura, herramientas controladas, memoria versionada y validación humana antes de cualquier modificación.
1. Lo que afirma la retroalimentación
Anthropic describe un agente llamado Claude Tag utilizado como primer respondedor para incidentes relacionados con la integración y el despliegue continuos. Según los datos internos publicados, el agente produjo el primer informe de situación en cada incidente reciente que lo tenía, generalmente en quince minutos. La mediana anunciada para un análisis basado en evidencia es de catorce minutos y, en los casos más rápidos, se identificó una causa raíz en cuatro minutos.
Estos resultados provienen del entorno de Anthropic y no constituyen un punto de referencia independiente. Sin embargo, muestran que parte del trabajo inicial de vigilancia puede estructurarse: recopilar las señales, formular hipótesis, citar los elementos observados y preparar una transmisión.
2. El buen papel para un agente de guardia
El primer objetivo no es reemplazar al ingeniero de guardia. Es reducir el tiempo perdido en abrir varias herramientas, cruzar horarios y reconstruir el contexto de un cambio.
Un agente bien diseñado puede recuperar las alertas, despliegues recientes, errores, rastros y discusiones asociadas. Luego puede proponer una cronología, los servicios afectados, las hipótesis y las próximas verificaciones. El humano conserva la decisión, especialmente cuando una acción puede agravar el incidente.
Esta distribución es coherente con el principio de validación humana de los sistemas de IA : automatizar la recopilación y la síntesis, pero mantener una responsabilidad clara sobre los actos de alto impacto.
3. Una arquitectura en dos tiempos
El modelo descrito separa el desencadenamiento determinista de la investigación agénica. Las alertas y reglas clásicas detectan un estado conocido: fallo de pipeline, tasa de error, retraso o saturación. Luego lanzan al agente con un perímetro y un identificador de incidente.
Un orquestador puede delegar varias tareas a subagentes: analizar las métricas, examinar los cambios de Git, leer los eventos de Kubernetes o encontrar incidentes similares. Cada resultado debe conservar las referencias que permitan al ingeniero verificarlo.
Esta separación es esencial. El sistema de monitoreo sigue siendo responsable de la detección y de los umbrales. El modelo interviene en la investigación, la interpretación y la comunicación, donde las reglas rígidas alcanzan sus límites.
4. Por qué empezar en solo lectura
Anthropic proporciona un kit de inicio que crea un rol inicial de solo lectura. Es el enfoque adecuado para un primer despliegue. Un agente capaz de consultar las métricas y registros ya aporta valor sin poder detener un servicio o modificar una configuración.
El kit público se presenta sin auto-remediación: los humanos deciden las acciones y las implementan. El sistema interno descrito por Anthropic también incluye un agente distinto capaz de manejar implementaciones progresivas detrás de banderas de características; esta capacidad no debe confundirse con el alcance inicial del kit.
Los derechos deben asignarse por herramienta y por entorno. Leer los eventos de un clúster de prueba no justifica el acceso a los secretos de producción. Consultar una solicitud de extracción no requiere el derecho a fusionarla.
Cada solicitud debe registrarse con la identidad del agente, el incidente, la herramienta, el alcance y el resultado. Los identificadores temporales y los tokens de corta duración limitan el impacto de una filtración.
5. El acceso a las herramientas a través de MCP
El retorno de experiencia menciona el acceso a Datadog o Grafana, PagerDuty, GitHub, Kubernetes y Slack a través de MCP. El protocolo facilita una interfaz común, pero en sí mismo no constituye un control de seguridad.
Cada servidor MCP debe exponer un subconjunto explícito de acciones, validar los parámetros y aplicar los derechos del lado del servicio. Se debe evitar el uso de herramientas genéricas del tipo “ejecutar un comando arbitrario” o “hacer una consulta libre” cuando una función más específica sea suficiente.
Las respuestas de las herramientas deben considerarse como datos no fiables. Un mensaje de Slack o un nombre de rama puede contener texto diseñado para desviar al agente. El modelo nunca debe convertir una instrucción encontrada en una fuente en autorización para actuar.
6. Memoria, instrucciones y aprendizaje
Anthropic describe una memoria alimentada por Slack, instrucciones permanentes en Markdown versionadas en Git y un archivo de lecciones extraídas de incidentes anteriores. Esta organización es preferible a un prompt opaco modificado en una interfaz.
Las instrucciones deben especificar el orden de las verificaciones, las fuentes confiables, el formato del informe, los umbrales de escalamiento y las acciones prohibidas. Cualquier modificación pasa por una revisión de código y puede estar vinculada a un incidente específico.
La memoria debe ser filtrada. Un postmortem a veces contiene secretos, datos personales o hipótesis que se han vuelto falsas. Conserva resúmenes validados y una fecha de caducidad en lugar de un acceso ilimitado a todas las conversaciones históricas.
7. Los salvaguardas antes de una acción
Cuando se domina un controlador de solo lectura, se pueden proponer algunas acciones reversibles: abrir un ticket, preparar una solicitud de extracción, relanzar un trabajo no destructivo o generar un comando para validar.
La corrección descrita por Anthropic sigue siendo revisada, fusionada y desplegada por el ingeniero de guardia. Este límite debe ser explícito en la interfaz. Un botón de validación no es suficiente si el usuario no comprende exactamente los efectos.
Para una acción automática, exija como mínimo una política determinista, un alcance limitado, un registro firmado, un plazo, una condición de reversión y una prueba de verificación después de la ejecución.
8. Un plan de despliegue en cuatro fases
La fase 1 está fuera de línea: vuelva a jugar incidentes cerrados y compare el informe del agente con el postmortem. La fase 2 es la observación en tiempo real, sin notificación operativa. La fase 3 abre el informe a la guardia, siempre en modo de solo lectura. La fase 4 permite algunas acciones preparatorias o reversibles.
En cada etapa, defina criterios de paso: tasa de citas correctas, ausencia de acceso fuera del perímetro, tiempo de respuesta, calidad de las hipótesis y carga de verificación humana.
No salte directamente a la remediación automática. El incidente es precisamente el momento en que el contexto está incompleto, los sistemas están degradados y los errores son costosos.
9. Los indicadores a seguir
Mida el tiempo hasta el primer informe útil, el tiempo hasta la causa raíz, la precisión de los hechos, el número de hipótesis refutadas y el tiempo de revisión humana. También siga los incidentes en los que el agente no aportó ningún valor.
Un buen sistema debe reducir el tiempo de comprensión sin aumentar el riesgo. La tasa de “buen diagnóstico” por sí sola es insuficiente: un análisis correcto pero no fundamentado puede ser imposible de usar bajo presión.
La experiencia publicada por Anthropic muestra una dirección creíble para la externalización y el SRE. Sin embargo, su transposición exige una arquitectura de permisos, herramientas específicas y un progreso medido.
Partitech puede acompañar la implementación de un asistente de guardia: integración con las herramientas, roles de solo lectura, juegos de repetición, paneles de control, validación humana y procedimiento de reversión.