The consequence changes even when the capability does not
An assistant that drafts a reply and a system that books a shipment use much the same underlying capability. They do not carry the same risk, and the difference is not measured in model accuracy. It is measured in what happens when the output is wrong. A wrong sentence costs a few minutes of attention. A wrong write creates a record and starts other systems reacting to a fact that was never true.
Moving from conversation to execution is an organisational decision, not a technical one. Someone must decide which actions may run unattended, which must wait for a person, and which are refused altogether. That decision cannot be delegated to a model.
Answering is read-only, and read-only failures are cheap
Assistance has a forgiving failure mode. A wrong answer is caught by the person who reads it, usually before it reaches anyone else. That is why conversational systems spread so easily: the reader is a free safety mechanism. Remove the reader and the same class of error becomes expensive.
| Dimension | Read-only assistance | Executing system |
|---|---|---|
| Typical error | A poorly formed or wrong answer | A wrong record, message or transaction |
| Detected by | The person reading the output | Downstream systems, customers or a later audit |
| Cost of correction | A few minutes of attention | Reversing a write, crediting, re-shipping, explaining |
| Accountable owner | The reviewer, informally | A named business owner, by design |
A tool is a contract, and the contract is the design
An executing agent is not a chat interface with a database attached. It is a set of narrowly described capabilities, each declaring what it needs and what it changes. That contract is what the business reviews, what the platform enforces and what the audit log records.
- Purpose: what the action is for, and what it must never do.
- Preconditions: which fields must be valid before it may run.
- Effects: which records, messages and downstream events it creates.
- Permission: the identity it runs as, and what that identity may reach.
- Reversibility: whether it can be undone, or needs a compensating action.
- Audit: what is written to the record when it runs.
Idempotency and transaction boundaries decide whether retry is safe
Retrying is unavoidable. Networks fail, calls time out, and a process restarts after a crash at exactly the point where the outcome is unknown. The question is not whether an action will run twice, but whether running it twice matters. An action that creates a second order matters, and so does a customer notice sent twice.
So the contract for a consequential action should say whether repeating it is safe, and if not, what identifies a repeat: a business identifier from the caller, a deduplication key held against the record, or a natural key derived from the content. Where an action spans two systems the boundary matters, because a first write that succeeds and a second that fails leaves the operation neither done nor undone.
The approval gate belongs to the process, not to the model
Consequential actions are usually approved by a named person, and the interesting engineering question is where that gate sits. A gate placed after the write is an audit log. A gate placed before it is a control, and how much approval an action needs should follow from how reversible it is. The design of those states, the evidence the approver is shown, and the behaviour when nobody responds are covered in designing AI workflows with human approval and exception handling.
Our own renewal demonstration makes the shape concrete. It evaluates a small set of versioned rules against reconciled records, and the agent, running under a named identity, has no write access at all. Where a customer-facing action is required, the system raises an approval request for a named role, and the decision is recorded with the evidence the approver saw.
Where a person has to remain in the decision
The workable boundary sits between understanding and committing. Extracting a commitment from a message, classifying a request, checking a record against a stated rule and ranking options are things a model can do without authority. Deciding whether a credit is due or a commitment is binding is not: the organisation will be asked to defend those consequences.
The difficulty is that this boundary does not align with process boundaries. One order-to-cash flow contains a dozen actions, some trivial and some consequential, and a blanket rule against unattended customer-facing action is too blunt: it also blocks the notification that would close a support ticket. Classifying the actions is a discipline in its own right, covered in how to identify which tasks should be done by people, AI or both.
A sequence for introducing action safely
- Put one read-only use case into production first, because it establishes the data connections and the operating routine without moving anything consequential.
- Inventory the candidate actions and classify each by consequence, reversibility and frequency, with the business owner doing the classification.
- Write the contract for each action you intend to allow, including the idempotency behaviour and the recovery path for a partial failure.
- Put the approval gate in front of the consequential actions, and test the no-response case before the successful path.
- Release to a limited population with a daily review of the exception queue, and widen the scope only when that review has become boring.
The measures that show execution is working are mostly about waiting: the share of actions held for approval, how long an exception sits in the queue before somebody owns it, and how many completed actions must be corrected afterwards.
The choice of mechanism for each task matters as much as the sequence: the argument for taking the simplest adequate option is in when to use AI, conventional automation, business rules or a combination. The discipline that keeps the permission boundary honest is in enterprise agent engineering.