The Operations Decision Agent: Run the What-if Before You Commit Inventory

A tier-2 failure propagates through the context graph. Because the model knows what is causally connected, it isolates the affected subgraph and replans only that; the unaffected chain never moves.

The 2am version of the problem

A machine fails at a plant. Or a tier-2 supplier goes dark, or a port closes, or a promo lands harder than planned. What follows is familiar to anyone who has run an operation: a scramble of calls, extracts, and spreadsheets to work out which orders are exposed, what the options are, and what each option costs. By the time the plan is agreed, the situation has moved.

The other version of the problem is quieter and more expensive. Committing to a supplier, holding a safety-stock level, opening a distribution centre: each decision commits before the outcome exists and propagates through every part of the business coupled to it. By the time the result is visible, the cost is already paid. You can't review your way out of a decision the way you can review a task.

What planning tools do today

Operations has never lacked tooling. APS systems optimise, digital twins mirror assets, S&OP cycles align the functions, dashboards report. Each is useful and each shares the same limit.

An APS optimises against a fixed model of the operation: given these parameters, here is the best plan. It can't tell you what happens when the parameters themselves are the question, when the decision changes the system the plan assumed. A digital twin mirrors the physical estate in detail, but a mirror describes; it doesn't answer what a decision does to next month's OTIF. And a dashboard reports that an order is late once it's already late.

The question operations leaders carry is different in kind: should we? Should we qualify the second supplier at added cost? Should we cut safety stock in this DC, and by how much, without missing service levels? Should we accept the promo volume? Every one of these is counterfactual. Answering it requires a model of the operation you can act on before you act on the operation.

A world model for operations

An Enterprise World Model represents the operation as state and transitions.

State is the live configuration of the operation: inventory positions by location, capacity available in practice (rarely what the master data says), supplier lead times and their current risk, open orders and the commitments behind them. Continuously updated, so the model reasons about your operation today rather than a historical average of it.

Transitions are causal functions describing how the operation moves from one state to the next. How a lead-time slip propagates to production, to inventory, to the customer's date. How a line-speed change moves throughput and defect rates. Because transitions describe mechanism rather than history, they hold in situations the operation has never seen: the tier-2 failure that has never happened, the demand level no promo has ever produced.

Binding it together is the context graph: who depends on what, and in which direction. The graph carries the constraints the operation genuinely obeys, physical, logistical, and contractual. Inventory can't go negative. Capacity can't be allocated twice. A contract has a floor and a term.

What the decision agent does with it

Take the supplier case. The agent contextualises: this network, these suppliers, this inventory, today. It simulates the disruption: the tier-2 supplier fails, and the model propagates the failure through the graph, showing which orders slip, at what delay, at which customers. It compares mitigations: expedite at premium freight, qualify the second source at added cost, re-allocate inventory between DCs, each with consequences and a confidence range. It cascades the preferred option through the network before commitment: margin impact, working capital, exposure created elsewhere. Then it recommends a plan with the decision trace attached.

Three behaviours fall out of this that no planning tool provides.

It acts before the dashboard does

Because the model runs the current state forward, it predicts disruptions before they land. A defect on one line today shows up as a customer order that will miss its date next week, early enough to act before anyone downstream feels it.

It replans surgically

The model is a graph, so it knows which parts of the operation are causally connected and which aren't. When something breaks, it isolates the affected subgraph (the specific orders, lines, and constraints in the blast radius) and replans only that. The fix stays small and explainable: the order was saved by moving it to line 1. The rest of the operation never has to move.

It refuses invalid plans

If a proposed action moves inventory that doesn't exist, books capacity already committed, or breaches a supplier contract, the world model blocks it before it reaches a system of record. Every action must trace back to a simulated cause. The blast radius of a wrong recommendation is a rejected plan, not a broken supply chain.

What changes for the operations leader

Firefighting becomes forward planning. The scramble that follows a disruption is replaced by a standing capability: the disruption is simulated, the mitigations are compared, and the recommendation arrives while the decision is still reversible.

Trade-offs get one model instead of five spreadsheets. Cut safety stock and you touch service levels, working capital, and obsolescence at once. The world model holds those couplings explicitly, so the what-if returns the whole trade-off rather than one function's view of it.

And every recommendation can face an audit. Plans trace back to specific state values and transition logic rather than a black-box score, and the model declines to make confident calls where its knowledge is thin. That's what makes agent recommendations worth examining in a domain where wrong answers cost real money.

Getting to deployment

The path doesn't require replacing the APS, the ERP, or the twin. It starts by identifying the decisions that carry the most consequence, building the world model for those decisions first, and validating it against historical episodes before anything goes live: replay last year's disruptions and check the model's predictions against what happened. Then embed it as the reasoning engine for the decision agents operating there.

Start where decisions carry the most consequence. For most operations, that's supplier risk, inventory policy, or disruption response. Build outward from the first win: the same model that runs the supply what-if can grow to simulate the pricing decision that created the demand. One world, many decisions.

FAQ

How is this different from a digital twin? A twin mirrors the operation, often at asset level, and describes it. A world model carries causal transitions and constraints, so it can answer intervention questions: what happens to OTIF and working capital if we act? Mirrors describe; world models decide.

How is this different from our APS? An APS optimises within a fixed model of the operation. A world model simulates what a decision does to the operation itself, including decisions that change the parameters the APS treats as given, and it constrains agent actions against business reality.

What does it need to get started? Event traces from your existing systems. Operational discovery infers the real process structure, its current state, and its drivers from those traces, and priors learned across other enterprise deployments cover thin history. Validation runs against your own historical episodes before anything goes live.

Does it act autonomously? It recommends, with the decision trace attached, and blocks infeasible actions. How much execution authority to grant the agent is a governance choice you make per decision type, not a property of the architecture.