A practical way to tell useful autonomy from expensive uncertainty, with a test you can apply to any business process.
Most business processes do not need an agent. They need a reliable sequence of steps that someone has written down. If the steps are known, the inputs are structured, and the failure cases are predictable, a script will be cheaper, faster, and easier to trust than a model deciding what to do next.
Agents earn their place when the path is not known in advance: the inputs are messy, the next action depends on what was just discovered, and a person would normally use judgement to get through it. Reading a supplier's email thread to work out which invoice is being disputed is agent work. Posting the disputed amount to the ledger afterwards is a script.
A useful test is to ask what you would do if the system got it wrong. If the answer is "re-run it", the task is probably deterministic and belongs in a script. If the answer is "look at what it was thinking and correct it", you are describing an agent, and you should budget for the review tooling that makes correction possible.
The strongest designs we build combine both: agents handle the ambiguous front end of a process, and hand off to plain code the moment the work becomes well defined. That boundary is where most of the reliability lives, so we design it first.