Stop buying AI. Start buying the approval queue.

Almost every AI purchase decision is framed around the wrong object. Which model. Which vendor. Which benchmark. Meanwhile the thing that determines whether the project survives contact with your operations team is barely discussed: what happens between the model deciding something and your systems changing.

That gap is the product. Everything else is a dependency you will swap out twice in three years anyway.

Why the model is the least durable part of your investment

Models improve on somebody else's roadmap and budget. The one you deploy this quarter will be outclassed by something cheaper within a year, and if your system is built properly, swapping it will be a config change and a re-run of your evaluation set.

What does not commoditise:

• Your action taxonomy — the actual list of things that can be done, typed and validated
• Your policy layer — what requires approval, from whom, under what conditions
• Your evidence and citation plumbing
• Your review interface, and how fast a human can clear a decision in it
• Your ledger — the record that lets you answer questions in a year's time
• Your measured accuracy per action type, which is the asset that lets you safely increase autonomy

Every one of those is specific to your business, none of them come in a box, and together they are what makes AI deployable rather than demonstrable.

The architectural commitment that makes it possible

One rule, and everything else falls out of it: the model never calls your API.

It emits a proposal — a typed, validated, reversible object describing exactly what would change, with the evidence attached and a declared way to undo it. A separate execution layer holds the credentials, checks the proposal against policy, and decides whether to run it now, queue it, or refuse it.

model  →  proposal  →  [ policy + trust level ]  →  execute | queue | refuse
                                          ↓
                                    append to ledger

Three things you get for free from that shape, all of which are otherwise very hard:

Prompt injection stops being existential. A malicious instruction in a customer email can, at worst, produce a proposal that fails validation or gets rejected by a human. It cannot reach your database, because the thing that talks to your database does not read customer email.

Everything is reversible by construction. The reverse operation is declared alongside the action. You do not need to invent a rollback story during an incident at 2am.

Autonomy becomes a dial, not a decision. Because the execution layer already checks a trust level before running anything, raising autonomy for one action type is a configuration change backed by measured data — not a rewrite, and not a leap of faith.

Build the review interface like it is a product

Most approval workflows die because reviewing is slower than doing the task yourself. If that is true, your team will — correctly — route around it.

So the queue gets treated as a first-class product surface. Keyboard-first. One decision per screen. The diff against current state and the cited evidence visible without scrolling. Bulk approve for runs of identical low-risk items. And rejections captured with a reason from a fixed taxonomy, in one keystroke.

That last point is where most of the long-term value hides. A queue that records only yes and no is discarding the highest-quality training signal in the entire company. "Wrong policy" and "right action, wrong amount" are different failures demanding different fixes, and you only learn that if somebody built the button.

What to ask a vendor

Not "which model do you use". Ask:

1. Show me the proposal object for a real action. What is in it?
2. Where do the credentials live — can the model reach my systems directly?
3. Show me the review screen. How many keystrokes to approve? To reject with a reason?
4. What is in the ledger, and can I export it for an auditor?
5. How does an action type get more autonomy, and who decides?
6. How do I revoke it in one click, for one action type, at 3pm on a Friday?

If the answers are vague, you are buying a demo. If they are concrete, you are buying a system — and the model inside it is a detail you will change twice and barely notice.