The test at the end is a good one to put in front of any team: if the AI service is down on run day, does the job still finish or fail safely? Many teams would honestly answer that they would wait.
Compiling the judgment is the idea I would repeat. When an agent solves a recurring problem, the output should be a script, tests from real cases, a runbook for someone new and a schedule owned by a team account. That turns a transcript into something the business owns.
Your point about drift is the most important caveat. A script that fails quietly is worse than an agent that varies visibly, so the fail closed layers, strict input contracts, invariants, history comparison and a known answer canary, are what make this approach safe rather than brittle.
On client work we scope recurring automation this way: AI helps build it, ordinary software runs it, and each approval gate is named in the scope with the person who owns it.