The demonstration I would want to see
An invoice arrives. An AI agent reads it, finds the purchase order and the goods receipt, checks the amounts and prepares the case for approval. The documents agree, the evidence is assembled in seconds, and the finance team can see exactly what the agent did.
That is a good demonstration. It is not, by itself, a reason to deploy an AI agent. Enterprise finance systems already match invoices against orders and receipts, apply tolerances and flag discrepancies. What might be worth testing is whether the agent can bring the scattered evidence around an exception into one reviewable case. I would want to see that demonstration next.
Give the agent a partial receipt. Then a duplicate invoice. Then an email claiming someone approved an extra charge that the contract record knows nothing about. A serious team will have thought about cases like these already. They will have tested the agent against them, limited what it can change, given it a route to a person and recorded what it does. That is simply what building a production system involves.
So suppose the agent passes. It matches the clean invoices, flags the exceptions, cites its evidence and leaves the consequential decisions to the people authorised to make them. On every measure the team set for it, it works.
And the invoice process is still slow.
That, to me, is the more interesting production question. The demonstration looked like magic because one step in a long process suddenly became very fast. The rest of the process carried on as before. When I ask who the magician is, I mean the person who can connect the decisions, records and handoffs around the agent, and who answers for the outcome.
The agent passes. The work stalls.
Imagine that invoices with contract variations keep landing in the exception queue. The agent correctly spots each mismatch and stops. A finance reviewer opens the case, finds the supplier's email and asks procurement whether the extra charge was approved. Procurement searches another mailbox. Eventually the contract owner confirms the change was agreed, records the amendment and sends the case back to finance.
The following week a similar case arrives from the same business unit, and the agent stops again, exactly as designed. No control has been relaxed and no payment has gone out wrongly. Nobody has treated an email as formal approval. The same investigation is simply eating time in finance and procurement, week after week.
A team under pressure has a couple of tempting responses. It can tune the prompt or add test cases, though neither will put the missing amendment into the contract record. Or it can let the agent infer approval from the email, which would make the dashboard look healthier while quietly removing the very control everyone wanted to keep.
The useful conversation is between finance, procurement and the contract owner. Where should an approved variation be recorded, and who updates it? Which of these cases genuinely need judgement, and which are waiting only because a routine step keeps getting skipped? Those are operating decisions. Once they are made, the agent can support the new process very well. It cannot make them.
We have seen this before
This pattern has appeared in several waves of enterprise technology. A system can execute its assigned step while an approval, handoff or missing record holds up the outcome. I have worked across architecture, data, products and customer outcomes long enough to look for that gap when a new capability appears to make one step effortless.
RPA offers a useful parallel. A bot can carry out a defined task reliably while the approval sits in another team's inbox. Michael Hammer made the broader point in 1990: speeding up an inherited process is not the same as redesigning the work. Accounts payable already has document capture, matching, tolerances and workflows. An agent has to add something beyond another way to identify a variance: a better-evidenced path to resolving it.
Agents can make the gap unusually visible, because they can assemble the surrounding evidence as well as perform their own step.
What the exception queue knows
An exception queue contains cases automation cannot settle. A recurring exception is usually a decision the organisation has not finished making. That does not mean every repeat should disappear: sometimes the right decision is to keep a person involved, with clear evidence and authority. In other cases, the repeat shows that an agreed decision never reached the workflow.
Some exceptions are healthy. A disputed price, an unusual supplier request or a possible duplicate payment deserves a person's attention, and always will. Others point to avoidable work: an approval that always lives outside the system of record, a policy two teams read differently, a document that reliably arrives too late to be useful.
Before anyone argues for more agent autonomy, I would want to know which is which. How many cases are genuinely ambiguous, and how many are repeats of a gap everyone already knows about? How often does the reviewer change the agent's recommendation, and why? Do cases come back after being marked complete? The answers might point to better data, a clearer policy, a redesigned step or a narrower role for the agent. Occasionally they point to leaving things exactly as they are, which is also a decision worth making on purpose.
A person in the loop needs a real decision
"A human approves it" is often offered as the final answer to concerns about agent actions. Whether it really is depends on what that person sees, how much time they have and what authority they actually hold.
An approval screen that presents a confident recommendation, buries the conflicting evidence and sits in front of a growing queue will produce signatures without much judgement behind them. The reviewer needs the purchase order, the receipt, the contract terms and the reason for the referral, laid out so they can challenge it. They also need real options: send the case back, correct a record, or ask for a rule upstream to change.
So I would use human review deliberately, for decisions whose stakes, ambiguity or irreversibility justify it. It is the same reversibility test I argued for in the second Decode, applied to a single action instead of a whole platform. When a reviewer's decisions start to show a repeatable pattern, that pattern is information about the process. A repeated exception can still be a repeated risk, and some should stay with a person indefinitely. Either way, the pattern deserves to be read, which a simple count of referrals will never do.
Who changes the work?
This is where the magician question gets demanding. The team that built the agent can improve its retrieval, tools and evaluations. Finance owns the payment process. Procurement owns the purchase order and, in many organisations, the contract amendment. Security governs access. The person working the exception queue knows precisely which written rule does not match what actually happens.
All of them are needed, and none of them can change the work alone. Someone has to be able to bring them together and decide what changes when the evidence shows the agent is faithfully executing a poor process. I would place that accountability with the business owner of the end-to-end outcome, supported by named owners for the technology, the data and the controls. Naming them only helps if it gives them a genuine route to change the process. An owner who just receives alerts is really an audience member with a better seat.
In the third Decode I described Agent-led, Agent-assisted and Human-led decisions, guided by stakes, ambiguity and reversibility. The owner here is the person who decides where each kind of invoice sits, and those choices are rarely as simple as switching the agent on or off. The agent might prepare every invoice and release none. Well-defined, low-value cases might move to a faster path once the approval record can be trusted. A particular kind of exception might always go to a person. Or the biggest gain might come from changing how contract variations are captured, leaving the agent's authority exactly where it is.
That last option is the one most often missed, because it does not look like an AI decision at all. It is also where I would look first, because it is often where the lasting gain sits.
Readers of the first Decode may recognise the shape of this. There I described an Architecture-to-Outcome Bridge with five spans: decision rights, end-to-end ownership, operating rhythm, guardrails, and feedback and evidence. The invoice agent is a neat test of it. Its guardrails were excellent, which is exactly why it stopped instead of guessing. What was missing sat on the other spans. The case suggests that agreed changes were not being captured reliably in the operative record. A regular review of exception reasons could bring that repeated gap to the people with the authority to change the process. The agent worked. The bridge around it was only half built.
Measure the whole journey
Six months after launch, I would want two views side by side. One tells me whether the agent behaves as intended: what it accepts and what it refers, whether its evidence is right, whether it stays inside its authority, and how all of that shifts with each new version. The other follows the invoice to a lasting outcome: time from receipt to correct payment, rework across teams, legitimate invoices left overdue, improper payments, and the effort spent working exceptions.
The part I would insist on is the conversation between the two. Review the exception reasons regularly with the teams that can change them. When the same missing amendment keeps appearing, record the upstream fix and who owns it, then check in a later month whether that exception actually fell. That loop says more about value than whether the latest model scored a few points higher.
Keeping the two views apart has a cost. Finance can report thousands of invoices handled while procurement spends more time verifying variations and suppliers are still waiting to be paid. Every number can be accurate and the overall story of improvement can still be wrong. It is the same trap I described with containment in the CX Day edition: a figure that records what the system did and says very little about whether the customer, or here the supplier, was actually served. I would track the time and total effort required to pay an invoice correctly, alongside overdue and improper payment rates. A lower processing cost means little if work has merely moved to procurement or the supplier.
The Decode
The best teams already test edge cases, set permissions and build escalation routes. Those disciplines matter, and they still give no guarantee that the process around an agent is ready to benefit from it.
Our invoice agent did what it was designed to do. It spotted the variation, kept the evidence and referred the decision. The repeated referral exposed an approval process that had never been properly connected to the contract record. Giving the agent more access would have hidden that problem. Fixing the process lets the agent and the people around it both do better work.
So when someone asks me who the magician is, this is the answer I look for. There is real craft in the model and in the engineering. There is also craft in defining a decision, keeping its evidence trustworthy, giving people a meaningful role in the exceptions and changing the work when experience shows where it breaks. An accountable owner of the end-to-end outcome has to bring those people together and have a route to act on what they find.
The earlier Decodes examined ownership, reversibility and the place of human judgement. Here those questions meet in one invoice: the agent can be right, the hold can be justified, and the organisation can still have work to redesign.
AI can look like magic in the minute we watch it. Its value is decided in the months afterwards, when nobody is watching the demonstration any more.
CloudDataAI Decode explores the decisions behind cloud, data and AI from a practical business and technology perspective. The invoice scenario is illustrative and is not drawn from a client engagement.