Most sourcing estates are several platforms held together by routing rules that nobody owns. The demand we keep hearing: one intelligent layer above them all that reads each request and sends it to the right platform and the right process - while every system of record stays exactly where it is.
Route each spend type to the right sourcing platform and the right process, automatically. Today that routing is done by rules, across an ecosystem where every category runs its process slightly differently - so the request goes where the rules point, which is not always where it belongs.
This was not pitched to us as one more tool for the stack. It was named as the architectural gap above everything else in the conversation: the platforms exist, the processes exist, and nothing intelligent sits on top of them.
Heard from a senior procurement-solutions leader at a global consumer-goods manufacturer. Paraphrased, like everything on this map.
Anyone can demo a router. The reason this gap is still open in mature procurement organizations is that the hard parts sit around the routing, not in it.
Directional on purpose. We do not attach figures to demand signals - but the pools below are where the value collects wherever this pattern comes up.
A request that lands on the wrong platform bounces, gets re-routed and waits in between - and the sourcing event waits with it.
The bounce and the re-route stop being routine stages. A request goes where it belongs on arrival, and sourcing starts when the need shows up, not after the detour.
Policy is checked after the fact: audits catch the non-compliant route once the request has already travelled it, and someone gets to unwind what should never have happened.
When the layer does the routing, policy is applied at the junction. The non-compliant route is not flagged - it is simply never taken.
Several platforms, held together by routing rules nobody owns, with every category running its process slightly differently - an estate that behaves like many processes wearing one name.
The ecosystem starts behaving like one process - without the rip-out-and-rebuild program that is usually the price of that sentence.
Two engines run in production today - Analytical Lab Reports and account Knowledge Twins. Everything else on this map is an extension on the same foundation.
This entry is one of the extensions. Agent and task flows do the reading and the deciding; the integration layer - MCP-based connectors - carries each request to the platform that executes it. That is exactly the routing-and-integration fabric an orchestration layer needs, and none of it replaces a system of record.
The understanding underneath it - which categories exist, which policies apply, which platform owns what - is theKnowledge Twin mechanism, scoped to your sourcing landscape instead of an account.
The last group gets a veto worth respecting: anything that behaves like yet another platform has already failed the brief.
The layer runs inside your infrastructure, inside your boundary - your platforms, your policies, your data. And your freedom of action stays intact: which models do the reasoning, where the workloads run, and what the economics look like remain your calls.
Back to the AI ROI MapPick the spend type that never lands on the right platform first time. We will walk the exact path it would take through the layer - what gets read, what gets routed, and what never moves.
On-prem. Your data never leaves your boundary.