Cornerstone corta diagnóstico de banco de 45 para 10 minutos, mas agentes não tocam a produção

Uma query trava uma tabela. Uma segunda query espera por ela, uma terceira espera pela segunda e, em algum lugar, uma página carrega devagar para os clientes. O engenheiro de plantão abre system views, logs e dashboards em busca do início da cadeia. Na Cornerstone OnDemand, essa caçada costumava levar cerca de 45 minutos por incidente.

Um estudo de caso da AWS publicado em 7 de outubro descreve o que a empresa construiu para encurtar isso, e o detalhe mais útil não é a velocidade. É onde os agentes param.

Engenheiros como a camada de integração

Antes do projeto, o diagnóstico era manual: consultar system views, cruzar logs, coordenar entre times. Os workflows de ciclo de vida do banco de dados levavam dez ou mais passos manuais. Relatórios entre os times de site reliability e de dados atrasavam cerca de quinze minutos, e alertas redundantes competiam por atenção.

Nada disso é um problema de modelo. É um problema de montagem de evidências, espalhado por sistemas que não conversam entre si, com uma pessoa fazendo o papel de cola.

Treze agentes estreitos e um orquestrador

O sistema da Cornerstone, chamado Orion AI, usa um orquestrador que encaminha cada requisição para um de treze agentes de domínio, entre eles diagnóstico de banco de dados, análise de bloqueio de sessão e diagnóstico de SQL em tempo real. Roda no Amazon Bedrock com o framework de código aberto Strands Agents, e os agentes compartilham ferramentas via MCP. Eles leem o SQL Server por uma API interna de operações e trabalham com Jira, dashboards de métricas e escalas de plantão.

Os agentes mapeiam cadeias de bloqueio até as causas raiz, abrem tickets no Jira já preenchidos e atribuídos, e correlacionam e deduplicam alertas. Segundo números do time interno de operações de dados da Cornerstone, publicados pela AWS, o tempo médio de diagnóstico caiu de cerca de 45 minutos para cerca de 10, uma redução de 78%, e os alertas redundantes caíram uma mediana de 65%.

Tempo de diagnóstico não é tempo de resolução. O caso relata um segmento do incidente, aquele para o qual os agentes foram construídos.

Onde os agentes da Cornerstone agem e onde eles perguntam

Agentes agem sozinhos

• Consultar system views
• Mapear cadeias de bloqueio
• Correlacionar e deduplicar alertas
• Abrir e atribuir tickets no Jira

Ler e registrar

Uma pessoa decide

• Operações destrutivas no banco de dados
• Qualquer coisa que um guardrail sinalize como crítica

Janela de cinco minutos, negado no timeout

Os controles são o design

Três escolhas do caso valem ser copiadas, e nenhuma delas depende do Bedrock.

A aprovação tem relógio, e silêncio significa não. Operações destrutivas pausam até que uma pessoa confirme, dentro de uma janela de cinco minutos, e o padrão no timeout é negar. Uma aprovação sem prazo vira fila. Uma aprovação que por padrão libera não é uma aprovação.

A memória não é confiável para dados ao vivo. O time limitou a memória conversacional à sessão e a ignorou por completo para métricas ao vivo, de modo que um agente nunca responde a uma pergunta sobre o estado atual do banco com base no que lembrou dez minutos antes.

Os agentes são divididos por domínio, não por dificuldade. Cada agente recebe um conjunto estreito de ferramentas, o que, segundo o time, melhorou a seleção de ferramentas. O roteamento usa correspondência por palavra-chave por padrão, o que dá conta de cerca de 80% das requisições, com busca semântica como fallback.

É também um projeto modesto, o que o torna mais crível. Um time de três pessoas o entregou em seis meses, no Amazon ECS porque o runtime do Bedrock AgentCore não estava disponível quando eles começaram.

A mesma divisão, como padrão de referência

No mesmo dia, a AWS publicou uma arquitetura que transforma o instinto da Cornerstone em um template. Quando uma investigação do AWS DevOps Agent termina, um evento dispara uma durable function do Lambda, e um modelo do Bedrock propõe uma remediação. Ferramentas somente leitura rodam sozinhas. Mudanças de infraestrutura suspendem o workflow até que uma pessoa aprove. O modelo só pode invocar ferramentas de uma allowlist curada, as aprovações são registradas em checkpoint, e o histórico de execução mostra cada passo, cada chamada de ferramenta e o raciocínio do modelo.

O post não diz o que acontece quando uma pessoa rejeita a correção. Essa é a parte que cada time precisa desenhar, e o padrão de negar da Cornerstone é uma resposta razoável.

Escrevemos antes que quando um agente se torna seu SRE, permissões viram engenharia de confiabilidade. Esses dois textos mostram como isso fica na prática: a investigação ocupa um degrau alto da escada de autonomia, e toda mudança fica um degrau abaixo, atrás de uma pessoa e de um relógio. A lição para quem constrói um agente de operações é medi-lo pela velocidade com que coloca a evidência certa diante de uma pessoa, e deixá-lo conquistar mais somente com base nessa evidência.