Agentic AI: deciding where autonomy actually belongs

Discussion of AI agents tends to collapse into a binary — either software acts on its own or a person does the work. In practice there are several useful positions between those poles, and most successful deployments sit in the middle.

A useful ladder: the system observes and logs what it would have done; it suggests an action a person approves; it acts within tightly bounded limits with review after the fact; it acts autonomously with exception-based escalation. Each rung should be earned with evidence from the one below it.

First, what is the cost of being wrong? Misrouting an internal ticket is recoverable. Posting an incorrect journal entry or emailing a customer is not, at least not cheaply. The reversibility of the action should set the default autonomy level.

Second, can the outcome be verified? If a person can check the result quickly against an objective standard, supervised autonomy is reasonable. If verification is as expensive as doing the work, autonomy provides little benefit.

Third, how varied are the inputs? If the task genuinely has high variety, that is the argument for using a model at all. If inputs are consistent, conventional automation is cheaper, faster and more predictable — and you should use it.

A recurring design error is asking a model to do work that code should do. Models are good at interpretation, classification and language. They are a poor choice for arithmetic, validation against fixed rules, and anything requiring exact reproducibility.

Well-built agentic systems are mostly conventional software. The model interprets an ambiguous input and selects between defined paths; deterministic code then executes the path, applies the rules and produces the result. That division keeps the system testable and the failure modes comprehensible.

Most automation programmes stall on exceptions rather than on the main flow. The main flow is understood; the exceptions are where institutional knowledge lives and where nobody wrote anything down.

Designing the exception path first — what happens when confidence is low, when a system is unavailable, when the input does not fit any expected case — produces a more realistic estimate and a system that degrades gracefully rather than failing silently.