The First Job AI Agents Take Is the One Nobody Wanted.

Dynatrace announced autonomous operations on July 27. Not recommendations. Remediation. Its Cloud SRE Agent takes action across AWS, Azure, and Google Cloud, and the Autonomous SRE Agent it announced alongside it ships this month.

Microsoft already shipped the same idea. Azure SRE Agent is generally available right now, triaging incidents, correlating signals, and proposing fixes against live production.

Two years of demos about AI writing marketing copy, and the first job agents actually take is the 3 a.m. page.

Nobody Was Defending That Job

On-call went first for a reason, and it is not that incident response is easy.

It went first because it is the most instrumented work in the building. Every alert, every deploy, every metric, every log line is already captured. The success criterion is not a matter of taste. The graph goes back to green or it does not.

That is the whole story of where agents actually land. They do not go where the work is most valuable. They go where the work is most measurable.

Look at your own operation and ask which process has that shape: real-time data, a clear definition of done, and a human currently doing it at an hour they resent. That is where your first agent belongs. It is almost never the thing your vendor demoed.

The Approval Gate Is the Product

Here is the part that got buried under the word "autonomous."

Microsoft's documentation for Azure SRE Agent describes a permission gate, a pre-execution safety layer that evaluates every proposed tool call before it runs. The line in their own docs is blunt: the agent proposes changes and your team approves, and no change deploys without human sign-off. Audit telemetry routes into your own Application Insights instance.

Dynatrace built the same shape. Auditable action logs, centralized records across all three clouds, human approval and intervention where required.

Two competitors, working independently, both concluded that the valuable part is not the agent acting. It is the gate in front of the agent and the record behind it.

That should tell you something about the last eighteen months of agent marketing. The autonomy was never the hard engineering. Deciding what an agent is allowed to touch, who signs off, and how you reconstruct what happened afterward is the hard engineering.

A Gate With Nothing Behind It Is Just a Popup

Now the uncomfortable part.

An approval gate assumes somebody on the other side of it knows what "approved" means.

If your team has no runbook, no documented escalation path, and no written definition of a healthy system, that agent is going to propose a change at 3 a.m. to an engineer who has no basis to evaluate it. They will approve it, because the graph is red and the agent sounds confident.

You did not add a safety layer. You added a rubber stamp with an audit log, which is worse, because now the bad decision has your name on it.

The gate is only as good as the standard behind it. That standard is a document. Somebody has to write it.

This is the boring stuff, and it is the entire difference between an agent that reduces your incident load and an agent that automates your worst judgment.

On-Call Is Where Engineers Learn the System

I wrote a while back that AI came for the ladder, not the jobs. This is that argument with a specific address.

Getting paged at 3 a.m. is how a mid-level engineer learns how the system actually fits together. Not the architecture diagram. The real thing, with the undocumented dependency and the retry loop nobody remembers writing.

Hand every incident to an agent and you get quieter nights and a team that has never seen the machine under stress. Five years from now, the person who has to make the call the agent cannot make will not exist, because nobody built them.

So build the bench on purpose. Let the agent handle the noise, the known failure modes, the restart-and-reindex work. Keep humans in the loop on anything novel, and run incident reviews where an engineer has to explain what happened in their own words. Not the agent's summary. Theirs.

What I'd Do This Week

Pick the process with the clearest definition of done. Not the most expensive one. Agents succeed where success is measurable and fail where it is a judgment call. On-call went first because the scoreboard is objective.

Write the runbook before you turn on the agent. Trigger, thresholds, who owns the call, what "resolved" means, what gets escalated and to whom. If that document does not exist, you are not ready for an approval gate.

Decide what the agent may never do alone. Touch customer data, change access, restart anything with state, spend money. Put it in writing before somebody has to decide at 3 a.m.

Keep your audit trail in your own systems. Microsoft routes it to your Application Insights. Dynatrace centralizes it across clouds. Both are the right instinct. If the only record of what your agent did lives in a vendor's console, you do not have a record.

The Part That Matters

The agent takes the page. You keep the call.

Anybody selling you the other arrangement is selling you their liability, not your capability.

Write the runbook first. Then hand it the pager.