The moment software moves a customer case, sends a message, changes a record, or triggers a difficult-to-reverse handoff, the question is no longer just whether its answer was useful. The enterprise has acted.
That is the consequential boundary between conversational assistance and agentic work. A chatbot can advise a person who decides what happens next. An agent can carry a decision into the workflow. The difference is not how fluent the text sounds. It is what the system is authorised to change.
The commitment begins with consequence
Hold one value stream steady: customer service case resolution. A conversational assistant may find a policy or draft a reply. The employee reviews the output and decides whether to act. An agent may also read the case state, recommend a disposition, request approval, route follow-up work, update the customer record, or contact the customer.
Each step changes two things: the consequence of an error and the evidence needed to reconstruct what happened. An unexecuted draft can be rejected. An executed error has to be found, contained, and unwound. That can mean retrieving a case, correcting adjacent records, handling a customer response, and checking whether a downstream process relied on the change.
Answer quality still matters. It is simply not enough. A successful tool call proves activity, not that the case reached the right destination or that the customer received the right outcome. The proof burden rises when software crosses from recommendation into authorised action.
The economics begin at the same boundary. Less handling effort may create capacity, which stays in hours or cases. A durable redesign of decision rights, controls, or handoffs may create structural value. Cash requires a documented and attributable change in money paid or received. Potential retention remains modeled until it is observed and attributed; revenue remains upside until it is recognised and attributed. These are separate claims. They cannot be summed, and released time does not become savings by multiplying it by salary.
Put authority where the action is
For the case-resolution stream, classify every permitted action as advisory, approval-gated, or authorised within explicit limits. Advisory means the system informs and a person decides. Approval-gated means the system proposes an action and a named person commits it. Authorised means the system may take a defined consequential action under stated conditions, with an exception owner, a safe handoff, and a tested route to reversal where reversal is possible.
Set this policy by consequence, not by technical complexity. A simple routing action may affect a customer promise or start another process. A sophisticated summary may remain advisory. The relevant questions are practical: What can happen next? Under whose authority? Which fields, messages, or routes may change? What happens when the case falls outside the rule?
This turns “human in the loop” into a decision right rather than a slogan. Business and process owners define permitted outcomes and exceptions; technology enforces permissions; control owners specify the evidence. The workflow authority standard can remain stable even when the underlying model changes, while model-specific quality, privacy, and security controls still apply.
What would count as proof?
Two layers of evidence answer different questions.
First, a boundary map shows which actions are advisory, which need named approval, and which are authorised within limits. A reconstructable log then records the starting state, recommendation, authority or approver, action taken, resulting state, exception, outcome status, and any reversal. Together, those artefacts show whether execution was governed.
Second, outcome evidence shows whether the commitment was worth making. For a defined group of cases and period, state the baseline, the operational measure, and the attribution approach. Compare correct routing, accepted resolutions, exceptions, rework, and reversals under the intended controls. Keep cash, capacity, structural value, and modeled upside separate. Without both layers, execution may be observable while its value remains unproven.
What remains unclaimed?
A boundary map does not remove risk; it locates it. A complete log does not prove that the action was correct. A record change is not a customer outcome, released capacity is not a reduction in spend, and controlled execution in one case flow does not establish safe autonomy elsewhere.
The leader’s test is direct: where does this workflow cross into consequential action, who authorised it, and could the enterprise reconstruct what happened?