ARPDefinition

The definition, clause by clause

One sentence, six clauses, and the thing each clause is there to rule out. A definition that excludes nothing describes the market, not a category inside it.

Six clausesSeven resource classesReviewed September 2026

Autonomous Resource Planning is an architecture in which the system that holds the state of an enterprise's resources is also the system that decides and acts on them. It observes resource state and external signals continuously, forms plans against stated objectives and constraints, executes actions within explicitly granted authority, records the consequence in the same ledger it read from, confirms the intended outcome occurred, and escalates what falls outside its authority or its confidence.

The sentence is written to be failed. Each clause below carries one exclusion, and a system that meets five of the six is a system that meets five of the six. The point of stating it this way is that the clauses can be checked one at a time against something somebody can demonstrate, instead of agreed to in general and applied to nothing.

Clause by clause

The order is the order of the sentence, which is also the order of the loop it describes. What each clause rules out is the part that has to hold.

Clause 1

Holds the state and decides on it

the system that holds the state of an enterprise's resources is also the system that decides and acts on them

What it excludes

The two-system arrangement, in which a planning or decision layer sits beside the record and hands its conclusions across a boundary to the system that holds the position.

Every enterprise architecture of the last thirty years has had a decision layer beside the record: a planning engine, a data warehouse, a rules engine, a set of models. Each of them reads a copy and writes a recommendation, and each of them is separated from the position it reasons about by an interval nobody owns.

The separation is where the losses are. The decider reasons about a position that has already moved, the write back is an integration with its own failure modes and its own queue, and when the outcome is questioned afterwards there are two records of what was true and no way to say which one the decision was taken against. A system that holds the state and decides on it has no such interval to lose anything in, which is the single structural claim this definition makes.

Clause 2

Observes continuously

observes resource state and external signals continuously

What it excludes

The scheduled run and the opened screen. Also the system that watches only its own tables, since the clause asks for external signals as well as resource state.

The hardest judgement in resource planning is not what to decide but when the decision was needed, and a system that waits to be started has left that judgement with whoever started it. A nightly run fixes the worst case staleness of every plan it produces at the length of the interval, whatever the quality of the planning inside it.

External signals are named because the alternative is a system that is perfectly consistent with itself and wrong about the world. A shipment that will not arrive, a rate that moved, a customer that stopped paying: none of these are in the ledger at the moment they become true, and a system that cannot see them cannot begin the work at the moment the work became necessary.

Clause 3

Plans against stated objectives and constraints

forms plans against stated objectives and constraints

What it excludes

The implicit objective. A system whose goals live inside a model, a prompt, or the intentions of whoever configured it has objectives, but none that can be stated, compared or contested.

Stated is the working word. An objective that is written down can be argued with before the system acts on it, weighed against another objective when the two conflict, and used afterwards to say whether a decision was wrong and not merely unpopular. An objective that is implicit can only be inferred from behaviour, which means it is discovered through the decisions it already produced.

The clause also rules out automation that follows a rule without trading anything off. Routing every invoice under a threshold to automatic payment is a constraint with no objective behind it, and the system executing it is not planning: it has been handed the conclusion of somebody else’s plan. Planning begins where two stated objectives pull against each other and the system has to spend one to serve the other.

Clause 4

Executes within explicitly granted authority

executes actions within explicitly granted authority

What it excludes

Both ends at once: the system with no stated bounds, and the system whose bounds are described but never enumerated. Configurable is not a grant, and neither is a permission set written for human users and inherited by software.

Explicitly is doing the work, and it means the grants can be printed: which action types, up to what value, under which conditions, granted by whom, on what date, and revocable. A bound that cannot be produced as a document cannot be audited, cannot be narrowed after an incident, and cannot be insured, which in practice means the system will not be allowed near anything expensive.

This is also the clause that makes autonomy a governance question before it is a capability question. The interesting number about an autonomous system is not what it can do but what it was permitted to do, and those two are the same number only in systems where somebody wrote the permission down first.

Clause 5

Records the consequence in the same ledger it read from

records the consequence in the same ledger it read from

What it excludes

The draft, the approval queue, the staging table and the recommendation. Anything a person has to transcribe, release or accept before the world changes.

The clause names the same ledger deliberately. An action that lands somewhere other than the store the system reads from has not closed anything: the next observation still sees the old position, the reconciliation is between two systems instead of against the world, and the person who moves the record between them is carrying the result. That person is the part of the loop being claimed as automated.

The definition adds one more demand beside it, that the system confirms the intended outcome occurred. Acting and recording are assertions about intent. Confirmation is the point at which the system stops reporting its own intentions and starts reporting what the world did, and a system whose last belief about an action is its own instruction has no basis for saying it owns the outcome.

Clause 6

Escalates what falls outside authority or confidence

escalates what falls outside its authority or its confidence

What it excludes

The system that proceeds past its bounds and flags the result afterwards, the system that stops without saying what it knew, and the system that routes everything to a person, which is review wearing the word escalation.

Bounded authority is worth exactly what happens at the boundary. A system that crosses it has no boundary, and a system that stops and hands over a bare exception has moved the work to a person without moving any of the context that made the work tractable. The handover is the mechanism, not the stopping.

Confidence sits beside authority in the clause because the two failures look identical from outside and have different remedies. Outside authority is a governance fact, fixed by granting more or accepting less. Below confidence is an epistemic fact, fixed by better evidence or by a person who has some. A system that cannot tell the reader which of the two stopped it has not really stopped for a reason.

The seven resource classes

The definition says resources, and the word is only useful once it is enumerated. A resource planning system is built class by class and it fails class by class, so a claim made about a whole system is nearly always a claim about its best class. Six of the seven have been planned by software since the 1960s. The seventh arrives with the autonomy itself.

Resource class

Money

cash, receivables, payables, the ledger, the close, treasury

The class with the longest history of automation and the shortest history of autonomy: the record has been computerised since the 1960s, while the judgement it encodes has not.

Resource class

Materials

inventory, procurement, suppliers, logistics

Where resource planning began. MRP answered what to buy and when, and every later era inherited its vocabulary.

Resource class

People

labour, roles, assignment, scheduling, workforce planning

The class where bounded authority matters most, because the consequences of a wrong allocation are borne by a person rather than absorbed by a balance.

Resource class

Capacity

equipment, facilities, production capacity, throughput

Planned in detail by MRP II and, in most companies, still planned by spreadsheet in practice. Typically the lowest scoring class in any honest assessment.

Resource class

Time

lead times, commitments, calendars, sequencing

Rarely modelled as a resource, though every promise a company makes spends it. Treating it as one is what turns a schedule into a plan.

Resource class

Information

master data, documents, contracts, the enterprise record itself

Both a resource and the medium every other class is planned in. Autonomy degrades exactly as fast as this class does.

New class

Agents

compute, licences, permissions, authority budgets, escalation capacity

New. Once software holds authority, that authority is finite, costed and allocable, with its own utilisation, its own concentration risk and its own segregation of duties. An autonomous system has to plan the thing doing the planning.

The argument for the seventh class is short and it is structural. Every previous era of resource planning assumed that authority was held by people and that software spent it on their instruction. Nothing in those models needed a line for authority itself, because authority was an attribute of the staff list. Once a system decides inside bounds somebody granted it, that assumption stops holding and the grants become a stock with all the properties of one.

Authority is finite, because somebody has to be willing to answer for the total of it. It is costed, because compute, licences and the human capacity to absorb escalations are all bought. It is allocable, because raising the payment ceiling in one function is a decision not to raise it in another. It has utilisation, which is the fraction of granted authority actually exercised, and a grant sitting unused is a governance liability and not a spare. It has concentration risk, because authority pooled in one decision path fails all at once. And it has segregation of duties, which is the hard one: the control that keeps the person who raises a payment separate from the person who releases it has to survive both being the same software.

So an autonomous system has to plan the thing doing the planning. That is the one structural addition this category makes to a model that has otherwise held since manufacturing resource planning, and it is the reason the class is listed beside money and materials instead of being treated as a matter of configuration.

The classes are also the unit the maturity model grades on. A company reaches a level in a class, never in general, and the distance between its best class and its worst is usually the whole answer to what to do next.

What this is not

Six shapes come close enough to be read as this, and each one fails a single clause. They are described as shapes and not named as products, because each shape is held by several systems and the argument is about the architecture, not about anyone selling it. Five of the six are useful things that work. Being useful is not the test.

A system of record with a chat interface

The record is unchanged. A conversational surface sits on top of it, answers questions about what it holds, and in the better versions carries out instructions a person gives in words instead of in fields.

Fails observes resource state and external signals continuously

It fails on when. The work begins when somebody types, so the judgement about whether this needed deciding today stayed exactly where it was, and the improvement is in the cost of asking, not in the cost of not knowing to ask. This is a genuine improvement in an interface, and the interface was never the part of enterprise software that carried the judgement.

A system of record with drafting assistance

The system prepares the entry, the order, the reply or the reconciliation, and presents it to a person who checks it and commits it. Accuracy is often high and the time saved is real.

Fails records the consequence in the same ledger it read from

It fails on where the action lands. Nothing changes in the ledger until a person accepts it, which means the throughput of the system is bounded by the attention available to review it, and the review is the expensive part. A drafting system that is right ninety-nine times in a hundred still requires a hundred reviews, because nobody knows in advance which one is the exception.

A system of record with a language model reading its data

The model has access to the enterprise record and can summarise it, explain an anomaly in it, answer a question about it and write about what it found, with the record itself untouched.

Fails the system that holds the state of an enterprise's resources is also the system that decides and acts on them

It fails on decides and acts. Reading is the interpret stage of the loop, and interpretation has been improving continuously since the first reporting suites without ever crossing into decision. The reader is still the decider, and a better explanation delivered to the same decider is a better report.

Workflow automation

A path is drawn in advance: when this happens, do that, then route it there, and if the value exceeds this figure, send it to that person. The path executes reliably, at scale, without anybody present.

Fails forms plans against stated objectives and constraints

It fails on planning. The decision was taken when the flow was drawn, and the running system is the record of a decision and not the maker of one. That is why workflow degrades in exactly the way it does: the world moves, the drawn path does not, and the gap is absorbed by people who work around the flow instead of through it. A planner trades objectives at the moment of the decision, which is the one thing a fixed path cannot do.

Robotic process automation driven by a model

Software operates the interfaces a person would operate, signing in as a user, reading the screens and keying the entries, with a model choosing what to do next instead of a recorded script.

Fails executes actions within explicitly granted authority

It fails on granted authority. Its authority is a login. Whatever that account can reach, the automation can reach, because the permissions were written for a person whose judgement was assumed to be the real control. Nothing about this is enumerable: there is no list of action types, no value ceiling, no grantor and no revocation date, only a user whose capabilities were never meant to be exercised at machine speed. Adding a model to it makes the range of what it might do larger and the list of what it may do no clearer.

Generated dashboards and analytics

The system detects what moved, assembles the view, writes the commentary and puts the exceptions in front of whoever opens it, without anybody building the report.

Fails escalates what falls outside its authority or its confidence

It fails on escalation, which in this definition is an act and not a display. Escalation has a named recipient, a reason for stopping, the evidence attached, and a resolution somebody is tracking. A generated surface has none of those: it presents everything it found at one level of urgency and leaves the triage to the reader, which is the work that was supposed to be moving. There is also nothing for anything to fall outside of, because a system with no authority has no boundary and a system that takes no action has no confidence threshold to fail.

The falsifiable form

A definition is only as good as the test that applies it, and every clause above can be agreed to in a meeting without changing anybody’s mind about anything. The eight questions of the ARP test are the same six clauses put as questions about a system somebody can demonstrate, with the answer that sounds like a pass written beside each one. Three of the eight decide the outcome. Read the definition here and settle it there.

Six clauses are an argument. Eight questions are a test.

The ARP test