Decision Engineering Comes Before Agent Design
List the decisions first. Then decide, for each one, how it should be made, who holds the authority and what evidence it needs. The agents come last.
A colleague who works with pharmaceutical manufacturers passed on a request from the smart manufacturing leads in those conversations: they want deterministic artificial intelligence (AI) agents. I have written two pieces on what that can mean, Two Operators Can Think Differently and Meet the Same Goal for business readers and Six Things Pharma Should Prepare to Demonstrate About an AI Agent for quality teams. While preparing a deck for a call with those teams, I noticed that the slides explained how agents and the checks around them work, but nowhere listed the decisions the agents would be part of.
The first question is which decisions they mean.
Warren Powell , whose work at Princeton on sequential decision analytics shapes how we think about agent decisions, puts the problem in one line: “You cannot make a better decision until you recognize that you are making a decision.” His method starts with three questions, asked in plain English before any mathematics. **What are the performance metrics? What types of decisions are being made, and who makes them?**What are the sources of uncertainty? Agent projects often start somewhere else, with the model, the framework and the number of agents. Those choices depend on the answers to Powell’s questions, so they cannot be made well until the decisions are listed.
This article sets out how to do that work: how to find the decisions in an operation, how to tell what kind each part of a decision is, and how to run a design session that produces a prioritized list of decisions before anyone draws an agent. Determinism comes after that, one decision at a time. It is longer than my usual articles because it is meant to be used: the six kinds, the decision card and the design session are all here, so a team can run the exercise without another document. The card is also available as a two-page PDF, with a blank template and a worked example.
Why call it engineering
Process engineering gave plants the process flow diagram and the piping and instrumentation diagram. Before anyone writes control logic, those drawings say what equipment exists, how it connects and what each line carries. Business process reengineering did something similar for office work in the 1990s, redrawing the flow of work across whole organizations; Michael Hammer’s 1990 article put its attitude in the title, “Don’t Automate, Obliterate”. Decision engineering produces the equivalent document for decisions: the list of decisions an operation makes, and a record of how each one should be made, before anyone builds the software that makes them.
A process map alone often leaves those decisions unspecified. I have argued before that we should stop designing the process and start designing the decision, and that argument assumed we already knew what the decisions were. A process map shows steps and handoffs. The decision sits inside a box labeled “review” or “assess”, and the map rarely says what question is being answered or which answers are allowed.
The term “Decision Engineering” is not mine. Vanja Bevanda described decision engineering in 2018 as discovering and modeling decisions, then building software that combines analytics, business rules and optimization to make them. James Taylor ‘s decision modeling work and the Decision Model and Notation standard provide ways to record decisions and the dependencies between them. Bain’s work on decision architecture had Nike list 33 key decisions under 10 headings, and Bain expected most companies to end up with 20 to 30 decisions worth focusing on. What agents add is a wider choice of how each decision gets made. A decision can now be made by a rule, a validated model, an optimizer, a language model or a person, often in combination, and under different levels of authority. Making that choice deliberately, one decision at a time, and recording why, is the engineering.
What counts as a decision
Taylor’s decision modeling work offers a simple discipline: write each decision as a question with a list of allowed answers. “Does this deviation need an investigation, and how deep?” might have three allowed answers: record it only, run a standard investigation, or run a full one. “Should the reflux rate change, and by how much?” has a range of allowed values set by the column’s limits; the reflux rate is how much condensed liquid a distillation column sends back down to improve separation. Once a decision is written that way, a team can count it, give it an owner and decide how it should be made.
The same discipline separates decisions from rules. A rule is one way of answering a decision. A site’s approved procedure may define how a given type of event is recorded, assessed and routed for investigation. That procedure is a rule, and the decision is the question it answers. When a workshop collects rules, ask of each one which question it answers, and the decision list starts to appear. Some questions turn out to have no rule at all, because experienced people answer them from judgment.
Powell takes a broad view of what counts. In his framework, a decision is any choice you control, made by a person or a computer, whether or not it is optimal and whether or not anyone acts on it. He names ten types. Among them are several that a plant workshop easily misses:
physical decisions, such as changing a setpoint, moving material or scheduling maintenance; decisions about what to observe, such as which sample to take or which reading to check again; decisions about what to communicate, to whom and when; labeling and estimation, such as diagnosing a fault or estimating the composition of a stream that is not measured; setting the parameters of an existing policy, such as a limit, a target or a weight; choosing the metrics and objectives that every other decision is judged against.
The last two need special handling once agents arrive. People approve the objectives, the weights and limits, and the rules for changing them, under change control. Agents may select operating targets or switch between objectives that people have already approved, but only within that authority, so no agent redefines what success means.
Volume is the other reason to write decisions down. A BioPhorum Operations Group survey of 13 biomanufacturers found each site averaging about 1,500 deviations a year, with 72% classified as minor and about 24% judged to be repeats. A classification decision made more than a thousand times a year at a typical site in that survey deserves careful engineering. Pharma’s own risk guidance already treats many such decisions as settled: the International Council for Harmonisation’s quality risk management guideline, ICH Q9(R1), says decisions governed by standard operating procedures (SOPs), policies or well understood requirements can use rule-based approaches that “do not require a new risk assessment” each time.
Some decisions run at volumes no team could handle one by one. In one of our own deployments, an XMPro application recommends where a chemical company’s product containers should go across about 2,500 plants, warehouses and customer sites in Europe, producing about 250,000 recommendations a month, roughly 8,000 a day. The planners work by exception. A decision made that often needs its question, its allowed answers and its authority written down, because nobody reviews each instance.
Finding the decisions
No single source gives you the list. These five do, between them:
Start from the metrics. List the measures the operation is judged on, then ask which decisions move each one. Powell puts metrics first because it ties the list to value from the start. Ask the people who make each decision, and the people who handle its exceptions, what they call it and which smaller decisions sit inside it. Read existing rules, calculations and models backward: identify the question each one answers, and write it down. Use the records the operation already keeps: operator actions logged by the control system, shift logs, management of change records and, in pharma, deviations and corrective actions. A logged setpoint change shows that someone acted. It does not show how they decided. Interview people about difficult episodes. Gary Klein’s Critical Decision Method walks people back through near misses and surprises, which brings out the cues and judgments no procedure mentions.
In one study of experienced fireground commanders, Klein and his colleagues found that more than 80 percent of the decision points were handled by recognizing the situation and identifying a workable response, without comparing several alternatives. Decisions like that are easy to miss in an interview that asks people to list their options, and they rarely appear in a procedure, which is why the last source on the list matters. You also do not need a complete census before starting. Bain’s advice to focus on the 20 to 30 decisions that carry the most value applies here, with the rest added as the work reaches them.
Six kinds of decision
Once a decision is written as a question, the next step is to ask how each part of it should be answered. The six kinds below describe parts of a decision, and one decision usually has several. Apply all six test questions to each decision; several answers may be yes. The first four describe how an answer is computed. The last two describe what else the decision needs: agreement between parties, or a person who must make or authorize it. Where Powell’s work connects, I note the connection.
1. Rule: an approved rule determines the answer
Test: does an approved, explicit rule determine the answer for specified inputs, including what happens when information is missing or an exception applies? If so, that part belongs in a rule: a limit, a permissive (a condition that must be true before an action is allowed), an SOP precondition or a routing table. A fixed rule like this is one example of what Powell calls a policy function approximation: a mapping from the current state to a decision, with no optimization inside it. A rule gives the same answer for the same state every time, and it can be tested case by case. Two uses of rules need to be kept apart. Some rules answer a question. Others are mandatory constraints that limit the answers any method may give, whether the answer comes from an optimizer, a model or a language model. Constraints of the second kind are held as computable policy, meaning rules written so software evaluates them against plant data.
2. Estimation: the answer is a number or label inferred from evidence
Test: does this part estimate a quantity nobody knows yet, or assign a label, from the evidence available? Soft sensors that estimate product composition between laboratory results, classifiers that identify a fault, demand forecasts, and estimates of how a deviation might affect quality all fall here. This is Powell’s labeling and estimation type. These answers usually feed other decisions and do not act on the plant themselves. They come from validated models, which can be statistical, machine-learned or based on physics. For critical pharmaceutical uses, the July 2025 draft of Annex 22 to the European Union Good Manufacturing Practice guidelines addresses static models, which do not change during use, with deterministic outputs, which are identical for identical inputs. Both properties, and suitability for the intended use, have to be established.
3. Optimization: the best of many options against a clear objective
Test: is there an agreed objective, known constraints and a process model good enough to search the options? Scheduling, blending, and setting operating targets inside limits are examples, and advanced process control already does this work in many plants. Powell describes his cost function approximations as parameterized, usually deterministic, optimization models tuned to perform well over time, and his direct lookahead policies as optimization over a planning horizon. An optimization part can handle uncertainty and still be computed repeatably, which helps testing and replay. The model behind it, its objective and its performance under real conditions still need validation.
4. Reasoning: interpreting a situation nobody wrote a rule for
Test: does the situation fall outside what the rules and models were built for, with incomplete, conflicting or unstructured information, so that someone has to work out what is happening and propose a response? An unusual combination of alarms, a feed change with no precedent, or a deviation whose cause is not clear from the batch record are typical cases. This is where a language model can contribute: it interprets the situation and proposes a response, and the design has to say which task it performs and what evidence will show its proposals are useful. Powell’s four classes of policy (policy function, cost function, value function and direct lookahead approximations) predate language models. When an agent compares the likely consequences of several possible actions before proposing one, it resembles a lookahead policy in a limited way, with an approximate model of the future expressed in language. The checks on its proposals have a separate justification: its output can differ from run to run, so nothing it proposes should reach the plant without passing the same rules as any other request. Not every hard decision is a reasoning decision. Snowden and Boone’s Cynefin framework separates complicated situations, where expert analysis finds the answer, from complex ones, where the right move is often a small, safe experiment, and neither automatically calls for a language model.
5. Coordination: several owners or objectives must agree
Test: does the decision need two or more people, teams or agents with different objectives to agree? Maintenance wants the pump down in Tuesday’s shutdown window, production wants the batch finished first, and the seal kit arrives on Thursday. Each answer is right by its own measure. These decisions need a shared team objective and agreed rules for settling conflict, which I wrote about in Should Multi-Agent Systems Negotiate? Powell lists communication as a decision type in its own right, and coordination between agents is where that type becomes a design problem.
6. Reserved for people: a person must make or authorize it
Test: does law, policy or the approved operating arrangement require a person to make or authorize this particular decision, or is the evidence not yet strong enough to delegate it? Batch release by a Qualified Person, accepting a risk outside normal limits, and approving a change to an objective’s weights are examples. People remain accountable for automated decisions too. The European Medicines Agency’s 2026 workshop report on Annex 22 records that “Accountability remains with qualified/responsible persons and cannot be delegated to AI.” Accountability alone does not mean every decision needs a manual approval. This kind covers the decisions where the authority itself stays with a person, and agents can still gather the evidence, check it for gaps and set out the options.
How the kinds combine: two examples
Take the deviation decision again. A rule from the site’s approved procedure routes the event, a validated model estimates the likely effect on quality, a language model drafts the investigation summary from the batch record, and a quality reviewer decides the major and critical cases. Human review of that summary does not by itself make the language model’s use non-critical, and under the draft Annex 22 that use still needs its own assessment. Or take a setpoint change on a distillation column. A soft sensor estimates the product composition, an optimizer proposes an operating band, an agent interprets an unusual feed change that no rule anticipated, a rule-based gate checks every limit, and the operator decides whether agents may act at all. In both examples the language model handles one part of the decision, and the rest is rules, models and people the plant already understands. A distillation column has run on soft sensors, optimizers and operators for decades, and an agent joins that arrangement as one more participant.
Counting those parts shows where a language model is needed and where it is not. OpenAI’s guide to building agents ends its checklist of good agent use cases with a plain warning: “Otherwise, a deterministic solution may suffice.”
Six things to record for each decision
The classification goes on a short record for each decision, which I think of as a decision card (PDF template and worked example). A header carries an identifier, the accountable owner, the rigor level, a version and a review date. Below it go six sections:
The decision problem: the question and its allowed answers, the trigger and how often it occurs, the inputs and how current they must be, what is uncertain, the objective, the limits and the deadline. The kinds: which kind each part of the decision is, what makes that part, what it produces, and the rule, model or procedure it relies on. The authority: who or what recommends, authorizes and executes, the permitted actions, and who can veto or escalate. The coordination: who must contribute, which other decisions this one depends on, how agreement is reached and what happens when it is not. The assurance: evidence that the decision followed its rules, separate evidence that it achieved the intended result against a baseline over an agreed period, the record that is kept, the fallback, and how changes to its rules, models and prompts are approved. The operating regime: the conditions under which this arrangement holds, how a departure from them is detected, and who approves changes.
Download our Decision Card template
The split in the assurance section carries over from the Two Operators article. Following the rules shows the decision was permitted. Achieving the result shows it was the right one, and that needs measured evidence of its own.
The rigor level comes from the model I proposed in How Much Rigor Does Your Operational AI Need?. Basic, Enhanced and High rigor set the depth of validation, oversight, evidence and change control a decision needs, based on its consequences. At High rigor, the approved model versions and configuration stay fixed until a formal management of change process approves a change. In that article I also proposed assessing agentic systems by type, class, maturity and rigor, and the card supplies what that assessment needs: the kinds inform which type of system fits, the authority field records the role and its authority, and the assurance section is where evidence of maturity builds up.
I described what a single decision definition contains in Software-Defined Operations Writes the Decision Down for AI Agents. The card adds the choice of kind, authority and rigor, which is the part agents make necessary.
Running a design session
Here is how I would run the first design session for an agent team, with the people who own the area in the room: operators, process engineers, quality, and whoever approves changes. Before the session, agree the area and the operating conditions in scope, and collect the metrics the area reports, its SOPs and alarm response procedures, a month of operator actions from the control system, recent shift logs and, in pharma, the deviation register.
Agree what the area is judged on. List the metrics, the objective and the limits that must never be traded against it. This becomes the objective the agents will be scored against. List the decisions as questions with allowed answers, working from the metrics, the people, the documents and the records. Count decision types, not occurrences: classifying a deviation is one decision, made perhaps 1,500 times a year. Aim for a prioritized list of the 20 to 30 that matter most. Describe each priority decision: who makes it today, how often, how much time there is, what information it uses and what is uncertain. Classify each part of each decision with the six test questions. Set the authority for each decision: who recommends, authorizes and executes, who can veto, and what changes during an upset. Draw the dependencies: which decisions feed each other, share a limit or need several owners to agree. This is a starting point for hazard analysis and does not replace it. Set the rigor and agree the evidence: choose Basic, Enhanced or High rigor from the decision’s consequences and how readily an error would be caught, then agree what record and what measured result will show that the decision was made well, and what happens when it cannot be.
One session will not finish all of this. A realistic first output is the prioritized list, a few completed decision cards, and a named owner for each open question. Working sessions complete the rest.
Only then name the agents. Group the reasoning and coordination parts by domain, and those groups become candidate agents and the team they form. Rule parts become checks in the data and action paths and in computable policy. Estimation parts become validated models. Optimization parts stay with the optimizer or the advanced control that already does that job. Reserved parts stay with people, with agents preparing the evidence. The agent team is the last thing designed, and the decision list gives it its requirements. Shared tools, permissions, response times and the separation of responsibilities still shape the final architecture.
In our own engagements, XMPro runs a guided version of this design work (XMForge), which takes a use case from its decisions and success measures through to a configured agent team. In our multi-agent systems (MAGS), those requirements map onto parts of the platform: team objectives and objective functions, Data Streams for checks in the data and action paths, agent roles, and a collaborative process for reaching agreement between agents. A requirement written into a design is not yet a control. Every mandatory rule still has to be implemented and verified in each execution path an action can take, and that verification belongs in the assurance section of the card.
Where determinism comes in
With the list in hand, the determinism question becomes answerable. The US Food and Drug Administration (FDA) published draft guidance in January 2025 on AI that supports regulatory decisions about drugs and biologics, and it starts with the decision. Its first step is to define the question of interest, “the specific question, decision, or concern” the AI model addresses. It then rates two things separately: how much the model influences the decision, and how serious the consequence of a wrong decision would be. Consequence is assessed “irrespective of how modeling is used”. The FDA does not prescribe an amount of determinism. My engineering conclusion follows from its order of work: the decision sets how much determinism and evidence it needs, before anyone chooses a model. The rigor level on the card is where that conclusion becomes a design choice. At High rigor I would expect the approved versions of every part to stay fixed until a change is approved, and more of the answer to come from parts that can be replayed and tested.
The six kinds show where determinism can come from. Rule, estimation and optimization parts can be deterministic by design, giving the same answer for the same inputs every time. A reasoning part may not be, which is why its proposals pass through rule-based checks before anything reaches the plant. The draft Annex 22 uses “deterministic” for a model’s output, and that remains a property of the method. The decision’s consequence determines how much that property matters and what has to surround it. The FDA guidance gives an example: an AI vision system checks the fill volume of vials, but independent release testing reduces how much the release decision depends on the model’s evidence, even though a wrong answer would be serious. That belongs on the card too: what independent evidence checks the model’s answer before it affects release.
In the earlier articles I described an advise mode and an act mode for agents. Those modes belong to individual decisions, so one agent team can act on some decisions while it only advises on others. An advisory output can still strongly influence the person who acts on it, which is why the card records influence and authority separately.
SAP draws the same line between a reasoning part and the rules that check it. Colin Masson of ARC Advisory Group reported from SAP Connect 2026 that when SAP’s chief executive, Christian Klein, was asked how agents can give reliable answers when language models are probabilistic, he said the agents “are embedded in the deterministic workflows of our applications” and run “on the same data, following the same rules, and leaving the same audit trail” as SAP’s other applications. Masson’s summary is that “the agent is forced to yield to deterministic code”: if a proposal breaks a compliance rule, a validation constraint or a credit limit, the application rejects it. That works because an enterprise resource planning (ERP) system already holds decades of approved business rules for the agent to yield to. A plant has deterministic enforcement too, in the control and safety systems that hold its hard limits. Many of the operating decisions above those systems have no coded rule, such as when to take a pump out of service or how to respond to a feed change nobody planned for, and their rules live in procedures and in experienced operators’ judgment. Decision engineering is how a plant writes those decisions down, so its agents have something deterministic to yield to as well.
Where the list breaks down
Decisions interact. Nancy Leveson’s system-theoretic approach to hazard analysis treats many accidents as unsafe interactions between components that each worked as designed. The dependencies drawn in step 6 are where that analysis starts, and they do not replace it.
Decisions also change with conditions. The question asked during a plant upset may be the same as in steady operation, yet need a different kind and a different authority, which is why each card carries its operating regime. A decision reserved for a person needs more than a signature, and, as I argued in the Rigor article, human approval does not automatically make a decision low consequence. Lisanne Bainbridge pointed out in 1983 that automating routine work leaves people with the rare, difficult cases and less practice at handling them, so the design has to give that person time, evidence and practice.
Lists go stale as plants, products and people change, and the record of what was actually decided is how the list stays current. I have written before about decision traces, and recent research shows how decision logs can be mined back into decision models and tables.
A test you can run this week
Pick one area your agents will touch. Write down ten decisions as questions with allowed answers. For each one, mark its kinds, its authority and the evidence it needs. Then count how many need a language model at all, and how many already have a rule, a model or an optimizer that does the job. That count tells you how much agent work there really is, and where it should start.
A finished decision list lets a project team answer the questions that usually come too late: which decisions an agent will touch, what it may do in each, what evidence will show it worked, and which decisions should stay with rules, models or people. Process engineering produced the flow diagram before the control logic. The list of decisions is the first engineering document of an agent project.
Sources
Warren B. Powell, “Decisions, decisions” (decision types and the four classes of policies) and “Framing decision problems”, Sequential Decision Analytics. Decisions; Framing James Taylor, “Decision Modeling: Finding and modeling decisions”, IBM Community, 29 November 2023. Link Vanja Bevanda, “Decision engineering: settling a lean decision modeling approach”, 33rd International Scientific Conference on Economic and Social Development, Warsaw, 2018, pp. 93-102. Proceedings Michael Hammer, “Reengineering Work: Don’t Automate, Obliterate”, Harvard Business Review, July-August 1990. Link Marcia W. Blenko, Michael C. Mankins and Paul Rogers, Decision Insights: What are your critical decisions?, Bain & Company, 2010. PDF Brian Chviruk, Ewald Amherd, Joseph J. Antonetti, Philippe Verdon and Amanda Patnaud, “Transforming Deviation Management”, BioProcess International, 19 September 2017. Link International Council for Harmonisation, ICH Q9(R1), Quality Risk Management, section 5.2, 2023. PDF Gary A. Klein, Roberta Calderwood and Donald MacGregor, “Critical Decision Method for Eliciting Knowledge”, IEEE Transactions on Systems, Man, and Cybernetics 19(3), 462-472, 1989. Link Gary A. Klein, Roberta Calderwood and Anne Clinton-Cirocco, “Rapid Decision Making on the Fire Ground: The Original Study Plus a Postscript”, Journal of Cognitive Engineering and Decision Making 4(3), 186-209, 2010. Link David J. Snowden and Mary E. Boone, “A Leader’s Framework for Decision Making”, Harvard Business Review, November 2007. Link European Medicines Agency, report on the multistakeholder workshop on expert contributions to AI guidance development (Annex 22), EMA/156789/2026. PDF OpenAI, A Practical Guide to Building Agents, 2025. PDF US Food and Drug Administration, Considerations for the Use of Artificial Intelligence to Support Regulatory Decision-Making for Drug and Biological Products, draft guidance, January 2025. PDF European Commission, EudraLex Volume 4, Annex 22: Artificial Intelligence, consultation draft, July 2025. PDF Nancy G. Leveson and John P. Thomas, STPA Handbook (System-Theoretic Process Analysis), March 2018. PDF Lisanne Bainbridge, “Ironies of Automation”, Automatica 19(6), 775-779, 1983. DOI 10.1016/0005-1098(83)90046-8. Link Sam Leewis, Koen Smit and Johan Versendaal, “Discovering operational decisions from data: a framework supporting decision discovery from data”, Decision 51(4), 417-436, 2024. Link Colin Masson, “The Autonomous Enterprise Reality Check (Part 1): Architectural Foundations, Determinism & the IT/CXO Scorecard”, ARC Advisory Group, October 2026; also posted on LinkedIn, 19 October 2026. Link
Pieter van Schalkwyk is the CEO of XMPro, specializing in industrial AI agent orchestration and governance. Drawing on 30+ years of experience in industrial automation, he helps organizations implement practical AI solutions that deliver measurable business outcomes while ensuring responsible AI deployment at scale.
He is the lead author of the Industrial AI Agent Manifesto, published by the Digital Twin Consortium in February 2026, a governance framework for trustworthy autonomous operations.
Our GitHub Repo has more technical information. You can also contact myself or Gavin Green for more information.
Read more on MAGS at The Digital Engineer
How this was made: I worked with Claude to check sources, draft from my direction and edit, and with Codex to review the argument and evidence. I do not publish anything I have not rewritten myself.
This article originally appeared on XMPro CEO’s LinkedIn blog, The Digital Engineer, on 22 October 2026.
