An AI Mission for Purchase Approvals

Most purchase approvals are not decisions. They are signatures collected from people who have no independent information about what they are signing — and the fix is not a faster workflow, it is a better-informed approver.

At twenty past nine in the evening, a director in a mid-sized company opens an email on her phone and finds a requisition waiting for her. The subject line carries a number, the body carries four fields — requester, cost centre, vendor, amount — and a green button sits underneath them. She recognises the requester as someone reasonable and the vendor as a name she has seen before on some other document she cannot presently recall. She does not know whether the company already holds a contract with that vendor, whether the same service was bought by a different team six weeks ago, whether the cost centre has any budget left this quarter, or whether the price on the line is the price the company negotiated or the price the vendor's website quotes to strangers. She approves it, because there is nothing in front of her that would justify doing anything else, and because holding it would mean sending an email asking questions she does not have the standing to research. The whole interaction takes eleven seconds and is recorded, forever, as a control having been exercised.

It is worth being honest about what actually happened there. A signature was collected. No information entered the decision that was not already in the requester's own head, and the requester had every incentive to present the request in the light most favourable to it. The approval did not prevent anything, because prevention requires knowing something that would change the outcome, and the approver knew strictly less about the purchase than the person asking for it. What the approval did accomplish is worth naming plainly: it moved accountability. If the spend later turns out to have been redundant, or out of contract, or over budget, there is now a name on it that is not only the requester's. The control's real output was not a better purchase. It was a distributed blame surface.

An approval is only a control when the approver knows something the requester doesn't

This is the test that almost no approval chain is designed around, and it clarifies an enormous amount once you apply it. An approval adds value in exactly one circumstance: the approver brings information, authority, or judgement to the decision that the requester did not have. A category manager who knows the master services agreement already covers this scope is bringing something. A finance partner who can see that the cost centre has committed ninety percent of its annual budget by month five is bringing something. A security reviewer who knows this vendor has not completed a data processing assessment is bringing something. In each of those cases the approval is a genuine gate, because there is a realistic world in which the answer is no, and the no would be right.

Now look at the typical chain and count how many of its steps meet that test. The requester's manager, who approves because their report asked and the amount is under their limit. The department head, who approves because the manager approved. The finance approver, who checks that the coding is valid and the amount is within threshold — a real check, but a check on the form rather than on the purchase. Somewhere in the sequence there may be one person who could genuinely have caught something, and that person is usually the most senior and the least available, which means their review is the most likely to be a rubber stamp performed between meetings. The chain has length, and length feels like rigour, but most of its links are people confirming that other people approved. Volume is precisely where the theatre concentrates: the small and mid-sized requests, the ones that make up the overwhelming majority of transactions and never individually justify anyone's research time, sail through on nobody's knowledge at all.

The consequence is that organisations end up with two failure modes at once, which is why the usual remedies never work. Add more approvers and you increase cycle time and the number of people whose attention is spread thinner, which makes each individual review less considered rather than more. Remove approvers and you feel like you are loosening a control, even though the control you are loosening was never doing the work you attributed to it. Both moves are adjustments to the length of the chain, and the length of the chain was never the variable that mattered. What mattered was whether anyone in it knew anything.

The information that would change the decision already exists somewhere

The uncomfortable part is that in most companies the knowledge that would make an approval meaningful is not missing. It is simply sitting in systems the approver has no practical way to interrogate at nine-twenty at night on a phone. The contract that already covers this scope is in a contract repository, possibly as a PDF whose terms nobody has extracted. The near-identical order placed by an adjacent team last week is in the purchasing system, findable if you knew to look and knew what to search for. The budget position is in the financial ledger, current as of a close that happened three weeks ago. The negotiated rate is in a pricing schedule attached to an agreement signed by someone who has since changed roles. The vendor's risk status is in a third system entirely, owned by a team the approver has never met. Each fact is retrievable in isolation and none of them are assembled, because assembling them for a routine requisition would cost more time than the requisition is worth to any single human being.

That last clause is the entire economics of the problem. The reason approvals became theatre is not that anyone decided rigour was optional; it is that rigour, at the per-request level, has always cost more than the request appeared to warrant. So the organisation built a control it could afford — a signature — and told itself a story about what the signature meant. What changes the arithmetic is a system that can do the assembly work at the cost of a query rather than the cost of an afternoon: something that reads the incoming request, understands what is being bought rather than merely which fields were filled, goes out across the contract repository, the purchasing history, the ledger, the vendor master and the pricing schedules, and hands the approver a short brief that says what the company already knows about this purchase. Not a recommendation dressed up as a fact — a set of findings, each one traceable back to the record it came from, so the approver can check the claim rather than trust it.

It matters enormously that this is framed as briefing rather than deciding. A great deal of what is currently marketed as autonomous procurement is a routing engine with a new label, and the sceptics have a point; Gartner has predicted that over forty percent of agentic AI projects will be canceled by the end of 2027, citing unclear business value, inadequate risk controls, and "agent washing" — older tools presented as agents without any change in what they can actually do. A system that moves a requisition through a chain faster has automated the theatre. A system that arrives at the approver's screen with the contract reference, the duplicate order, and the budget position has changed what the approval is.

Segregation of duties is the reason to build it this way, not an obstacle to it

There is an obvious and wrong next step from here, which is to let the software approve the small stuff so humans only see the large stuff. That inverts the whole argument. The reason a purchase approval carries weight is that an accountable person with delegated authority put their name to a commitment of the company's money, and that accountability is not a formality to be optimised away — it is the substance of the control, the thing auditors test, and the reason segregation of duties exists in the first place. The person who requests cannot be the person who approves, and neither can be a piece of software acting on its own recognisance. Committing spend is an act of authority, and authority belongs to someone who can be held to it.

What the software can legitimately own is everything on the near side of that line: understanding the request, retrieving the evidence, reconciling it, flagging the conflict, and putting a decision in front of the right human with the reasons visible. This is the shape that platforms built for the pattern tend to take — in StudioX's terms, an AI Mission that runs across procurement's systems as a set of specialist agents with a reasoning core coordinating them, drawing on enterprise knowledge and connecting through MCP to the contract, purchasing and finance systems, with human-in-the-loop authority preserved at the point where money is actually committed. It is the same principle the broader literature on the autonomous enterprise keeps returning to: autonomy in the preparation, human authority at the commitment. The agents do not get an approval limit. They make the approval limit mean something.

The reframing worth carrying away is a change in what you measure. Approval systems are almost universally assessed on throughput — cycle time, requests processed, percentage approved within the service level — which is a set of metrics that a chain of eleven-second rubber stamps optimises beautifully. The better question is what proportion of your approvals were informed: how often the approver was shown something they did not already know, and how often that something changed the outcome. Run that number honestly and most organisations will find it uncomfortably close to zero, which is not an indictment of their people but of what they were given to work with. Fix the briefing and the same chain, the same people, and the same eleven seconds start doing the job the org chart always claimed they were doing.