Jon W. Hansen, FCIPS · Procurement Insights | Hansen Models™
On 9 October, Sanjoy Kumar Malik published one of the clearest maps I have seen of how an AI agent should execute safely in an enterprise. It is worth studying.
Look at how it is built. A control plane at the top. An agent runtime beneath it. A security and execution boundary around the agent harness. Below the harness, the context layer, the model access layer and the tool gateway, and around all of it, cross-cutting controls for authorization, policy, human approval, audit and cost. Every layer is necessary, and every one is well designed.
And it runs one way. However many layers it has, it is a map built forward from the plan, from the top down, toward the task. It contains what someone thought to design in. Adding layers makes it more thorough. It does not change its direction.
Now look at what the operation it serves actually does.
The same six functions. One drawn as a sequence. One as it operates. Illustrative, not measured data.
On the left is the sequence every organization draws: service, buyers, finance, supplier, courier, customs, each handing off to the next. On the right is how those same functions actually behave: as strands, each moving on its own rhythm, engaging one another at moments nobody scheduled, with consequences that ripple across all of them at once, not down a line.
That is where outcomes are decided, and it is the part a designed map cannot show. Sanjoy’s own worked example makes the point. His agent audits cross-border logistics invoices against contract rates and flags anomalies. In 1998, I worked on exactly that kind of operation. These were dynamic flux commodity items, priced at the moment of the order rather than against a contract rate, and our client was losing margin on every transaction: the purchase order covered the part, the courier’s charges arrived on a separate invoice, and the markup to the customer was calculated on the purchase order alone. The error lived between two correct documents, in the seam between finance and the courier. An agent built to audit invoices against contract rates would have had no contract rate to check them against, and it would have found nothing.
Three things the forward map could not see
The invoices were only one seam. When we traced the DND operation backward from its failing outcome, three more surfaced, and none of them had a box on any map.
First, the parts were the wrong kind of commodity for the contract. The RFPs of the day asked for firm prices on many pages of components, locked for three to five years. That works for what I call a historic flat line part, whose price holds steady for long periods. These were dynamic flux parts. Their prices drop steadily, often sharply soon after a contract is signed, and keep dropping until the part leaves circulation. A fixed price on a dynamic flux part is wrong almost from the day it is signed, and more wrong every month. Think of the lobster on a restaurant menu: no restaurant prints a lobster price meant to last five years. It writes “market price,” because the cost changes daily. Some bidders understood the decay well enough to quote their parts at zero dollars, and some even issued the DND a credit for every part used. On the evaluation sheet, that looked like savings. It was the cheapest column to give away.
Second, the installed base the parts list was written for was disappearing. Over a three-to-five-year contract, older systems were retired and replaced by new ones whose parts were covered by manufacturer warranty, and which had no parts list at all. Anything new, or added, was quoted by the technician at “market price” and often approved on the spot, with no list, no committed price and no competing quote. The contract was won on a column that was shrinking toward zero. The money was made in a column that kept growing.
Third, the same part had four names. One component carried a service number, a warehouse number, a reseller number and sometimes a fourth from frontline suppliers, with descriptions that rarely matched. A base called on a Friday afternoon needing a replacement tape backup unit by Saturday, the most expensive moment to buy anything. Because we had reconciled the numbering, we could tell them they already had three good units in their own local warehouse.
Each of these looked correct at the moment it happened. Every bid was valid, every quote was approved, every emergency order was well formed. That is why a forward map, however detailed, could not show them, and why they surfaced only by tracing backward from the outcome and feeding every transaction back into the record until the patterns repeated in plain view.
It is also why automating first would have made things worse. Automate that map, and you get a faster RFP process that locks in the same fixed pricing, faster ordering that places the Friday emergency order in seconds for a part already on the shelf, and an automated audit that confirms every document is correct. The technology faithfully executes whatever map you hand it.
Once the operation was traced and rebuilt, next-day delivery rose from 51% to 97.3%, and the service provider that engaged us reported a 23% reduction in its cost of goods, both sustained for seven years. The cost to the end client was never measured separately, because the problem never appeared on any single invoice.
This is not a criticism of the architecture. It is a question about what the architecture is built around. A designed map governs how an agent executes. It cannot tell you whether the task reflects how the operation actually runs. That requires a map traced backward from what is actually happening, and a fence that keeps the agent tied to it.
A static representation of the same difference: Sanjoy’s map is the map you design, built forward from the plan. The map you trace starts from the failure and works backward to what actually caused it.
So, what is the most valuable talent or capability in the AI era? In the AI era, coding will become a secondary skill to synthesized critical thinking.
Truth Is Believing. Accuracy Is Knowing. Outcome Is Proof.™
Every Layer Works. The Map Still Runs One Way.
Posted on October 11, 2026
0
Jon W. Hansen, FCIPS · Procurement Insights | Hansen Models™
On 9 October, Sanjoy Kumar Malik published one of the clearest maps I have seen of how an AI agent should execute safely in an enterprise. It is worth studying.
Image: Sanjoy Kumar Malik, “AI Agent Architecture: Conceptual Reference Guide,” LinkedIn, 9 October 2026.
Look at how it is built. A control plane at the top. An agent runtime beneath it. A security and execution boundary around the agent harness. Below the harness, the context layer, the model access layer and the tool gateway, and around all of it, cross-cutting controls for authorization, policy, human approval, audit and cost. Every layer is necessary, and every one is well designed.
And it runs one way. However many layers it has, it is a map built forward from the plan, from the top down, toward the task. It contains what someone thought to design in. Adding layers makes it more thorough. It does not change its direction.
Now look at what the operation it serves actually does.
The same six functions. One drawn as a sequence. One as it operates. Illustrative, not measured data.
On the left is the sequence every organization draws: service, buyers, finance, supplier, courier, customs, each handing off to the next. On the right is how those same functions actually behave: as strands, each moving on its own rhythm, engaging one another at moments nobody scheduled, with consequences that ripple across all of them at once, not down a line.
That is where outcomes are decided, and it is the part a designed map cannot show. Sanjoy’s own worked example makes the point. His agent audits cross-border logistics invoices against contract rates and flags anomalies. In 1998, I worked on exactly that kind of operation. These were dynamic flux commodity items, priced at the moment of the order rather than against a contract rate, and our client was losing margin on every transaction: the purchase order covered the part, the courier’s charges arrived on a separate invoice, and the markup to the customer was calculated on the purchase order alone. The error lived between two correct documents, in the seam between finance and the courier. An agent built to audit invoices against contract rates would have had no contract rate to check them against, and it would have found nothing.
Three things the forward map could not see
The invoices were only one seam. When we traced the DND operation backward from its failing outcome, three more surfaced, and none of them had a box on any map.
First, the parts were the wrong kind of commodity for the contract. The RFPs of the day asked for firm prices on many pages of components, locked for three to five years. That works for what I call a historic flat line part, whose price holds steady for long periods. These were dynamic flux parts. Their prices drop steadily, often sharply soon after a contract is signed, and keep dropping until the part leaves circulation. A fixed price on a dynamic flux part is wrong almost from the day it is signed, and more wrong every month. Think of the lobster on a restaurant menu: no restaurant prints a lobster price meant to last five years. It writes “market price,” because the cost changes daily. Some bidders understood the decay well enough to quote their parts at zero dollars, and some even issued the DND a credit for every part used. On the evaluation sheet, that looked like savings. It was the cheapest column to give away.
Second, the installed base the parts list was written for was disappearing. Over a three-to-five-year contract, older systems were retired and replaced by new ones whose parts were covered by manufacturer warranty, and which had no parts list at all. Anything new, or added, was quoted by the technician at “market price” and often approved on the spot, with no list, no committed price and no competing quote. The contract was won on a column that was shrinking toward zero. The money was made in a column that kept growing.
Third, the same part had four names. One component carried a service number, a warehouse number, a reseller number and sometimes a fourth from frontline suppliers, with descriptions that rarely matched. A base called on a Friday afternoon needing a replacement tape backup unit by Saturday, the most expensive moment to buy anything. Because we had reconciled the numbering, we could tell them they already had three good units in their own local warehouse.
Each of these looked correct at the moment it happened. Every bid was valid, every quote was approved, every emergency order was well formed. That is why a forward map, however detailed, could not show them, and why they surfaced only by tracing backward from the outcome and feeding every transaction back into the record until the patterns repeated in plain view.
It is also why automating first would have made things worse. Automate that map, and you get a faster RFP process that locks in the same fixed pricing, faster ordering that places the Friday emergency order in seconds for a part already on the shelf, and an automated audit that confirms every document is correct. The technology faithfully executes whatever map you hand it.
Once the operation was traced and rebuilt, next-day delivery rose from 51% to 97.3%, and the service provider that engaged us reported a 23% reduction in its cost of goods, both sustained for seven years. The cost to the end client was never measured separately, because the problem never appeared on any single invoice.
This is not a criticism of the architecture. It is a question about what the architecture is built around. A designed map governs how an agent executes. It cannot tell you whether the task reflects how the operation actually runs. That requires a map traced backward from what is actually happening, and a fence that keeps the agent tied to it.
A static representation of the same difference: Sanjoy’s map is the map you design, built forward from the plan. The map you trace starts from the failure and works backward to what actually caused it.
I explained how the two maps differ, and why only the second one finds the obstacles, in The Map You Design and the Map You Trace.
So, what is the most valuable talent or capability in the AI era? In the AI era, coding will become a secondary skill to synthesized critical thinking.
Truth Is Believing. Accuracy Is Knowing. Outcome Is Proof.™
-30-
Share this:
Like this:
Related