________________________________________________________________________________________________________________________
exactly that. The practical consequence is that these systems remain rigid, in that they are configured around one network and changing them is a project rather than an adjustment, and they remain largely untrusted, because the people using them cannot see the logic behind a recommendation and therefore override it, frequently for good reasons.
That second failure is not a changemanagement problem to be trained away. A planner who overrides a recommendation they cannot interrogate is behaving sensibly rather than obstructively, and every one of those overrides is a piece of real business judgment the system did not hold. It is lost for a mechanical reason rather than a cultural one: the judgment exists as a sentence, and until recently nothing in the stack could act on a sentence. Business logic had to arrive as code or configuration, which meant a developer, a release and a delay, so the planner adjusted the number by hand and moved on.
That is the constraint that has now lifted, and it is where the technology earns its place.
What agents do that planning systems cannot
Two kinds of thing need to reach the plan, and neither sits in a data warehouse. The first arrives from outside, and most of it is simply text: the supplier email confirming a three-week slip, the scanned certificate of analysis, the carrier notification, the contract clause nobody has read since signature. An agent reads it, works out which product and which location it bears on, and turns it into something the plan can use, which means a change to a demand or supply driver with a confidence attached and the source still visible behind it. That is the work planners have always done by hand, at whatever hour the email arrived.
The second is more valuable, and it governs what happens next. It is what a planning team already knows and has never
32