[{"data":1,"prerenderedAt":56},["ShallowReactive",2],{"thought-decision-models-for-agent-workflows":3},{"slug":4,"path":5,"url":6,"title":7,"metaTitle":8,"description":9,"published":10,"modified":10,"datePlaceholder":11,"keywords":12,"image":23,"imageUrl":29,"summary":30,"faqs":31,"reference":44,"material":-1,"cta":-1,"html":52,"referenceHtml":53,"wordCount":54,"readingMinutes":55},"decision-models-for-agent-workflows","\u002Fthoughts\u002Fdecision-models-for-agent-workflows","https:\u002F\u002Fgavinerasmus.com\u002Fthoughts\u002Fdecision-models-for-agent-workflows","Applying The Decision Model to long-running agent workflows","The Decision Model for agent workflows | Gavin Erasmus","Why long-running AI agent workflows make inconsistent decisions, and a design using The Decision Model to make them consistent and auditable.","2026-10-23",false,[13,14,15,16,17,18,19,20,21,22],"The Decision Model","TDM","decision modelling","AI agents","agentic workflows","determinism","rule families","DMN","Jev","LLM",{"src":24,"src2x":25,"width":26,"height":27,"alt":28},"\u002Fthoughts\u002Ftdm-three-components.png","\u002Fthoughts\u002Ftdm-three-components@2x.png",1280,720,"Diagram of three components and their roles: Jev, a typed decision model, answers narrow judgement questions; The Decision Model's rule families apply the business rules deterministically; the LLM agent calls only the tools the conclusion permits.","https:\u002F\u002Fgavinerasmus.com\u002Fthoughts\u002Ftdm-three-components.png","Large language models do not apply the same rule in the same way on every run, and in long-running agent workflows the inconsistency compounds. The approach described here removes business decisions from the prompt and models them with The Decision Model (TDM), a method published by Barbara von Halle and Larry Goldberg in 2009. Rule families apply the business rules in code, a typed decision model answers only the narrow questions that need judgement and abstains when uncertain, and the LLM acts only within the conclusion.",[32,35,38,41],{"q":33,"a":34},"What is The Decision Model?","The Decision Model (TDM) is a method for representing business logic, published by Barbara von Halle and Larry Goldberg in 2009. It expresses decisions as rule families, which are small tables of conditions and conclusions that chain together, and normalises them so that each fact appears once and every dependency is visible.",{"q":36,"a":37},"Why are AI agent workflows not deterministic?","A large language model interprets its instructions afresh on every run, so the same input can lead to a different decision. In a long-running workflow, each step depends on earlier decisions, so small inconsistencies compound across the process.",{"q":39,"a":40},"What does the typed decision model do in this design?","The typed decision model, Jev, answers only narrow judgement questions that rules cannot resolve, such as whether a document is a bill. It must choose from candidates extracted by code, returns a confidence score, and is treated as uncertain below a set threshold, in which case a person decides.",{"q":42,"a":43},"Does this make the LLM itself deterministic?","No. The LLM continues to interpret input and call tools, but the business decisions are made by rule families in code, and the agent may act only within the conclusion those rules return.",{"text":45,"name":46,"authors":47,"year":50,"publisher":51},"von Halle, B. and Goldberg, L. (2009). *The Decision Model: A Business Logic Framework Linking Business and Technology.* Auerbach Publications.","The Decision Model: A Business Logic Framework Linking Business and Technology",[48,49],"Barbara von Halle","Larry Goldberg",2009,"Auerbach Publications","\u003Cp>AI agents are now able to run business processes that span many steps, including reading a document, matching it to existing records, applying policy, writing to a system of record and confirming the result. However, a large language model (LLM) does not apply the same rule in the same way on every run. In a short task the variation is tolerable, but in a long-running workflow each step depends on the decisions made before it, and the inconsistency compounds. As an illustration, a workflow containing twenty decisions, each made consistently 98 per cent of the time, completes all twenty consistently on approximately two runs in three. A process that behaves in this way cannot be audited and cannot be permitted to act without a person checking each step.\u003C\u002Fp>\n\u003Cp>The common response is to extend the prompt. Agent procedures are written as prose, and the model interprets that prose afresh on every run. As a result, the same input can produce a different decision, a required step can be skipped without any signal, and the logic cannot be reviewed, as it exists only in the model's reading of the text. On the CLTF platform, before the current controls were introduced, finance agents created a supplier that did not exist, drafted a bill payable to the business owner rather than the supplier, entered dates with no year and omitted a verification step the procedure required. In each case the model made a business decision implicitly and made it incorrectly, while its handling of the language was sound.\u003C\u002Fp>\n\u003Ch2>An established method\u003C\u002Fh2>\n\u003Cp>The approach removes those decisions from the prompt and models them explicitly, using a method published in 2009. The Decision Model (TDM) was developed by Barbara von Halle and Larry Goldberg. I applied it as Corporate and Institutional Banking Debt Change Programme Director at the Royal Bank of Scotland (RBS) on the end-to-end London Interbank Offered Rate (LIBOR) loans process and system transformation programme. Larry Goldberg trained the debt change team in the method. The LIBOR loan processes across the front, middle and back office were redesigned using Business Process Model and Notation (BPMN) process models and TDM decision models, implemented in an IBM Business Process Manager workflow integrated with LoanIQ, and a permanent process and decision modelling centre of excellence was established within the change team.\u003C\u002Fp>\n\u003Cp>TDM represents business logic as rule families. A rule family is a small table in which each row is a set of conditions leading to a single conclusion, and the conclusion of one family can serve as a condition in the next, so that the families chain into a complete decision. The logic is normalised in the same manner as data in a relational database, so that each fact appears once and no rule depends on another without that dependency being visible. The logic is also held separately from the process that uses it. The Object Management Group's Decision Model and Notation (DMN) standard draws on the same principles. The method was designed for a regulated bank that required its decisions to be consistent, explainable and owned, which is the same requirement now placed on agents executing finance processes.\u003C\u002Fp>\n\u003Ch2>The design\u003C\u002Fh2>\n\u003Cp>The design combines TDM with two newer components, each assigned a single function. Before any rule is applied, code extracts candidate values from the source document, comprising the dates, amounts and references printed on it. Only values extracted in this way are eligible to be written to the ledger. Rule families then apply the business rules in code and return the same conclusion for the same input on every run. Each family has an explicit hold outcome, which refers the case to a person where the rules do not resolve it.\u003C\u002Fp>\n\u003Cp>Certain questions cannot be resolved by rules, such as whether a document is a bill, or which of two printed dates is the invoice date. These are referred to a typed decision model, and Jev, a model developed by TypeSafe and available through OpenRouter, is being tested in this role. Jev answers a fixed-choice or yes\u002Fno question, selects only from the candidates supplied by code, and returns a confidence score. Where the confidence falls below a set threshold, the answer is treated as uncertain and a person decides. The typed model supplies facts to the rule families and does not evaluate the decision itself, as a probabilistic evaluation of the full decision would remove the consistency the rule families are intended to provide.\u003C\u002Fp>\n\u003Cp>The LLM agent retains the tasks to which it is suited, being the interpretation of unstructured input and the calling of tools. It may call only the tools the decision permits, with the values the decision permits. A required step, such as reading a record back after writing it, is enforced by the runtime as a rule rather than left to the agent as an instruction. The workflow is consequently consistent at each decision point the business has specified, while the agent retains latitude in reading and handling the input.\u003C\u002Fp>\n\u003Ch2>Worked example: supplier bill capture\u003C\u002Fh2>\n\u003Cp>Jev determines whether an emailed document is a bill. Code matches the sender against existing suppliers, and a rule prevents the business itself or its owner from being recorded as the supplier. Code extracts the candidate dates and completes a missing year, and Jev selects between two plausible dates or abstains. Code checks for duplicates using the same key as the accounting system. A final rule family reads only the conclusions of the earlier families and, where all are clear, sends an approval request to a person. Following approval the agent may write the bill, but it cannot mark the task complete until the record it reads back matches what was approved. Each of the failures described above corresponds to one of these rule families.\u003C\u002Fp>\n\u003Ctable class=\"rule-family\">\n\u003Ccaption>Rule family: Bill can be written. One row permits the agent to act; every other row holds the case for a person.\u003C\u002Fcaption>\n\u003Cthead>\n\u003Ctr>\u003Cth scope=\"col\">Is a bill\u003C\u002Fth>\u003Cth scope=\"col\">Supplier valid\u003C\u002Fth>\u003Cth scope=\"col\">Invoice date resolved\u003C\u002Fth>\u003Cth scope=\"col\">Duplicate\u003C\u002Fth>\u003Cth scope=\"col\" class=\"conclusion\">Conclusion\u003C\u002Fth>\u003C\u002Ftr>\n\u003C\u002Fthead>\n\u003Ctbody>\n\u003Ctr>\u003Ctd>Yes\u003C\u002Ftd>\u003Ctd>Yes\u003C\u002Ftd>\u003Ctd>Yes\u003C\u002Ftd>\u003Ctd>No\u003C\u002Ftd>\u003Ctd class=\"conclusion\">Request approval\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>No or unsure\u003C\u002Ftd>\u003Ctd>–\u003C\u002Ftd>\u003Ctd>–\u003C\u002Ftd>\u003Ctd>–\u003C\u002Ftd>\u003Ctd class=\"conclusion hold\">Hold\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>–\u003C\u002Ftd>\u003Ctd>No\u003C\u002Ftd>\u003Ctd>–\u003C\u002Ftd>\u003Ctd>–\u003C\u002Ftd>\u003Ctd class=\"conclusion hold\">Hold\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>–\u003C\u002Ftd>\u003Ctd>–\u003C\u002Ftd>\u003Ctd>Unsure\u003C\u002Ftd>\u003Ctd>–\u003C\u002Ftd>\u003Ctd class=\"conclusion hold\">Hold\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>–\u003C\u002Ftd>\u003Ctd>–\u003C\u002Ftd>\u003Ctd>–\u003C\u002Ftd>\u003Ctd>Yes\u003C\u002Ftd>\u003Ctd class=\"conclusion hold\">Hold\u003C\u002Ftd>\u003C\u002Ftr>\n\u003C\u002Ftbody>\n\u003C\u002Ftable>\n\u003Ch2>Current position\u003C\u002Fh2>\n\u003Cp>Runtime enforcement of procedure loading and an approval gate before finance writes are in production. The decision model for bill capture has been designed and has not yet been built, and Jev has been tested offline for routing only. The next step is a shadow evaluation against past runs, and no accuracy figures will be reported until that evaluation is complete.\u003C\u002Fp>\n","von Halle, B. and Goldberg, L. (2009). \u003Cem>The Decision Model: A Business Logic Framework Linking Business and Technology.\u003C\u002Fem> Auerbach Publications.",1288,6,1793536248628]