A live model of markets, prices, supply, demand, supplier performance and risk is the correct foundation for autonomous procurement. The question nobody is asking is who decided what belongs in it — and in 1998 the answer to that question was worth forty-six percentage points of delivery performance.
Jon Hansen | Procurement Insights | August 2026
Romain Rousseau, with Sarah Pohle and Alexandra Lovin, published a piece this week called Reinventing Procurement for the Autonomous Enterprise. It is the most serious argument for agentic procurement I have read, and it deserves engagement rather than the reflexive skepticism this category usually gets from people who have been around as long as I have.
His case, compressed: procurement exists because intelligence was scarce and expensive, and most of what procurement does is scaffolding built to ration that scarcity. Collapse the cost of intelligence and the scaffolding loses its purpose. What survives is not the workflow but the intent behind it. In place of process towers he proposes a Procurement Operating System in five layers — Economic Intelligence, Policy, Agents, Orchestration, Execution — with procurement’s durable claim on the top two.
I think the architecture is right. I think one question sits upstream of it, unasked, and that everything depends on the answer.
Where we already agree, and it is not a small thing
In his seventh section he writes that if procurement builds autonomous sourcing without connection to finance, legal, risk, supply chain and business planning, it will create a faster silo — not transformation but accelerated fragmentation.
That is the whole of my concern about agentic deployment, stated by someone arguing in favour of it. I have been making a version of that point for nineteen years and I have rarely seen it put more precisely by a proponent.
He also names the thing most analyses dodge — that a role which becomes more strategic and concentrates on the highest-value work is, by definition, a role you need fewer of, and that an analysis unwilling to say so is a brochure. That is an honest sentence in a genre that does not reward honesty.
So this is not a disagreement about direction. It is a disagreement about sequence.
The question upstream
The Economic Intelligence Layer is described as a continuous, live model of markets, prices, supply, demand, supplier performance, contractual obligations and risk. The system’s senses.
Here is the question: how was it determined what belongs in it?
Not how is it maintained, or how current it is kept, or how many sources feed it. Who decided what the model contains — and against what were they checking?
Because a live model of the wrong variables is a live model of the wrong variables. It will be beautifully current, continuously refreshed, and still missing the variable determining the outcome — for the same reason no designed map contains its own obstacle: if anyone had known the variable belonged in the model, it would already be in there.
A question I asked in January 2025, still unanswered
I put this to a group of practitioners in a public exchange eighteen months ago, and I will put it here again:
Tell me how Agentic AI would have known to ask, “What time of day do orders come in?”
Nobody answered it at the level it was asked. The best response I received described what a well-designed agent would do — recognize the timing pattern, identify the missing variable, generate the inquiry before an analyst considered it. All plausible, and all of it presupposing that time-of-day is already a variable the system tracks and treats as causally interesting.
Nothing in the declared problem says it is.
The declared problem in 1998 was a national defence maintenance operation delivering next-day parts on 51 percent of the time against a 90 percent contractual requirement. The declared map was four boxes: order received, supplier sourced, parts ship, next-day delivery. Give an agent that map and every data source attached to it, and it will optimize it superbly — faster supplier selection, better delivery probability, dynamic sourcing strategy, automated negotiation.
It will produce a faster 51 percent.
Ask what time of day the orders arrive and you get 4 PM. Ask why 4 PM and you leave procurement entirely — into a service department nobody had put on the procurement map, where technicians were holding parts orders to the end of the day because they were rated on calls responded to. That finding changes what you need to look at back inside procurement. Which sends you out again to the suppliers, then the couriers, then the border, and finally into finance — where the cost of the part and the cost of the freight sat as two separate line items, each correct, each reconciling cleanly, with the loss living only in the relationship between them and nobody looking at the two lines together.
Four departmental crossings. Delivery moved above 97 percent within three months, before any new technology entered the building. The technology came afterward, onto a substrate that had finally been made real — and it was the technology, applied to aligned conditions, that sustained the result across seven consecutive years.
Now write the specification for the Economic Intelligence Layer that would have contained all of that.
Technician call-response incentives. Order submission timing. Buyer queue-clearing behaviour. Cross-border competence of the supplier base. Courier fragmentation. Customs clearance probability. The relationship between two accounting line items and a contract markup formula. And whether the commodity in question moves on dynamic flux pricing or sits on a historical flat line — because a part that costs one hundred dollars at nine in the morning does not cost one hundred dollars at four in the afternoon.
Nobody would have specified it, and not through carelessness. They did not know those things formed a system. The failure is what revealed that they did.
Two stacks, running in opposite directions
The clearest way to see the difference is to put them side by side.
Outcome → follow actual causality → cross declared boundaries → discover relationships nobody had declared → validate operating reality → then determine intelligence, policy, agents and execution
These are not competing architectures. The second is the epistemic layer the first assumes it already has.
Every downward stack begins by taking the model of reality as given. That is not a flaw in the design — it is a dependency, and it is invisible precisely because it sits above the top layer. Ask where the contents of the intelligence layer came from and you are asking a question the diagram does not have a box for.
Orchestration is not discovery
The obvious objection is that Rousseau anticipates this. His endpoint is the autonomous enterprise — agents talking to agents across functional boundaries that are today defended by org charts, budget lines and system ownership. If agents span procurement, finance, supply chain and operations, surely the crossing happens.
Orchestration coordinates declared interfaces. It cannot cross an undeclared one.
The technicians’ calls-per-day rating was not an interface. It was an internal performance measure inside a department with no relationship to procurement on any diagram. The two finance line items were not an interface — they were two correctly maintained fields whose relationship was the finding, and a relationship nobody has named has no endpoint for an agent to address.
The claim is not that such a relationship can never be found — a system with broad enough observational reach might surface a statistical correlation nobody asked for. It is that nothing in the architecture gives it a reason to look, or tells it which of a million undeclared correlations is the one that matters. Naming the coupling is prior work, and nothing in the stack does it.
What actually fires
There is a temptation to call the tracing discipline the solution — start from the failure, refuse to assume the cause sits inside the declared process, follow it wherever it goes.
That is a method, and by my own definition a method is a guardrail. It has to be remembered, recognized as applying to the case in front of you, and preferred over the faster forward map. Each of those fails silently, and the last one fails most often, because the forward map is quicker and looks more professional.
The fence is the failure signal.
A contractual requirement standing against actual delivery is structural. It fires whether or not anyone remembers a methodology, it does not depend on anyone’s attention, and it cannot be argued out of existence. A delivery rate stuck at 51 percent against a 90 percent requirement is what that fence emits, and it is the one signal in the entire system guaranteed not to have been designed.
Which is why a known failure is the most reliable place to start. Not because tracing is a superior discipline, but because the failure is the only thing in the operation that already knows the model is incomplete.
Four waves, and the fourth is where we part
Rousseau closes on four waves: transactions digitized, workflows automated, intelligence introduced, and then a fourth that removes procurement as an execution function altogether — making the process invisible and reassigning the human to intelligence, policy and judgment. Most of the market, he argues, is living in the third wave and mistaking it for the destination.
I have my own four, and I published them in March: ERP, e-Procurement, SaaS/Cloud, and now AI. Four consecutive technology eras.
We agree completely about the first three. We disagree entirely about the fourth.
His fourth wave is the resolution. Mine is the next instance of the same thing — and the evidence available now is sharper than the argument I was making a year ago.
Across the earlier eras the implementation failure rate sat between 60 and 85 percent. On his reading, agentic capability should have moved it. It has not. RAND reports more than 80 percent of AI projects failing to deliver business value — roughly twice the failure rate of comparable IT projects without AI. MIT’s NANDA work puts about 95 percent of generative AI pilots at no measurable P&L return. S&P Global has 42 percent of companies abandoning most of their AI initiatives in 2025, against 17 percent the year before. These are reported figures; the primary studies are the citation, not anyone’s summary of them.
But the number getting worse is not the interesting part. The interesting part is why it is not directly comparable.
An ERP implementation counted as successful when it went live. E-procurement counted when adoption held. Those eras measured whether the thing got installed. MIT counts an AI implementation successful only when it produces sustained productivity gains and documented P&L impact, verified by end users and executives.
That is a different question, and it is the right one. It is also the question I have been asking since 1998.
So the honest reading is not that the failure rate rose. It is that the industry has finally started measuring outcome realization instead of implementation completion — and the first time it did, the number came back at ninety-five percent.
The earlier bands were flattering. This one is not. And the causes these reports name — no agreed definition of success before the project begins, weak data foundations, poor integration into real workflows, technology chosen ahead of outcome — are, without exception, things that happen before any technology is installed.
That is the fourth wave as I see it. Not the resolution. The first era honest enough to measure what it was actually producing.
The consequence of an omission scales with autonomy
Here is what concerns me most, and it follows directly from Rousseau’s own argument rather than against it.
He is explicitly predicting that agents will stop executing predefined processes and start selecting the workflow themselves — choosing the supplier, the negotiation strategy, the contracting route, the execution path, fresh each time, based on the situation in front of them.
Grant that. Then the value of the model those agents are reasoning from stops being one input among many and becomes the entire determinant of the outcome.
Increasing intelligence does not reduce dependency on operating reality. It raises the cost of misunderstanding it.
A 1998 buyer working from an incomplete model made one bad call at a time, slowly, in a system where a person could still notice. An autonomous network working from an incomplete model makes every call from it, continuously, at a rate no review cycle observes — and every one of those decisions will be rational, defensible, and correctly derived from a picture of reality that has a department missing from it.
That is not an argument against the operating system. It is an argument that the layer above it is the one that decides whether it works.
Truth Is Believing. Accuracy Is Knowing. Outcome Is Proof.™
-30-
And one pattern held so consistently that I have come to treat it as the finding: the more capable the AI became, the more the outcome depended on the human orchestrating it — not less.
The Operating System Is the Right Architecture. Nobody Has Said Where Its Intelligence Comes From.
Posted on August 25, 2026
0
A live model of markets, prices, supply, demand, supplier performance and risk is the correct foundation for autonomous procurement. The question nobody is asking is who decided what belongs in it — and in 1998 the answer to that question was worth forty-six percentage points of delivery performance.
Jon Hansen | Procurement Insights | August 2026
Romain Rousseau, with Sarah Pohle and Alexandra Lovin, published a piece this week called Reinventing Procurement for the Autonomous Enterprise. It is the most serious argument for agentic procurement I have read, and it deserves engagement rather than the reflexive skepticism this category usually gets from people who have been around as long as I have.
His case, compressed: procurement exists because intelligence was scarce and expensive, and most of what procurement does is scaffolding built to ration that scarcity. Collapse the cost of intelligence and the scaffolding loses its purpose. What survives is not the workflow but the intent behind it. In place of process towers he proposes a Procurement Operating System in five layers — Economic Intelligence, Policy, Agents, Orchestration, Execution — with procurement’s durable claim on the top two.
I think the architecture is right. I think one question sits upstream of it, unasked, and that everything depends on the answer.
Where we already agree, and it is not a small thing
In his seventh section he writes that if procurement builds autonomous sourcing without connection to finance, legal, risk, supply chain and business planning, it will create a faster silo — not transformation but accelerated fragmentation.
That is the whole of my concern about agentic deployment, stated by someone arguing in favour of it. I have been making a version of that point for nineteen years and I have rarely seen it put more precisely by a proponent.
He also names the thing most analyses dodge — that a role which becomes more strategic and concentrates on the highest-value work is, by definition, a role you need fewer of, and that an analysis unwilling to say so is a brochure. That is an honest sentence in a genre that does not reward honesty.
So this is not a disagreement about direction. It is a disagreement about sequence.
The question upstream
The Economic Intelligence Layer is described as a continuous, live model of markets, prices, supply, demand, supplier performance, contractual obligations and risk. The system’s senses.
Here is the question: how was it determined what belongs in it?
Not how is it maintained, or how current it is kept, or how many sources feed it. Who decided what the model contains — and against what were they checking?
Because a live model of the wrong variables is a live model of the wrong variables. It will be beautifully current, continuously refreshed, and still missing the variable determining the outcome — for the same reason no designed map contains its own obstacle: if anyone had known the variable belonged in the model, it would already be in there.
A question I asked in January 2025, still unanswered
I put this to a group of practitioners in a public exchange eighteen months ago, and I will put it here again:
Tell me how Agentic AI would have known to ask, “What time of day do orders come in?”
Nobody answered it at the level it was asked. The best response I received described what a well-designed agent would do — recognize the timing pattern, identify the missing variable, generate the inquiry before an analyst considered it. All plausible, and all of it presupposing that time-of-day is already a variable the system tracks and treats as causally interesting.
Nothing in the declared problem says it is.
The declared problem in 1998 was a national defence maintenance operation delivering next-day parts on 51 percent of the time against a 90 percent contractual requirement. The declared map was four boxes: order received, supplier sourced, parts ship, next-day delivery. Give an agent that map and every data source attached to it, and it will optimize it superbly — faster supplier selection, better delivery probability, dynamic sourcing strategy, automated negotiation.
It will produce a faster 51 percent.
Ask what time of day the orders arrive and you get 4 PM. Ask why 4 PM and you leave procurement entirely — into a service department nobody had put on the procurement map, where technicians were holding parts orders to the end of the day because they were rated on calls responded to. That finding changes what you need to look at back inside procurement. Which sends you out again to the suppliers, then the couriers, then the border, and finally into finance — where the cost of the part and the cost of the freight sat as two separate line items, each correct, each reconciling cleanly, with the loss living only in the relationship between them and nobody looking at the two lines together.
Four departmental crossings. Delivery moved above 97 percent within three months, before any new technology entered the building. The technology came afterward, onto a substrate that had finally been made real — and it was the technology, applied to aligned conditions, that sustained the result across seven consecutive years.
Now write the specification for the Economic Intelligence Layer that would have contained all of that.
Technician call-response incentives. Order submission timing. Buyer queue-clearing behaviour. Cross-border competence of the supplier base. Courier fragmentation. Customs clearance probability. The relationship between two accounting line items and a contract markup formula. And whether the commodity in question moves on dynamic flux pricing or sits on a historical flat line — because a part that costs one hundred dollars at nine in the morning does not cost one hundred dollars at four in the afternoon.
Nobody would have specified it, and not through carelessness. They did not know those things formed a system. The failure is what revealed that they did.
Two stacks, running in opposite directions
The clearest way to see the difference is to put them side by side.
The operating system runs downward:
Intent → Economic Intelligence → Policy → Agents → Orchestration → Execution → Outcome
Tracing runs upward:
Outcome → follow actual causality → cross declared boundaries → discover relationships nobody had declared → validate operating reality → then determine intelligence, policy, agents and execution
These are not competing architectures. The second is the epistemic layer the first assumes it already has.
Every downward stack begins by taking the model of reality as given. That is not a flaw in the design — it is a dependency, and it is invisible precisely because it sits above the top layer. Ask where the contents of the intelligence layer came from and you are asking a question the diagram does not have a box for.
Orchestration is not discovery
The obvious objection is that Rousseau anticipates this. His endpoint is the autonomous enterprise — agents talking to agents across functional boundaries that are today defended by org charts, budget lines and system ownership. If agents span procurement, finance, supply chain and operations, surely the crossing happens.
Orchestration coordinates declared interfaces. It cannot cross an undeclared one.
The technicians’ calls-per-day rating was not an interface. It was an internal performance measure inside a department with no relationship to procurement on any diagram. The two finance line items were not an interface — they were two correctly maintained fields whose relationship was the finding, and a relationship nobody has named has no endpoint for an agent to address.
The claim is not that such a relationship can never be found — a system with broad enough observational reach might surface a statistical correlation nobody asked for. It is that nothing in the architecture gives it a reason to look, or tells it which of a million undeclared correlations is the one that matters. Naming the coupling is prior work, and nothing in the stack does it.
What actually fires
There is a temptation to call the tracing discipline the solution — start from the failure, refuse to assume the cause sits inside the declared process, follow it wherever it goes.
That is a method, and by my own definition a method is a guardrail. It has to be remembered, recognized as applying to the case in front of you, and preferred over the faster forward map. Each of those fails silently, and the last one fails most often, because the forward map is quicker and looks more professional.
The fence is the failure signal.
A contractual requirement standing against actual delivery is structural. It fires whether or not anyone remembers a methodology, it does not depend on anyone’s attention, and it cannot be argued out of existence. A delivery rate stuck at 51 percent against a 90 percent requirement is what that fence emits, and it is the one signal in the entire system guaranteed not to have been designed.
Which is why a known failure is the most reliable place to start. Not because tracing is a superior discipline, but because the failure is the only thing in the operation that already knows the model is incomplete.
Four waves, and the fourth is where we part
Rousseau closes on four waves: transactions digitized, workflows automated, intelligence introduced, and then a fourth that removes procurement as an execution function altogether — making the process invisible and reassigning the human to intelligence, policy and judgment. Most of the market, he argues, is living in the third wave and mistaking it for the destination.
I have my own four, and I published them in March: ERP, e-Procurement, SaaS/Cloud, and now AI. Four consecutive technology eras.
We agree completely about the first three. We disagree entirely about the fourth.
His fourth wave is the resolution. Mine is the next instance of the same thing — and the evidence available now is sharper than the argument I was making a year ago.
Across the earlier eras the implementation failure rate sat between 60 and 85 percent. On his reading, agentic capability should have moved it. It has not. RAND reports more than 80 percent of AI projects failing to deliver business value — roughly twice the failure rate of comparable IT projects without AI. MIT’s NANDA work puts about 95 percent of generative AI pilots at no measurable P&L return. S&P Global has 42 percent of companies abandoning most of their AI initiatives in 2025, against 17 percent the year before. These are reported figures; the primary studies are the citation, not anyone’s summary of them.
But the number getting worse is not the interesting part. The interesting part is why it is not directly comparable.
An ERP implementation counted as successful when it went live. E-procurement counted when adoption held. Those eras measured whether the thing got installed. MIT counts an AI implementation successful only when it produces sustained productivity gains and documented P&L impact, verified by end users and executives.
That is a different question, and it is the right one. It is also the question I have been asking since 1998.
So the honest reading is not that the failure rate rose. It is that the industry has finally started measuring outcome realization instead of implementation completion — and the first time it did, the number came back at ninety-five percent.
The earlier bands were flattering. This one is not. And the causes these reports name — no agreed definition of success before the project begins, weak data foundations, poor integration into real workflows, technology chosen ahead of outcome — are, without exception, things that happen before any technology is installed.
That is the fourth wave as I see it. Not the resolution. The first era honest enough to measure what it was actually producing.
The consequence of an omission scales with autonomy
Here is what concerns me most, and it follows directly from Rousseau’s own argument rather than against it.
He is explicitly predicting that agents will stop executing predefined processes and start selecting the workflow themselves — choosing the supplier, the negotiation strategy, the contracting route, the execution path, fresh each time, based on the situation in front of them.
Grant that. Then the value of the model those agents are reasoning from stops being one input among many and becomes the entire determinant of the outcome.
Increasing intelligence does not reduce dependency on operating reality. It raises the cost of misunderstanding it.
A 1998 buyer working from an incomplete model made one bad call at a time, slowly, in a system where a person could still notice. An autonomous network working from an incomplete model makes every call from it, continuously, at a rate no review cycle observes — and every one of those decisions will be rational, defensible, and correctly derived from a picture of reality that has a department missing from it.
That is not an argument against the operating system. It is an argument that the layer above it is the one that decides whether it works.
Jon Hansen — Procurement Insights | Hansen Models™ | Independent. Unsponsored. Archive-based.
Truth Is Believing. Accuracy Is Knowing. Outcome Is Proof.™
-30-
— 1,800 Hours With AI, and the One Thing That Never Changed, 8 July 2026
Share this:
Like this:
Related