Cornerstone redujo el diagnóstico de bases de datos de 45 a 10 minutos. Sus agentes no tocan producción solos

Una consulta bloquea una tabla. Una segunda consulta espera sobre ella, una tercera espera sobre la segunda y, en algún lugar, una página carga lentamente para los clientes. El ingeniero de guardia abre vistas del sistema, logs y dashboards, buscando la cabeza de la cadena. En Cornerstone OnDemand, esa cacería solía tomar unos 45 minutos por incidente.

Un caso de estudio de AWS publicado el 7 de octubre describe lo que la compañía construyó para acortarlo, y el detalle más útil no es la velocidad. Es dónde se detienen los agentes.

Los ingenieros como capa de integración

Antes del proyecto, el diagnóstico era manual: consultar vistas del sistema, cruzar logs, coordinar entre equipos. Los flujos de trabajo del ciclo de vida de la base de datos tomaban diez o más pasos manuales. Los informes entre los equipos de confiabilidad del sitio y de datos llegaban con unos quince minutos de retraso, y las alertas redundantes competían por la atención.

Nada de eso es un problema del modelo. Es un problema de ensamblaje de evidencia, repartido entre sistemas que no se hablan entre sí, con una persona actuando como pegamento.

Trece agentes específicos y un orquestador

El sistema de Cornerstone, llamado Orion AI, usa un orquestador que enruta cada solicitud a uno de trece agentes de dominio, entre ellos diagnóstico de bases de datos, análisis de bloqueo de sesiones y diagnóstico SQL en tiempo real. Se ejecuta en Amazon Bedrock con el framework de código abierto Strands Agents, y los agentes comparten herramientas a través de MCP. Leen SQL Server a través de una API interna de operaciones, y trabajan con Jira, dashboards de métricas y calendarios de guardia.

Los agentes asignan cadenas de bloqueo a causas raíz, abren tickets de Jira ya completados y asignados, y correlacionan y deduplican alertas. Según cifras del equipo interno de operaciones de datos de Cornerstone, publicadas por AWS, el tiempo promedio de diagnóstico cayó de unos 45 minutos a unos 10, una reducción del 78%, y las alertas redundantes cayeron una mediana del 65%.

El tiempo de diagnóstico no es el tiempo de resolución. El caso reporta un segmento del incidente, para el que se construyeron los agentes.

Dónde actúan los agentes de Cornerstone y dónde preguntan

Los agentes actúan solos

• Consultar vistas del sistema
• Asignar cadenas de bloqueo
• Correlacionar y deduplicar alertas
• Abrir y asignar tickets de Jira

Leer y registrar

Una persona decide

• Operaciones destructivas en la base de datos
• Cualquier cosa que un guardrail marque como crítica

Ventana de cinco minutos, denegado al expirar

Los controles son el diseño

Tres decisiones del caso vale la pena copiar, y ninguna depende de Bedrock.

La aprobación tiene un reloj, y el silencio significa no. Las operaciones destructivas se detienen hasta que una persona confirma, dentro de una ventana de cinco minutos, y el valor predeterminado al expirar es denegar. Una aprobación sin fecha límite se convierte en una cola. Una aprobación que por defecto permite no es una aprobación.

La memoria no es de confianza para datos en vivo. El equipo limitó la memoria conversacional a la sesión y la omitió por completo para métricas en vivo, de modo que un agente nunca responde una pregunta sobre el estado actual de la base de datos a partir de lo que recordó diez minutos antes.

Los agentes se dividen por dominio, no por dificultad. Cada agente recibe un conjunto específico de herramientas, lo que según el equipo mejoró la selección de herramientas. El enrutamiento por defecto es la coincidencia de palabras clave, que maneja alrededor del 80% de las solicitudes, con búsqueda semántica como respaldo.

También es un proyecto modesto, lo que lo hace más creíble. Un equipo de tres personas lo entregó en seis meses, en Amazon ECS porque el runtime de Bedrock AgentCore no estaba disponible cuando empezaron.

La misma división, como patrón de referencia

El mismo día, AWS publicó una arquitectura que convierte el instinto de Cornerstone en una plantilla. Cuando termina una investigación del AWS DevOps Agent, un evento inicia una función durable de Lambda, y un modelo de Bedrock propone una remediación. Las herramientas de solo lectura se ejecutan por su cuenta. Los cambios de infraestructura suspenden el flujo de trabajo hasta que una persona aprueba. El modelo solo puede invocar herramientas de una lista de permitidos curada, las aprobaciones se registran en puntos de control, y el historial de ejecución muestra cada paso, cada llamada a herramienta y el razonamiento del modelo.

La publicación no dice qué sucede cuando una persona rechaza la solución. Esa es la parte que cada equipo tiene que diseñar, y la denegación por defecto de Cornerstone es una respuesta razonable.

Escribimos antes que cuando un agente se convierte en tu SRE, los permisos se convierten en ingeniería de confiabilidad. Estas dos piezas muestran cómo se ve eso en la práctica: la investigación se sitúa en un escalón alto de la escalera de autonomía, y cada cambio se sitúa un escalón más abajo, detrás de una persona y un reloj. La lección para cualquiera que construya un agente de operaciones es medirlo por la rapidez con que pone la evidencia correcta frente a una persona, y dejar que gane más solo sobre esa evidencia.