Your agent loop is not a production system

An Amazon Web Services engineer argues that once an AI agent can change live systems, teams must prove separately who approved a change, what ran and whether it worked.

Sriram Madapusi Vasudevan, a senior software engineer at Amazon Web Services (AWS), works on AWS DevOps Agent, an AI agent that joins on-call engineers during production incidents. He describes what the system around such an agent must record and check once it can change cloud resources. He argues that engineering leaders should set these rules for every team before any agent may change production.

• An approval should name the exact operation, resource, approver and expiry. It should survive a restart, be used once, and be asked for again if the target changes.
• Every change an agent makes should pass through one gateway, whether the agent calls a tool directly, writes code, or hands the task to another agent.
• A rollback can succeed while the errors continue, so the system should confirm that the incident has cleared before it counts the task as done.
• He proposes that a platform team own the shared machinery and that domain teams own their tools and what counts as done. Operators own approval limits and the power to stop work.

An engineering team that lets an AI agent act on production can store each approval with its scope and expiry, and check the outcome before counting a task done. The author draws on his own work on an AWS product, and the application to other teams is an inference.

Derived by Working Surface from the article. Source line: Approval proves authority. Execution evidence proves what changed. Verification proves whether the goal was reached.

28 September 2026: when agents build, people keep the first screen, the review, the files agents read and the whole product.