Every failed AI programme we get called in to rescue failed the same way: someone had to choose between a model that could not act and a model nobody could supervise. The whole method below exists to remove that choice.
Week one is not a model. It is a stopwatch. We sample real volume — tickets, calls, documents, pull requests — and classify it into action types: not "billing questions", but "issue refund under $100 on a late delivery". A good action type is one you can write a rule for and count the exceptions to.
Out of that comes a ranked list with two numbers per row: annual hours consumed, and blast radius if the AI gets it wrong. We automate down the first column and up the second. The first automation is almost never the most interesting one; it is the highest-volume action that is trivially reversible.
An agent that answers from the model's own memory will invent your refund policy. Everything we build answers from your material — help centre, resolved tickets, policy PDFs, product data, the ERP itself — and carries the citation through to the reviewer's screen.
Just as important: it is allowed to say no. Abstention is a first-class outcome, triggered by low retrieval confidence, contradictory sources, contract or legal language, detected anger, or simply an action type it has not been authorised for. An agent that abstains 8% of the time and is right the rest is worth vastly more than one that always answers and is right 92%.
This is the architectural commitment that makes the rest possible. The agent never calls your billing API. It emits a proposed action: a typed, validated, reversible object describing exactly what would change, rendered as a diff a human can read in two seconds.
{
"type": "refund.issue",
"target": {"order": "48812", "customer": "c_7741"},
"change": {"amount_cents": 8400, "reason": "delivery_late"},
"evidence": ["ticket:99312", "policy:refunds#under-100", "shipment:1Z...:delivered+6d"],
"confidence": 0.97,
"reversible": true,
"reverse_with": "refund.void",
"requires": "level>=3 OR approval"
}An execution layer — not the model — validates that object against policy, checks the current trust level for that action type, and either runs it or parks it in the queue. The model has no credentials. It cannot reach your systems even if it is compromised or prompt-injected, because the only thing it can produce is a proposal that something else decides to run.
Most approval workflows fail because reviewing is slower than just doing the task. So the queue is built like a product: keyboard-first, one decision per screen, the diff and the evidence side by side, bulk approve for a run of identical low-risk items, and a rejection captures why in one click from a fixed taxonomy. Rejections are the training data. A queue that only records yes and no is throwing away the most valuable signal in the building.
The trust ladder is agreed with you before launch and written into the SOW, so nobody is arguing about it later:
| Level | Behaviour | Gate to reach it |
|---|---|---|
| 0 — Shadow | Proposes, executes nothing | Day one |
| 1 — Draft | Pre-fills, human sends | 2 weeks shadow, disagreements reviewed |
| 2 — Queue | Full action, held for approval | ≥80% of drafts sent with minor or no edit |
| 3 — Auto+recall | Executes, reversible on a window | ≥98% approval over ≥200 decisions |
| 4 — Autonomous | Executes, sampled audit only | <0.5% recall over a full month |
Levels are per action type, never global. It is completely normal — and correct — for "send tracking information" to sit at level 4 while "cancel a contract" never leaves level 2. Demotion is automatic: a spike in rejections or recalls drops an action type a rung and pages a human. Nobody has to notice.
Every proposal, every approval, every rejection, every execution and every reversal is appended to a hash-chained log with the evidence attached. It answers, months later and without archaeology: what did the system do to this customer, on what basis, and who allowed it. That log is what makes an operations director, a compliance officer and an auditor willing to say yes — and it is the thing almost no AI vendor ships.
The engagement ends with your team running it. That means the runbook is written for your staff, the workflows are in a tool they can edit, the prompts and policies are in your repo under review, and we have sat with your people while they changed something and shipped it. If a system only we can maintain, we have sold you a dependency, not a transformation.