Changing an Automation Is Part of Its Design, Not an Afterthought

The article argues that a demo of an automation shows only the happy path, while the real test is how the system handles changes to the process. It asks whether operators can update rules directly or need code, configuration, or further approvals, and how much retesting and explanation each change demands. Using an invented example of a team routing requests under frequently changing policy, it compares native approval rules, lightweight integrations, and custom agent-backed services, noting each trades off inspectability, expressiveness, and maintenance burden. The author recommends tracing a sample policy update through each option, naming its owner, artifact, verification, and recovery path, and testing one representative change with an expected failure and reversal. The piece reports no new deployment or measured results, framing its conclusions as hypotheses to examine.