Every major enterprise resource planning vendor is now using the word agentic, and the demonstrations have a common shape: the system notices a shortage, drafts a purchase order, checks it against a contract, routes it for approval and follows up when nobody responds. It is impressive, and it is being presented as a capability you procure rather than a control problem you inherit. The question this year is not whether systems can initiate transactions. They can. The question is what you have to put in place before letting them.
A system that records decisions needs accurate data. A system that makes them needs accurate data, defined authority, and somebody who can explain in writing why it was allowed to act
Most organisations have the first. Very few have the third, and that is the actual constraint on deployment.
The four rungs, and where the line sits
It helps to be precise about what "agentic" means in a given product, because vendors use the term across a very wide range. Observe. The system detects a condition and tells someone. This is a rules engine with better language, and it is safe. Draft. It prepares the transaction and a person commits it. This captures most of the available productivity gain and almost none of the risk. Act within limits. It executes inside a defined envelope — value thresholds, approved vendors, standard terms — and escalates outside it. This is where real operating leverage starts. Act and reconcile. It executes, handles the consequences, and reports after the fact. Very few organisations should be here this year, and those that should are running high-volume, low-value, highly standardised flows. Most of the value sits at the second and third rungs. Most of the marketing is about the fourth.
| Level | System role | Control boundary |
|---|---|---|
| Observe | Detect and notify | A person decides |
| Draft | Prepare the transaction | A person commits |
| Act within limits | Execute inside an approved envelope | Stop and escalate outside limits |
| Act and reconcile | Execute and handle consequences | Review actions, exceptions and rollback evidence |
Qualitative summary of this article's source text, not a measured outcome or performance estimate.
Authority is the part nobody has documented
Your delegation of authority matrix names people and amounts. It does not contemplate a system as a delegate, and in most organisations it cannot: the underlying policy assumes a human who can be held accountable, who has a line manager, and who can be asked what they were thinking. Before any system acts, someone has to answer four questions in writing. Under whose authority does it act — which named person's delegation is it exercising? What are the limits, expressed in the same units as your existing authority matrix? What does it do when it encounters something outside those limits, and does it stop or guess? And who reviews its actions, how often, and against what sample? If those four answers do not exist, the correct deployment is the draft rung, regardless of what the software can do.
Controls change shape, not quantity
A human process is controlled by checking steps. An automated process cannot be controlled that way, because the volume defeats the checking. What replaces it is a different set: preventive limits enforced by the system, a sample of decisions reviewed for quality rather than every decision reviewed for existence, monitoring of the exception rate as a leading indicator, and a rollback path that has been tested rather than described. Your external auditor will ask about these, and the conversation goes better when you raise it first.
Where to start, honestly
Pick a process that is high volume, low value per item, well understood, and reversible. Payment matching, routine replenishment within contracted terms, standard dunning, recurring journal preparation. Avoid anything touching customer pricing, credit decisions, employment or anything a regulator would want to inspect. Run it at the draft rung for a quarter and measure the override rate. If people are changing more than a small fraction of what the system proposes, you are not ready to move up a rung — and you have learned that cheaply.
Practical Guidance for Agentic ERP Readiness Assessment
- Classify each proposed use against the four rungs explicitly.
- Extend your delegation of authority to cover systems as delegates.
- Express limits in the same units as your existing thresholds.
- Define the escalation behaviour — stop, never guess.
- Measure override rate before promoting anything a rung.
- Replace step checking with sampling and monitor exception rates.
- Test the rollback path rather than documenting it.
- Brief your auditor early, before they find it in walkthrough.
The Regional Angle
The first obstacle here is that authority in regional groups is frequently personal rather than procedural. Approval limits exist on paper, and in practice a great deal is settled by a director's verbal agreement, a message on a phone, or the simple fact that everyone knows which transactions require the chairman's nod regardless of what the matrix says. Automation is unforgiving of that arrangement: a system cannot exercise an authority that was never written down, and attempts to encode the real approval behaviour produce either a rule so loose it controls nothing or an escalation path that routes half the transactions to one person. Getting the authority structure actually documented is the prerequisite, and it is a governance project with a political dimension rather than a configuration task. Start it before the software arrives. The second concerns the supplier base these systems will be transacting with. Autonomous procurement assumes contracted terms, catalogued items, stable pricing and suppliers who transact electronically. A substantial share of regional purchasing runs on negotiated relationships, quotations obtained per order, prices that move with currency and shipping conditions, and suppliers who confirm by messaging rather than through a portal. A system acting inside that environment will either escalate constantly or commit you to terms nobody agreed. The practical sequence is to build a genuine contracted catalogue for the repeatable portion of spend first — typically consumables, maintenance items and standard services — automate only that, and leave the negotiated tail with the buyers who are good at it. The third is about how this will be read outside the business. Regional banks, auditors and regulators are still developing their positions on system-initiated transactions, and the immediate consequence is that an organisation deploying autonomous payment or procurement steps ahead of its auditor's understanding will spend the year explaining rather than operating. Two things help disproportionately: keep the human-authorised control point at the payment release rather than at the transaction creation, and produce an evidence pack — the authority document, the limits, the sampling results, the exception log — before anyone asks. Organisations that do this find the conversation is short. Organisations that do not find that the first audit becomes a scope expansion.
The objection worth taking seriously
The strongest objection is that this governance apparatus is disproportionate to systems that are, in practice, doing bookkeeping. A rules engine has been raising replenishment orders automatically for twenty years and nobody wrote a delegation of authority for it. Wrapping the same functionality in a model and then demanding an authority framework, a sampling regime and an auditor briefing is compliance expanding to fill the available anxiety, and the organisations that do it will spend a year on paperwork while their competitors simply switch the feature on. The comparison is fair and the historical point is correct. Deterministic automation has operated for decades without this ceremony. The difference is not the volume or the value of what is being decided; it is that the rules engine's behaviour was fully specified in advance and this is not. A reorder rule does the same thing in the same circumstances forever, and when it is wrong it is wrong predictably and visibly. A model-driven agent generalises to circumstances nobody enumerated, which is precisely the property that makes it useful and precisely why you cannot rely on inspection to know what it will do. The governance is not about the transaction's size. It is about the fact that you cannot fully enumerate its behaviour in advance, which means you need limits at the boundary and sampling after the fact instead. That is a smaller amount of work than a compliance programme and a larger amount than nothing.
Common Questions
Can we just cap it by value?
Value limits are necessary and insufficient. A sequence of small transactions can produce a large exposure, so cap frequency and aggregate as well as individual amounts.
Who is accountable when it gets something wrong?
The named person whose authority it exercises. If you cannot identify that person, you are not ready to let it act.
Do we need a separate log?
You need one that records what the system saw, what it decided, and what limit permitted the action. Most transaction logs record only the third of those.
What should we expect over the next twelve months?
Expect every major vendor to ship agentic modules and to price them separately. Expect the first public failures to involve authority rather than accuracy — a system doing something correctly that nobody had authorised. Expect audit firms to publish guidance late in the year. And expect the organisations that spent this quarter documenting delegation to be the ones deploying by the fourth.
Agentic ERP Readiness Assessment — we establish the authority and control structure first, because the software is the easy part.