An SRE agent's diagnosis is a starting point, not a finding. AWS and Microsoft both built the handover

“Suggested isn’t the same as confirmed.” The line is a screenshot caption in a Microsoft engineering post, under an AI agent’s diagnosis of a production incident, and it may be the most useful sentence written about operations agents this year.

In the post, published on October 14, a Microsoft engineer walks through an incident in a Contoso demo modeled on a real one: the gateway health check passed while orders and payments failed. Azure SRE Agent picked up the incident and reported a stopped PostgreSQL database. The engineer then spent the rest of the investigation checking that claim. The logs supported a connectivity problem; they did not prove the database was stopped, and the agent’s own activity log check had found no stop event. The real production incident behind the demo, he notes, was resource exhaustion.

A day later, AWS announced something with the same shape from the other direction.

Two releases, one handover

AWS. The next-generation AWS Resilience Hub now connects with AWS DevOps Agent. When a team runs a resilience test, the agent observes it and returns a structured analysis of symptoms, root cause and impact, along with observed recovery actions such as a Region switch. From a failure mode assessment finding, an engineer can start an agent task with the finding’s context already loaded, investigate and build a mitigation plan. The integration is offered in a long list of Regions, including South America (São Paulo). The announcement describes investigating and planning; it does not say the agent applies changes itself.

Microsoft. The new Azure SRE Agent canvas puts the agent’s investigation next to a GitHub Copilot conversation, in the Copilot app and in canvas-capable Copilot CLI sessions. The engineer brings what the SRE agent lacks: the code, private data sources and knowledge of the application. Private connections stay private to Copilot; connecting an investigation does not give the SRE agent the engineer’s data permissions, and evidence goes back to the agent only when the engineer previews and approves it. Queries are shown in full and approved before they run. Granting capacity, the possible fix, is a separate action with its own approval.

Why the handover is the design

Both releases accept that an operations agent sees part of the picture. The AWS agent sees a structured test it was told to watch. The Azure agent sees the telemetry it is connected to, not the Kusto cluster only the developer can reach. Neither should be the last word, and both products are built so that a person takes the analysis further with their own access.

That has two consequences worth adopting whatever platform you run:

• The agent’s output should separate claims from observations. The Microsoft engineer’s first prompt asks Copilot to “separate the reported diagnosis from observed evidence” and list “what still needs independent verification.” That should be the default format of every incident summary an agent writes, not a prompt an expert has to remember.
• Permissions stay with people. The developer’s access is not lent to the agent. The agent’s findings are brought to the developer. This keeps the agent’s identity narrow, which matters when its investigation reads untrusted log content. It is the pattern we saw at Cornerstone, where database agents diagnose and then ask.

Where resilience testing changes the game

AWS’s integration adds something incident tooling usually lacks: a known cause. In a resilience test, the team injected the failure. That makes test runs the best possible evaluation set for an operations agent. If the agent’s root cause analysis of an injected failure is wrong, it will be wrong in a real incident too, and you found out on a Tuesday afternoon rather than at 3 a.m.

A practical program for teams adopting either tool:

1. Score the agent on injected failures before trusting it on real ones: did it name the cause you injected?
2. Require evidence links for every claim in an agent’s summary, the query and the result, the way Block keeps raw evidence behind each investigation.
3. Keep mitigation as a separate, approved change, as both vendors do, even when the agent drafted it.
4. Feed confirmed findings back. Microsoft notes that what the engineer learns goes back into the agent’s memory; review what goes in, because a wrong lesson stored there repeats.

Operations agents are becoming good at the first hour of an incident. The engineer’s job is moving from finding the evidence to judging it, and the tools are finally being built for that job.