AI Agents in Production: The Real Question Is Who Controls the Change

The conversation around AI agents is moving fast, from experimenting with them to actually letting them execute things.

Agents can already generate code, dig into incidents, tweak infrastructure definitions, propose configuration changes, and interact directly with operational systems.

The instinctive question people ask is usually: can we trust an AI agent to make production changes?

That's probably the wrong question, though.

We already let humans, pipelines, and various automation systems change production. So the real challenge was never whether some new actor is allowed to make a change. It's whether the platform can guarantee that every change, no matter who or what makes it, plays by the same rules.

Which leads to a better question: can AI-driven changes be governed with the same policy, auditability, and rollback guarantees we already expect from human-driven automation?

Trust shouldn't depend on who's making the change

Traditional infrastructure automation already assumes humans shouldn't have unlimited freedom. That's why we build:

• role-based access
• approval workflows
• policy-as-code
• version control
• CI/CD controls
• audit logs
• environment boundaries
• testing
• rollback mechanisms

These exist because even experienced engineers mess up sometimes. AI doesn't remove that need, if anything it makes it bigger. If an agent can act on its own, the platform needs to spell out exactly what it's allowed to touch, where, and under what conditions.

So trust shouldn't come from assuming the agent will always make the right call. It should come from building systems where the wrong call is difficult, or ideally impossible, to actually execute.

Autonomy without boundaries is just risk with extra steps

Picture an AI agent investigating a production incident. It spots what looks like an infrastructure configuration issue and proposes a fix. What happens next?

There are a few paths this could take:

• the agent modifies production directly
• it generates a pull request for a human to review
• it only executes inside a predefined sandbox environment
• it requires approval depending on how risky the change is
• it validates the change against policy before doing anything
• it monitors the outcome and rolls back automatically if something looks wrong

None of these are really AI questions. They're Platform Engineering, DevOps, SRE, and governance questions. The intelligence proposing the change is only one piece of the puzzle. What actually determines whether that change gets executed safely is the operating model wrapped around it.

Auditability matters even more now

AI also changes what accountability looks like.

With traditional automation, the path from a human decision to an infrastructure change is fairly easy to trace: an engineer writes code, a pull request gets reviewed, a pipeline runs, the change lands in production.

Agentic systems add another layer of decision-making on top of that. An agent observes information, picks an action, calls tools, and reacts to whatever comes back. That makes auditability essential. Organisations will need clear answers to questions like:

Without this kind of trail, debugging gets harder and governance becomes close to impossible.

Rollback can't be an afterthought

The same logic applies to rollback. Letting an agent make production changes without a reliable way to undo them is an obvious risk.

But it also exposes something bigger. A lot of organisations already have plenty of automation and pretty weak recovery processes. The agent doesn't create that problem, it just makes it visible.

If rollback is already painful for human-driven deployments, it'll stay painful for AI-driven ones. If configuration changes can't be reproduced reliably today, agentic automation will just inherit that same weakness. And if observability is thin, an agent might not even be able to tell whether its own fix actually helped.

This is probably one of the underrated upsides of adopting AI agents: it forces organisations to fix fundamentals that arguably should have been solid a long time ago.

AI agents might become just another platform consumer

There's an interesting architectural angle here too.

Right now, developers are the main consumers of internal developer platforms. In the near future, AI agents could become consumers too. They'll need their own APIs, permissions, workflows, policies, and controlled ways to touch infrastructure.

A well-designed platform can provide exactly those boundaries. Instead of handing an agent unrestricted infrastructure access, organisations can expose only approved capabilities through controlled interfaces. The platform becomes the enforcement layer.

That might actually be one of the most important roles Platform Engineering plays as agentic infrastructure grows. Not making AI autonomous, but making that autonomy governable.

So maybe the most useful question isn't "do we trust AI agents in production?" It's closer to "have we built a production environment where trust doesn't depend on who, or what, is making the change?"

That's a very different bar to clear.

How far should agent autonomy go in production environments, and where should the platform draw a hard line?