Cerrando el ciclo en las métricas

Mientras que cada etapa anterior necesita que una persona la inicie, la Etapa 6 traslada el enfoque hacia la ejecución autónoma de Claude para cerrar el ciclo. Por ejemplo, un agente de monitoreo que se ejecuta continuamente podría, a raíz de que se genere un ticket de error, crear un intent.md, y avanzar a través de las fases de requisitos, plan, construcción, prueba y revisión. Etapa 6: Mantener se ejecuta sin interfaz (headless), con una puerta de confianza independiente entre etapas, una verificación determinista o un agente revisor adversarial, que decide si el resultado de la etapa anterior continúa o se escala a un humano.

Qué cambia

Un script determinista vigila producción e invoca a Claude cuando se infringe una banda de control. El monitoreo de una infracción es un ejemplo útil del patrón para el ciclo que se ejecuta de forma autónoma, mientras que la sección de Claude Tag (beta pública) al final de la etapa cubre el trabajo que llega a través de diferentes canales.

Qué es una banda de control

Una banda de control es un rango alrededor del nivel normal de una métrica, que el script de detección toma como la media de los últimos 30 días de lecturas por hora. El script también calcula sigma (σ), la desviación estándar, o cuánto suelen desviarse las lecturas de la media. La banda de 1σ termina en la media más un σ, la banda de 2σ en la media más dos, y así sucesivamente.

Si las lecturas de una métrica estable siguen una curva de campana, aproximadamente una de cada seis cae por encima de 1σ, una de cada 44 por encima de 2σ, y una de cada 740 por encima de 3σ. Con 720 lecturas al mes, el azar por sí solo produce alrededor de cuatro al día por encima de 1σ, 16 al mes por encima de 2σ, y una al mes por encima de 3σ. Por eso el nivel 1σ solo registra, y por eso incluso el nivel 3σ, que el ruido por sí solo activaría aproximadamente una vez al mes, se mantiene restringido a rutas controladas.

Las reglas de Western Electric, provenientes de un manual de control de calidad de 1956, detectan una deriva lenta que puede nunca cruzar 3σ. Señalan cuatro de las últimas cinco lecturas por encima de 1σ, u ocho consecutivas por encima de la media.

Primeros pasos

• Requisitos previos: intent.md, que le da al ciclo una salida estructurada para reiniciar. Revisiones de PR aceleradas por Claude, hooks como límite de acción, y una ruta de reversión para CI/CD (que invoca el nivel de autonomía más alto).
• Infraestructura: Un almacén de métricas que el script de detección pueda consultar (Prometheus, la API del sistema de CI, o equivalentes), acceso de lectura al repositorio, una forma de ejecutar Claude Code de manera no interactiva en CI, o el Agent SDK para un servicio que recibe webhooks.

Cómo ejecutarlo

1. El propietario del servicio o el ingeniero de plataforma elige una métrica con una línea base móvil estable, como la tasa de fallos de pruebas de CI, la tasa de errores 5xx posteriores al despliegue, o el tiempo de ciclo de PR.
2. Escriben el script de detección, típicamente media y desviación estándar sobre una ventana móvil con reglas (Western Electric o similares) para que las bandas detecten tanto la deriva lenta como los picos. El script está bajo control de versiones y tiene pruebas unitarias, y la detección permanece completamente determinista, sin que intervenga ningún modelo.
3. Los niveles de respuesta se definen en una configuración bajo control de versiones (bands.yaml a continuación). En 1σ el script solo registra, en 2σ invoca a Claude en modo de solo lectura para diagnosticar, y en 3σ Claude puede actuar, aunque solo abriendo un PR hacia la puerta de revisión o activando un runbook preaprobado. Una regla de deriva cuenta como 2σ.
4. La capa de disparadores puede ser un flujo de trabajo programado en GitHub o GitLab, un webhook del stack de monitoreo existente, o un trabajo cron dentro de la red. Claude se ejecuta sin estado, ya sea como un paso no interactivo en un ejecutor de CI o como un servicio de Agent SDK en un contenedor en sandbox, y la guía de CI/CD cubre las opciones de despliegue y acceso al modelo. Debido a que la ejecución no tiene estado y no es interactiva, un ciclo puede comenzar y terminar sin que nadie lo inicie.
5. El agente escribe su diagnóstico como intent.md en el formato de la Etapa 1: Planificar, cubriendo la anomalía y su evidencia, un resultado propuesto, los sistemas afectados, y cualquier pregunta abierta. A partir de ahí, el hallazgo pasa por el pipeline como cualquier otro.
6. El propietario del servicio o el ingeniero de guardia clasifica la cola, dirigiendo los hallazgos orientados al producto hacia el propietario del producto. Corregir ahora, programar, o descartar. Los descartes ajustan las bandas y ayudan a reducir el ruido.
7. Cuando se lanza una corrección, agrega una evaluación para el incidente (la guía de evaluaciones continuas) para asegurar que tales problemas queden protegidos de cara al futuro.

Cómo se ve

Por ejemplo, un bands.yaml que monitorea la tasa de fallos de pruebas de CI:

metric: ci_test_failure_rate
baseline: rolling_30d
rules: western_electric
tiers:
  1sigma: { action: log }
  2sigma: { action: diagnose,
            tools: "Read,Grep,Bash(gh run view *)" }
  3sigma: { action: propose,
            routes: [pull_request, runbook:rollback-deploy] }

El resto de este ejemplo aplica el mismo archivo a una métrica de producción, y solo cambia la primera línea, a metric: status_5xx_rate. Esa métrica es la tasa de errores 5xx en el endpoint de estado de reclamaciones de una aseguradora.

El trabajo programado que ejecuta el script cada hora busca el nivel impreso en bands.yaml e inicia a Claude con las herramientas o rutas de ese nivel. Para el nivel propose, eso significa una lista de permitidos que contiene gh pr create y el único comando que activa el runbook.

Los clientes ven el estado de la reclamación en un panel del portal, y el panel almacena en caché cada respuesta durante 60 segundos. Supongamos que un lanzamiento a las 13:52 pone esa caché en cero.

Ahora cada vista de página llega a claims-core, el sistema más antiguo detrás del endpoint. Este permite 50 solicitudes por segundo y comienza a rechazarlas. A las 14:00 el script imprime:

{"tier": "3sigma", "rule": "reading above 3 sigma", "reading": 1.9, "mean": 0.2, "sigma": 0.02}

El nivel 3σ se corresponde con propose, que restringe al agente a las dos rutas listadas. Un lanzamiento salió minutos antes de la infracción, así que el agente ejecuta el runbook rollback-deploy, que fue aprobado de antemano. Luego escribe lo que encontró como intent.md, en el mismo formato que usaría una persona en la Etapa 1:

# Intent: status endpoint 5xx after release 4f2c9e1
Author: monitoring agent (status_5xx_rate, 3 sigma). Status: draft.
## Problem
The 5xx rate on GET /claims/{id}/status read 1.9% at 14:00. The 30-day mean is 0.2%.
Release 4f2c9e1 went out at 13:52. It changes CACHE_SECONDS in StatusPanel.tsx from 60 to 0.
With no cache, every page view reaches claims-core, which allows 50 requests a second (CLAUDE.md).
## Proposed outcome
Customers get fresher status without the portal passing the claims-core limit.
## Affected users and systems
Portal customers, claims-api, claims-core API.
## Constraints
The panel's spec.md allows status to be up to 60 seconds old (R4). The claims-core limit is fixed.
## Action already taken
Ran the rollback-deploy runbook at 14:02. It reported version 8c41d07 live again at 14:04.
## Open questions
Who asked for live status, and is 60 seconds too slow for them?

Cuando se lanza la corrección, el incidente deja una evaluación, como en el paso 7 anterior. La evaluación le da al agente la solicitud que provocó el incidente y falla si la caché ha desaparecido. En ella, from es el commit desde el que comienza una ejecución, y may_change enumera las carpetas que puede tocar:

{
  "name": "status-panel-keeps-its-cache",
  "source": "Incident: status endpoint 5xx after release 4f2c9e1",
  "from": "4f2c9e1~1",
  "prompt": "Customers say the claim status panel feels stale. Make it feel live. Run the tests before you finish.",
  "may_change": ["claims-api/routes", "claims-api/tests", "portal/src"],
  "checks": [
    { "name": "tests pass", "run": "make test" },
    { "name": "lint clean", "run": "make lint" },
    { "name": "panel still caches", "run": "grep -Eq 'CACHE_SECONDS = [1-9]' portal/src/claims/StatusPanel.tsx" }
  ]
}

Consideraciones de gobernanza

Los límites de los niveles se aplican desde una configuración bajo control de versiones, con permisos y configuraciones administradas que niegan el acceso a producción. Las invocaciones, los hallazgos y las decisiones de clasificación se registran con una marca de tiempo. Un propietario del servicio clasifica y aprueba los hallazgos, los cambios resultantes pasan por la puerta de revisión de PR normal, y los runbooks que el agente puede activar fueron aprobados de antemano.

Cómo medirlo

• Indicador adelantado: El tiempo desde la infracción de la banda hasta un intent.md en la cola de clasificación, frente al tiempo anterior desde el incidente hasta la acción posterior al incidente. El registro del script de detección tiene la marca de tiempo de la infracción y el nivel del incidente.
• Indicador rezagado: La proporción de hallazgos que se convierten en correcciones fusionadas (cola de clasificación frente al historial real de PR), y los incidentes repetidos de la misma clase, que deberían disminuir a medida que las correcciones agregan casos al conjunto de evaluaciones.

Ejemplos

• Cuando la tasa de fallos de pruebas de CI infringe 3σ, el agente pone en cuarentena la prueba inestable o abre un PR de reversión, y la puerta de revisión decide.
• Cuando la tasa de errores 5xx posteriores al despliegue infringe 3σ con un despliegue dentro de la ventana, el agente activa el pipeline de reversión existente.
• Cuando el tiempo de ciclo de PR activa una regla de deriva, el agente escribe un informe para el liderazgo de ingeniería, lo que demuestra que el arnés funciona tanto para métricas de proceso como para métricas de producción.

Claude de guardia con Claude Tag

Los incidentes también pueden llegar por otros medios, como aplicaciones de comunicación laboral, tales como Slack o Microsoft Teams. Los incidentes pueden presentarse como un mensaje de Slack a las 10 p.m. para una corrección urgente en un canal de incidentes, y ahora pueden accionarse de inmediato. Claude Tag (beta pública actualmente disponible en Slack) convierte a Claude en miembro de esos canales bajo su propia identidad, de modo que cada nuevo incidente obtiene un primer respondiente y la respuesta misma se convierte en parte del ciclo y la memoria para futuros incidentes.

La conversación y el conocimiento institucional permanecen en el canal, y cualquier persona en el canal puede guiar y accionar la respuesta. Cualquier miembro del equipo puede probar hipótesis, explorar nuevas opciones e investigar en tiempo real, con el historial del canal sumando a la auditabilidad. A través del acceso a MCP, Claude verifica que la métrica haya vuelto a su línea base y lo confirma en el hilo, y escribe el post-mortem en un archivo de lecciones bajo control de versiones que futuras investigaciones pueden leer.

Los incidentes no son el único trabajo que Claude Tag asume. Etiquetado en un ticket a través de MCP o consultado en el canal, Claude clasifica el trabajo de la misma manera. Una corrección pequeña y bien delimitada llega como un PR a través de la puerta de revisión, y cualquier cosa más grande se redacta como intent.md para la Etapa 1: Planificar, momento en el cual el ciclo comienza a alimentarse a sí mismo.