Agents are becoming authors of production changes. Your change process is now your agent governance

Look at what enterprise agents shipped in the past week and a pattern appears that has little to do with chat. ServiceNow’s Autonomous Engineer plans, builds and tests workflow changes. Google’s EKS-to-GKE agent translates Kubernetes manifests and proposes them through GitOps. AWS’s migration design generates infrastructure code from approved modules. In each case the agent’s output is the same kind of object: a change to a production system.

That matters because enterprises already have a mature control for changes to production systems. It is old, unglamorous and audited every year. Our view, and it is a view rather than a fact, is that change management is about to become the main place where agent autonomy is governed, and that most companies will get there faster by extending it than by inventing an AI-specific process.

The signals

• Workflow changes. ServiceNow’s AI Workflow Factory loops process mining, agent building and deployment, with Autonomous Engineer (Early Access) doing unattended coding.
• Infrastructure changes. Google’s EKS-to-GKE migration agent (Public Preview) puts approval gates and GitOps between the agent and the cluster. AWS’s migration architecture has an agent compose infrastructure code from approved modules.
• Changes to the agent itself. A model swap changes behavior without changing code, which is why we called model retirement the new API deprecation.
• Apps nobody coded by hand. Platforms such as Copilot Managed Runtime run applications generated from natural language, which still need a release process.

What changes when the author is an agent

Change processes were designed around scarce authors. A team produced a manageable number of changes, and a change advisory board could review the risky ones. Agents remove the scarcity. When an agent can propose twenty workflow improvements a week, three things break:

1. Volume. Human review of every change does not scale, and rubber-stamping is worse than no review.
2. Attribution. “Author: svc-automation” says nothing about which agent, which version, which model, or which person asked for it.
3. Separation of duties. If the same platform’s agent writes, tests and promotes a change, the control that separates author from approver has quietly disappeared.

A change record for agent-authored work

1. Author: agent ID, version, model
2. Sponsor: the person who asked
3. Scope: systems and data touched
4. Evidence: tests and checks run
5. Approver: a different identity
6. Rollback: plan and trigger

Recorded by the platformNamed people

Then use the change categories you already have to decide where autonomy goes:

• Standard changes are pre-approved, low risk and repeatable. This is where an agent can act alone once it has a track record, for example applying a tested template to a new team’s workflow. The ladder in our framework for earned autonomy applies directly: promote a class of change to “standard” for an agent only on evidence.
• Normal changes need assessment and approval. Agents can author them, but the evidence (tests, policy checks, impact analysis) must be produced by the pipeline, not described by the agent, and the approver must be a different identity, human or policy engine.
• Emergency changes stay human. An agent may diagnose and propose, but the decision to bypass normal approval belongs to an accountable person.

The answer to volume is not a bigger review board. It is moving evidence into the pipeline (automated tests, policy as code, comparison runs) so that people review the decision, not the diff.

Why auditors will get there first

For U.S. public companies, program change is one of the core domains of SOX IT general controls. An auditor sampling changes to a financial workflow will ask who authored it, who approved it and what testing supported the approval. “An agent did it” is not an answer the control framework recognizes; “agent X version Y, sponsored by person A, approved by person B after test run Z” is. Our expectation is that within a year, agent authorship becomes a standard field auditors ask to see.

What to do now

1. Add agent authorship fields to your change records: agent identity, version and model, plus the sponsoring person.
2. Enforce a different approver identity for every agent-authored normal change.
3. Define which change classes an agent may treat as standard, and require evidence before adding one.
4. Move evidence into the pipeline so approval reviews results, not descriptions.
5. Treat model and prompt updates to an agent as changes to that agent, with the same record.
6. Report agent-authored changes separately for six months, with failure and rollback rates, before granting more autonomy.

The bottom line

The governance question for agents that write production changes has an old answer: change management. Extend it with agent authorship, keep author and approver separate, and let evidence from the pipeline decide which kinds of change an agent can make alone.