Past the pilot, into production.
Most AI programmes stall in the same place. The demonstration works, everybody is impressed, and then it cannot go live because nobody can answer what it is allowed to do, what it did last Tuesday, and who is accountable when it is wrong. This programme starts from those three questions.
Agents hold a role·Limits before autonomy·Every step on the audit trail
Where AI programmes get stuck.
The blocker is almost never the model. It is that the work an agent would do sits across systems, with no permission model, no audit trail, and no named owner for the outcome.
The demo cannot be grounded
It answers well on a curated extract and badly on live data, because the live data is in four systems with different keys.
Nobody will sign off autonomy
There is no way to say what the agent may and may not do, so the answer defaults to nothing.
You cannot audit a decision
When it gets one wrong, there is no trail showing what it read, what it decided, and what limit let it act.
It never leaves the sandbox
Twelve months of pilots, real enthusiasm, and no process that runs differently on a Monday morning.
How the programme runs.
Deliberately the reverse of the usual order: the limits and the audit trail are built before any autonomy is granted, because they are what makes granting it possible.
- 01Weeks 1–3
Ground
Before an agent does anything, it has to be able to read your records correctly with your permissions applied. That is a data and permission problem, and it is solved first.
What exists at the end of it
- Records reachable with row-level permissions enforced
- Retrieval that names the documents behind every answer
- Gaps in master data identified and a plan to close them
- A grounded question-answering surface your team can test
- 02Weeks 3–5
Scope the roles
An agent is defined the way a job is defined — what it is responsible for, what it may touch, what it may spend, and who it escalates to. Written down and agreed before anything is switched on.
What exists at the end of it
- Named agent roles with explicit tool permissions
- Value and action limits per agent, period, and document type
- Escalation paths with named human owners
- Segregation of duties written as rules, not conventions
- 03One period
Run in proposal mode
Every agent runs for a full period proposing rather than acting. You get the accuracy figure from your own data before autonomy is a question, not from a vendor benchmark.
What exists at the end of it
- Proposal-versus-decision accuracy measured on your records
- The exception cases characterised rather than averaged
- Thresholds tuned to your own tolerance for being wrong
- A documented case for what should act and what should not
- 04Per agent, per limit
Grant autonomy, narrowly
Autonomy is granted one action and one ceiling at a time, on the evidence from proposal mode. Anything above the ceiling still routes to a person, with the reasoning attached.
What exists at the end of it
- Named actions permitted within named limits
- Human approval gates above every ceiling
- Full reasoning log on the document each agent touched
- A review cadence for raising or lowering each limit
Where agents go first, and why.
Ordered by how cheaply a mistake can be caught. High-volume, rule-shaped, easily-checked work comes first; anything that commits money or touches a person's pay comes last, if at all.
Reading and matching
Document capture, coding, and three-way matching. High volume, mechanically checkable, and wrong in ways a person spots in seconds.
Watching and chasing
Shortages, overdue lines, expiring batches, unbilled deliveries, breached SLAs. The agent notices and prompts; a person still decides.
Preparing and drafting
Reconciliation proposals, close checklists, quotations, briefings, and replies drawn from live records — offered to a person rather than sent.
Acting within limits
Only where proposal mode earned it: raising the request, posting the match, releasing the routine document — always under a ceiling, never approving its own work.
What makes this auditable rather than impressive.
Each of these exists so that a finance director, an auditor, or a regulator can be shown something rather than reassured.
- A written role per agent
- What it is responsible for, what it may read, what it may do, and what it may spend — the same document you would write for a person.
- Explicit tool permissions
- A named list of actions per agent. Matching an invoice does not imply paying one, and the system enforces the distinction.
- Value and action ceilings
- Hard limits per agent, per period, and per document type, which cannot be crossed however the agent is asked.
- Segregation of duties
- An agent cannot approve what it raised. The rule that applies to your people applies to your agents.
- A full reasoning log
- Every step written to the audit trail on the document it touched, readable months later without a specialist.
- Accuracy measured on your data
- From a full period in proposal mode, on your own records — not a benchmark from somebody else's.
The terms this programme runs on
- Grounding
- Live records with your permissions, never a snapshot
- Order
- Limits and audit trail built before any autonomy
- Evidence
- A full period in proposal mode before an agent acts
- Ceilings
- Per agent, per period, per document type
- Segregation
- No agent approves what it raised
- Reversibility
- Any agent can be returned to proposal mode immediately
What this programme is usually pointed at first.
Next step