Articles

Decision engineering: pointing abundant cognition at value

Working notes · 20 September 2026 · 12 minute read

Here is the thesis in one line: agentic AI makes cognitive capacity abundant inside a business, and the binding constraint moves from having the capacity to knowing where to point it.

Decision engineering (a working name, for now) is the practice of answering that second question systematically. You build a map of the decisions a business actually makes, find the ones made badly or not at all, and point the newly cheap cognition at the ones that move money.

This page sets out the argument, then works through one domain in enough depth to be concrete. It’s a method, not a case study. The simulation below is a model, not a deployment.

The foundation: most decisions in a business are invisible

There are far more decisions inside an operating business than anyone could count, and the overwhelming majority never reach anyone whose job is to improve decisions. Data and analytics work concentrates almost entirely on the visible tip — the decisions that come with a meeting, a deck and a business case.

It helps to put decisions on a ladder:

Notice that the value isn’t concentrated at the top of that ladder. The deliberate decisions already get attention, so the marginal return on more analysis there is modest. The lower rungs are unexamined, numerous, and frequently wrong in ways nobody has priced, Not through carelessness. Revisiting them simply was never economic. One person cannot re-derive four hundred parameters every quarter.

That is precisely the constraint that changes when cognitive capacity becomes cheap.

A worked example: master planning in a manufacturing business

Abstraction is the enemy here, so take one real chain. In a manufacturing business, master planning produces a master plan: how much to make in each period. A planning model generates that plan, and inside the model sit the settings that decide what comes out.

Follow one branch down:

Queue allowance is the interesting one. It is the padding built into planned lead time to account for the fact that a job spends most of its life waiting, not being worked on. It is a single number in a configuration table. In most businesses it was set once, by someone, years ago — rung four or five of the ladder.

It’s also, unambiguously, a decision. It has alternatives. It has consequences. And those consequences run all the way to revenue.

What the alternatives look like

• Fixed at a central estimate — set queue allowance from the median observed queue time. Plans look tight and efficient.
• Fixed at a protective percentile — set it from, say, the 85th percentile of observed queue time. Plans are more conservative.
• Dynamic — derive it per product family, per work centre, per load condition, and revise it as conditions change. This is the option that is almost never taken, because nobody has the capacity to maintain it.

What the simulation shows

Running a simulated shop floor against the two fixed options gives the shape of the trade-off. Setting queue allowance at the median produces a higher lateness percentage and more cumulative late days; the 85th percentile produces fewer of both. On late delivery alone, the protective setting wins clearly.

But lateness is only one side. The same simulation shows the distribution of how early orders complete against their due dates, and the protective setting pushes that distribution earlier. Earliness is not free. It means material released sooner, work-in-progress sitting longer, cash committed earlier, and finished goods waiting for a due date to arrive.

So the decision is not “which number is correct”. It is a trade between service level and working capital, and the right point on that trade depends on what late delivery costs this business relative to what carrying inventory costs it. Those are two numbers a finance team can supply, and almost nobody is asked to supply them, because nobody framed the configuration field as a question.

A parameter with a trade-off behind it and no owner is not a setting. It is an unmade decision with a price attached.

The next step in this example, and the one that makes it fundable, is translating those two outcome curves into currency: late days priced at their real consequence, earliness priced at carrying cost. That conversion is what turns a shop-floor chart into a business case.

The decision portfolio

One parameter is an anecdote. The method is to map the whole space.

Many organisations already have a value-driver tree: financial performance at the centre, decomposed outward into the operational drivers that move it — material availability, on-time delivery, throughput, yield. Decision engineering extends that tree by one layer, and the extra layer is where the work happens:

Drawn out, this becomes a tree with hundreds of leaf nodes, each one a decision. A radial layout is a practical way to hold it in one view: financial metrics at the centre, operational KPIs in the ring around them, decisions on the outside.

For the map to be useful rather than decorative, each decision node needs a consistent set of fields:

• Value chain — the traced path from this decision to an operational KPI and on to a financial metric. If the path cannot be drawn, the node does not belong on the map.
• Current mode, which rung of the ladder it currently sits on, and who owns it, if anyone.
• Failure mode — what going wrong looks like, and in which direction it currently errs.
• Option space — the alternatives, including the dynamic option that nobody has capacity for today.
• Measured impact — the difference between options, in KPI units first and currency second.
• Decision frequency — how often it could usefully be revisited, versus how often it actually is. The gap between those two numbers is the opportunity.

Populated, the map does something a list of AI use cases cannot: it ranks. It shows where decision quality is weakest, where the traced value is largest, and therefore where capacity should be pointed first. That ranking is the roadmap.

Why agents change the economics

Everything above could in principle be done by people. It isn’t, and the reason is capacity. A planner who could revisit three hundred parameters against current conditions every week would be enormously valuable, and doesn’t exist. So the parameters stay where they were set, and the business quietly absorbs the cost.

Agents change the arithmetic because the marginal cost of revisiting a decision approaches zero. An agent assigned to a decision node can hold three responsibilities:

• Decide — evaluate the option space against current conditions, within an explicitly bounded mandate.
• Escalate — hand upward when the situation falls outside the mandate, when confidence is low, or when the value at stake crosses a threshold.
• Execute — write the decision back into the system that acts on it, with an audit trail.

Three engineering constraints decide whether that works:

1. A model of consequence. An agent tuning queue allowance needs to be able to evaluate the outcome — through simulation, backtesting against history, or a staged rollout. Without a feedback signal you have automated the guess rather than improved the decision.
2. A bounded mandate with real escalation. Ranges it may move within, thresholds above which it must ask, and a human who actually reviews escalations. This is the governance layer, and it is the part that makes the programme acceptable to the people whose process it is.
3. Measurement you can defend. Every decision an agent makes needs to be recorded with its inputs, its reasoning and its outcome — both to improve it and to answer, a year later, why the number changed. This is the same discipline as an evaluation harness, applied to decisions rather than outputs.

The security posture matters too, and for an unusual reason: these agents have write access to operational systems. That puts them squarely in the territory covered in AI security for LLM products — least-privilege tool scoping, human approval for irreversible actions, and treating anything read from an upstream system as untrusted.

What happens to the people

The obvious worry is that this is a headcount argument in disguise. In practice it lands differently, because most of the work being automated is work nobody was doing.

Planners and analysts freed from manually maintaining parameters do not run out of things to do. They move toward the frontier — the places where the field itself has not settled, where different schools of thought disagree, where the right answer has to be discovered rather than looked up. They design the experiments that produce the evidence. They set the mandates the agents operate within, and they handle the escalations, which are by construction the interesting cases.

This is the expansion mechanism from how AI generates value, not the substitution one. The value comes from decisions that were never made well, not from labour removed.

Running it as a programme

Sequenced honestly, this is not a project that finishes in weeks:

1. Map the portfolio in one domain. Decision tree, value chains traced to financial metrics, current rung recorded for each node. Weeks, not months, and it is a strategic engagement in its own right — the map has value even if nothing is built.
2. Quantify a handful of nodes. Simulate the option space for the highest-traced-value decisions and convert the differences into currency. This produces the business case and, just as importantly, tests whether the value chains survive contact with data.
3. Instrument before automating. Put measurement around the decisions you intend to hand over, so the baseline exists before anything changes.
4. Build agents on the highest-value nodes, starting with ones where consequence is simulable and errors are recoverable. Human-in-the-loop first, mandate widened on evidence.
5. Widen coverage. The economics improve as the portfolio grows, because the mapping method, the governance pattern and the measurement layer are reused across nodes.

The order matters. Building agents before mapping the portfolio produces automation pointed at whatever was most convenient to automate, which is rarely where the value is.

Honest limits

• It needs a model of consequence. Domains where you cannot simulate, backtest or safely stage a rollout are much harder, because there is no way to tell a good decision from a confident one.
• The map is an artefact that decays. Processes change, and a decision portfolio nobody maintains is worth what an out-of-date architecture diagram is worth.
• The hard part is organisational. Handing a parameter to an agent means someone accepts that it will move without them. Mandates, escalation paths and audit trails are what make that acceptable, and they take longer to agree than the software takes to build.
• Simulation is not deployment. A simulated result establishes the shape and rough size of a trade-off. The real number arrives only after the change is live and measured, and it will differ.

None of which undermines the thesis. It sharpens where it applies: domains with many parameters, a computable notion of consequence, and a value chain you can trace to money. Supply chain and manufacturing planning fit unusually well, which is why that is the domain worked through above. Pricing, credit, maintenance scheduling and capacity planning have the same shape.