O diagnóstico de um agente de SRE é um ponto de partida, não uma conclusão

“Sugerido não é o mesmo que confirmado.” A frase é a legenda de uma captura de tela num post de engenharia da Microsoft, sob o diagnóstico de um agente de IA para um incidente em produção, e pode ser a frase mais útil já escrita sobre agentes de operações neste ano.

No post, publicado em 14 de outubro, um engenheiro da Microsoft percorre um incidente numa demo da Contoso baseada num caso real: o health check do gateway passou enquanto pedidos e pagamentos falhavam. O Azure SRE Agent pegou o incidente e reportou um banco de dados PostgreSQL parado. O engenheiro então passou o resto da investigação conferindo essa afirmação. Os logs apontavam para um problema de conectividade; não provavam que o banco estava parado, e a própria checagem do log de atividades do agente não tinha encontrado nenhum evento de parada. O incidente real de produção por trás da demo, ele observa, foi esgotamento de recursos.

Um dia depois, a AWS anunciou algo com a mesma forma, na direção oposta.

Dois lançamentos, um handoff

AWS. O AWS Resilience Hub de nova geração agora se conecta ao AWS DevOps Agent. Quando um time roda um teste de resiliência, o agente observa e devolve uma análise estruturada de sintomas, causa raiz e impacto, junto com ações de recuperação observadas, como um Region switch. A partir de um achado da avaliação de modos de falha, um engenheiro pode iniciar uma tarefa do agente com o contexto do achado já carregado, investigar e montar um plano de mitigação. A integração é oferecida numa longa lista de Regions, incluindo South America (São Paulo). Estar na lista, porém, não diz onde a investigação roda: uma análise anterior da La Madre mostrou que o AWS DevOps Agent em São Paulo encaminha a inferência para fora da Region do Agent Space, então vale checar onde a inferência do agente acontece antes de assumir que os dados da investigação ficam no Brasil; como os logs costumam conter dados pessoais, isso pesa sob a LGPD. O anúncio descreve investigação e planejamento; não diz que o agente aplica mudanças sozinho.

Microsoft. O novo canvas do Azure SRE Agent coloca a investigação do agente ao lado de uma conversa do GitHub Copilot, no app do Copilot e em sessões do Copilot CLI que suportam canvas. O engenheiro traz o que falta ao agente de SRE: o código, fontes de dados privadas e conhecimento da aplicação. Conexões privadas continuam privadas para o Copilot; conectar uma investigação não dá ao agente de SRE as permissões de dados do engenheiro, e a evidência só volta ao agente quando o engenheiro faz o preview e aprova. As consultas são mostradas por inteiro e aprovadas antes de rodar. Conceder capacidade, o possível ajuste, é uma ação separada, com aprovação própria.

Por que o handoff é o design

Os dois lançamentos aceitam que um agente de operações enxerga só parte do quadro. O agente da AWS vê um teste estruturado que foi instruído a observar. O agente da Azure vê a telemetria à qual está conectado, não o cluster Kusto que só o desenvolvedor alcança. Nenhum deles deve ter a palavra final, e os dois produtos são construídos para que uma pessoa leve a análise adiante com o próprio acesso.

Isso tem duas consequências que valem a pena adotar, qualquer que seja a plataforma que você roda:

• A saída do agente deve separar afirmações de observações. O primeiro prompt do engenheiro da Microsoft pede ao Copilot que “separe o diagnóstico reportado da evidência observada” e liste “o que ainda precisa de verificação independente”. Esse deveria ser o formato padrão de todo resumo de incidente que um agente escreve, não um prompt que um especialista precisa lembrar.
• As permissões ficam com as pessoas. O acesso do desenvolvedor não é emprestado ao agente. Os achados do agente são trazidos ao desenvolvedor. Isso mantém a identidade do agente estreita, o que importa quando a investigação lê conteúdo de log não confiável. É o padrão que vimos na Cornerstone, onde agentes de banco de dados diagnosticam e depois pedem.

Onde os testes de resiliência mudam o jogo

A integração da AWS acrescenta algo que as ferramentas de incidente costumam não ter: uma causa conhecida. Num teste de resiliência, o time injetou a falha. Isso faz das execuções de teste o melhor conjunto de avaliação possível para um agente de operações. Se a análise de causa raiz do agente para uma falha injetada está errada, ela vai estar errada num incidente real também, e você descobriu isso numa terça à tarde, não às 3 da manhã.

Um programa prático para times que adotam qualquer uma das ferramentas:

1. Dê nota ao agente nas falhas injetadas antes de confiar nele nas reais: ele nomeou a causa que você injetou?
2. Exija links para a evidência de cada afirmação no resumo de um agente, a consulta e o resultado, do mesmo jeito que a Block mantém a evidência bruta por trás de cada investigação.
3. Mantenha a mitigação como uma mudança separada e aprovada, como fazem os dois fornecedores, mesmo quando o agente a redigiu.
4. Alimente o agente com os achados confirmados. A Microsoft observa que o que o engenheiro aprende volta para a memória do agente; revise o que entra, porque uma lição errada guardada ali se repete.

Os agentes de operações estão ficando bons na primeira hora de um incidente. O trabalho do engenheiro está migrando de encontrar a evidência para julgá-la, e as ferramentas finalmente estão sendo construídas para esse trabalho.