Find the button that matters
Ask a team to demonstrate its new AI agent. It reads a request, searches the right records and produces an impressive answer. Then someone copies the answer into another system, finds the approver, sends the message and checks what happened.
The demonstration has shown some capable work. It has not yet shown which part of the operating workflow changed.
My button test is useful if it starts that investigation. It becomes misleading if every human approval is treated as a failure of autonomy. A signature can be the part of the process that should remain human. Copying the same data between disconnected systems may be the part that should disappear.
The question I would take to a budget review is: which steps does the system complete, under what authority, and what does the business receive at the end?
Map one request all the way through
Consider a hypothetical purchase-request workflow. An employee emails a request. Someone checks the budget, looks up the supplier, confirms the terms, prepares an order, obtains approval, sends it and reconciles the acknowledgement.
An agent could collect the request, retrieve the approved records, identify missing fields and prepare the order for a named approver. That work can run without a person initiating each retrieval. The approver may still decide whether the company should make the commitment.
After approval, another permitted step could issue the order and track its acknowledgement. That step might also remain manual until the company has sufficient evidence and controls. Both designs deserve a precise description rather than a maturity badge.
| Step | What could be delegated | What still needs a decision |
|---|---|---|
| Receive and interpret | Read the request and identify missing information | How ambiguous requests are resolved |
| Check records | Retrieve budget, supplier and applicable terms | Which records are authoritative and current |
| Prepare the order | Assemble a traceable draft and flag exceptions | Whether exceptions can be resolved automatically |
| Authorise the commitment | Route a complete case to the right authority | The named approval or a bounded pre-authorised rule |
| Issue and reconcile | Execute permitted release and track the response | How failures, changes and mismatches are handled |
The map makes access and handoffs visible before value is assigned to them.
The approver’s button might be an intentional control. The clerk’s repeated copy-and-paste might be avoidable integration work. Counting them as identical would lead to the wrong investment.
Authority is a design choice
An agent may choose its next action within an objective, use tools and adapt to results. It can also pause at a human gate. Those properties can coexist. A useful system description names the actions permitted before and after the gate and the conditions that force escalation.
For the purchase request, the company might pre-authorise standard orders within an agreed scope while keeping unusual terms or larger commitments for review. It might instead require approval for every release. The right answer depends on evidence, consequence and the available controls.
When preparation outruns checking, the verification ceiling becomes a budget question.
The approval should be meaningful. Give the signer the request, applicable terms, exceptions and what has been checked. If the person merely approves a polished draft without a way to establish its basis, the button supplies little assurance.
The gate should also be enforceable. The agent should not be able to rewrite the approval state or issue the order through an alternate route. A prompt instruction describes the desired boundary; identity, permissions and release controls make the boundary operational.
Separate progress from the category label
A team can make a real improvement without closing the entire workflow. A retrieval assistant might shorten the time required to find the correct terms. A drafting system might reduce preparation effort. A more autonomous design might remove several handoffs and also create new integration and monitoring work.
No label determines which design has the better return. More autonomy can increase value, but it can also increase the cost of handling mistakes. A well-placed human gate can protect a large improvement. An unnecessary gate can conceal a process that nobody redesigned.
Evaluate the completed request against the previous process. Measure elapsed time, usable completion, corrections, exceptions and all-in cost. Include the human checking effort and the work passed to suppliers or another team. If a faster draft produces a slower approval queue, the business has bought a different outcome from the one on the slide.
Compare similar cases where possible. A fall in workload, a cleaner source database or a new approval rule can improve the result alongside AI. The leadership team needs to know which change it is funding, even when separating every contribution precisely is difficult.
Ask the vendor to show the exception
The happy path can conceal most of the remaining work. Ask for a request with a missing budget code, a changed supplier term or a conflicting delivery date. Watch what the system does, what evidence it presents and where the person has to intervene.
Then ask what happens after approval. Does the order reach the supplier? Is the acknowledgement checked? Can an interruption leave a duplicate order or an uncertain state? Who restores the case if the system stops between steps?
These questions turn a product demonstration into a workflow discussion. The answer may justify a narrow deployment, a further evaluation or investment in integration before wider autonomy. It may show that the existing assistant already addresses the most valuable constraint.
The business case should state the completed steps, retained decisions, intended volume and evidence required to expand permissions. It should name the process owner and the person who can stop release. A general promise of “agent-class returns” supplies none of those.
Bring one workflow map to the next funding decision. Mark every place a person copies, approves, sends or verifies. For each, write whether it is a useful control, missing integration, exception handling or work the system has not yet learned to perform reliably.
The map will show where to act. Preserve the button that protects a consequential commitment. Remove the one that exists because two systems still cannot exchange the same approved information. Judge the result by the work completed and the accountability it preserves.