Designing Decision Agents with DMN
Key Points
- Building large autonomous systems with agentic AI requires dedicated decision agents because LLMs alone are inconsistent, non‑transparent, and poor at decision‑making.
- Effective decision agents are created by combining business rules, decision platforms, and machine‑learning models within a formally designed decision model that serves as a visual blueprint.
- The industry‑standard notation for these blueprints is Decision Model and Notation (DMN), which uses a simple set of shapes and lines to capture complex decision logic.
- In a banking loan‑origination example, the overall “originate loan” decision is broken down into sub‑decisions, each represented as a rectangle in DMN, illustrating functional decomposition of the decision process.
- Despite its simplicity—primarily rectangles for decisions and a few connector lines—DMN scales to highly intricate scenarios, enabling clear, transparent, and maintainable decision agents.
Sections
- Designing Decision Agents with DMN - The speaker explains that large language models are unsuitable for reliable decision‑making in autonomous systems, so dedicated decision agents—combining business rules, ML, and other technologies—must be crafted using visual decision models and the Decision Model and Notation (DMN) standard.
- Decision Diagram for Credit Origination - The speaker explains how to model a loan‑origination decision using a diagram where credit‑worthiness and vehicle information are shown as input ovals (JSON‑style objects) feeding three sub‑decision nodes via dependency arrows, culminating in the decision to lend money.
- Untitled Section
- Decision Tables and FEEL in DMN - The speaker explains how decision tables—enhanced with the FEEL expression language—offer flexible, reusable, and well‑structured declarative logic within DMN models, reducing duplication and centralizing rule management.
- Origination Decision Service Architecture - The speaker outlines a layered origination service where a decision agent consumes vehicle, customer, and an external default‑prediction model to compute loan eligibility and return a yes/no/maybe response.
Full Transcript
# Designing Decision Agents with DMN **Source:** [https://www.youtube.com/watch?v=Wtpwva8t1vs](https://www.youtube.com/watch?v=Wtpwva8t1vs) **Duration:** 00:20:39 ## Summary - Building large autonomous systems with agentic AI requires dedicated decision agents because LLMs alone are inconsistent, non‑transparent, and poor at decision‑making. - Effective decision agents are created by combining business rules, decision platforms, and machine‑learning models within a formally designed decision model that serves as a visual blueprint. - The industry‑standard notation for these blueprints is Decision Model and Notation (DMN), which uses a simple set of shapes and lines to capture complex decision logic. - In a banking loan‑origination example, the overall “originate loan” decision is broken down into sub‑decisions, each represented as a rectangle in DMN, illustrating functional decomposition of the decision process. - Despite its simplicity—primarily rectangles for decisions and a few connector lines—DMN scales to highly intricate scenarios, enabling clear, transparent, and maintainable decision agents. ## Sections - [00:00:00](https://www.youtube.com/watch?v=Wtpwva8t1vs&t=0s) **Designing Decision Agents with DMN** - The speaker explains that large language models are unsuitable for reliable decision‑making in autonomous systems, so dedicated decision agents—combining business rules, ML, and other technologies—must be crafted using visual decision models and the Decision Model and Notation (DMN) standard. - [00:03:08](https://www.youtube.com/watch?v=Wtpwva8t1vs&t=188s) **Decision Diagram for Credit Origination** - The speaker explains how to model a loan‑origination decision using a diagram where credit‑worthiness and vehicle information are shown as input ovals (JSON‑style objects) feeding three sub‑decision nodes via dependency arrows, culminating in the decision to lend money. - [00:06:42](https://www.youtube.com/watch?v=Wtpwva8t1vs&t=402s) **Untitled Section** - - [00:11:59](https://www.youtube.com/watch?v=Wtpwva8t1vs&t=719s) **Decision Tables and FEEL in DMN** - The speaker explains how decision tables—enhanced with the FEEL expression language—offer flexible, reusable, and well‑structured declarative logic within DMN models, reducing duplication and centralizing rule management. - [00:16:32](https://www.youtube.com/watch?v=Wtpwva8t1vs&t=992s) **Origination Decision Service Architecture** - The speaker outlines a layered origination service where a decision agent consumes vehicle, customer, and an external default‑prediction model to compute loan eligibility and return a yes/no/maybe response. ## Full Transcript
If you're using agentic AI to build large autonomous systems, you're going to need to build
decision agents. These are agents in your agentic framework that literally make decisions. And it
turns out the large language models are not very good at making decisions. They're not consistent.
They're not transparent. And so you need to use a different set of technologies, business rules,
decision platforms, machine learning, uh, and combine those technologies into decision agents.
Now, decision agents need to be designed. You have to go through a design exercise to say exactly how
do I want this decision agent to work. And we've been building decision agents, decision services
for many years. And when it comes to the best practice approach to designing them, there's
a clear winner. You want to build a decision model. And decision model is a visual blueprint
that lays out exactly how your decision agent is going to behave and lets you combine these
technologies effectively uh to make the decision correctly. And the best notation for this is
actually called the decision model and notation. It's an industry standard that lays out a set of
shapes and lines and and semantics that enable you to build a visual blueprint of exactly how
your decision should work. Now, uh I'm going to use an example here. Okay. So, let's imagine that
I'm a bank and I'm going to lend money to someone who wants to buy a boat. So, I have to decide I
have to have a decision agent that decides this. An origination decision as a bank calls it. So,
I have to originate this loan. That is to say, I have to decide if I'm going to lend you the money
and if I am going to lend you the money on what terms of how long and so on. So, I have to make
this origination decision. And so I'm going to walk through how you can use DMN to lay out this
decision and describe all the elements of your decision. So uh DMN is great for doing this. It
uses quite literally three shapes and two lines to do the vast majority of the heavy lifting.
It can seem like a very simple notation, but it is remarkably effective and scales to enormously
complex decisions like loan origination. So let's start with the shapes. So the first
shape you need to know is a rectangle. So all decisions and subdecisions and sub subdecisions
are all rectangles. Each decision is a if you can think of it as a question that has to be answered
and that's represented using a decision. So let's start building an example here. So let's take our
origination decision. Say I've got to originate this line. That's the decision I've got to take.
Not enough room for the word originate. So I've got to decide if I'm going to originate the line.
Well, uh how do I do that? Well, I've got to think about the pieces of that decision. I've
got to decompose that decision into subdecisions. So, I can break down my problem itself. Functional
decomposition technique and say, well, in order to decide if I'm going to lend you the money,
I have to decide what type of vehicle you're trying to borrow money because there are lots of
kinds of vehicles. Boats are only one. I've got to decide what your loan to value ratio is. So,
you know, how much are you trying to borrow? What's what do I think the boat's really worth?
What does that look like? I have to decide what your credit worthiness is. So, how good is your
credit? How how likely are you to pay me back? And then perhaps I also need to know some information
about the vehicle. So, in this case, uh I'm going to draw that as an over. Now, you notice that the
the three subdivisions are drawn as decisions because they are also decisions. Each decision,
each subdecision is a specific question that has to be answered using a specific set of inputs.
But I can also show input data as I have here. I've shown vehicle. Now vehicles in an oval. Ovals
represent input data. And you can think of each input data as like a JSON object. It's it could
be a single field, but it could also be a whole set of information about a vehicle or a customer.
So you might have what kind of vehicle it is, how big it is, how old it is, how much it weighs, and
all sorts of other information that describes this input data. Now uh to show that these are part and
parcel of how I originate I use a solid arrow like this and this is called uh we call these sort of
dependency links. So you can think of these things as saying well in order to make the origination
decision I need some inputs decisions are pick a set of inputs decide what the right output is. In
this case the output is and we're going to lend you the money. So what are the inputs? Well, the
inputs in this case are the vehicle information and the answers to three other questions. What
type of vehicle is it? What's your loan to value ratio? And how creditworthy are you? And those
are shown using these links. So these are we use a couple of different terms for it. One is
um you know it's formal name is that it is an information requirement and we call we call
all these all the links requirement links but uh you can also think of it as a subdecision or as a
dependency. So we're saying that we can't make the origination decision until we've made these other
decisions. We are dependent on their answers. So it's a dependency. Now um I can go further. I can
keep decomposing this. So I can say well in order to do your creditworthiness I need to know what
credit tier you're in. Are you a tier A, tier B, TC, tier C? I need to know uh what debts you have
and perhaps I need to know what assets you have. And so um I've got these dependencies. So this
decision is dependent on those three decisions as well. And perhaps I'm going to use customer
data to do those assessments. So I've got customer data and I can show that I'm using it in a variety
of different ways. Now these can look quite hierarchical like trees, but they're actually
directed as graphs networks. So you can reuse things. You can reuse customers as I show here.
You could have another decision completely like um what promotions am I going to send someone
uh and that could depend on their credit tier as well. So you can reuse decisions across multiple
um you know parent decisions. You can reuse core concepts like credit tier define it once and use
it in lots of different places. Uh obviously these diagrams can get very large. So the other
thing you can do with DMN is draw lots of these diagrams. Uh these are genuine objects. Each
object can be used on many diagrams. So I could have the credit tier decision be on two different
diagrams and it would be the same credit tier object. So they are not pictures, they are views
into a network. And so there's a an underlying network of everything and how everything is
connected and then a series of diagrams that represent different pieces of that. Now these
are the sort of two core shapes and it shows me uh what information is is used in my decision.
But I also want to be able to capture why that is my decision. So the third shape that I need is
what's called a knowledge source. Um that's meant to be like a document shape. Um humorously enough,
we tried really hard to make them easy to draw and that one we didn't really manage. Uh and these are
connected to um other shapes using what's called an authority requirement because you can think of
these things as authorities. So um you think of something like uh a policy document is an
authority for a decision. we make this decision a certain way because of its authorities. And
those authorities uh you know you might have something like um the the the the risk policy
might be how you describe your risk tiers. So you can keep track of why your decision model has the
pieces it has. What are the pieces that are in here and why are those the pieces? Now these
uh models allow you to build very robust uh you know understandings of your decision. You can
break it down into smaller and smaller pieces and you can really start to lay out exactly how your
decisions used. You can say well you know the vehicle information is actually how I get the
type as well and perhaps I have to link yeah I can start to link various things together so I
can't start to build a rich understanding of how information flows through my decision agent. Now
DMN has a couple of other sort of minor shapes that you can use. There's a group shape. You can
draw like groups around things so that you can uh show that certain things are related to each
other. You can annotate things with an annotation. Um and those are really just a sort of ways of of
marking up diagrams so you can explain it better. Uh you can also show that you've got reusable sort
of code fragments if you like sort of functions that you're reusing. Uh and these are called
business knowledge models and they another hard shape to draw. Um, and these basically
support your decision-making so that if you have a reusable function like calculating the monthly
payment from a debt or something like that or the likely monthly income from an asset, you can have
that as a BKM and you can reuse it across many diagrams and and across many decisions. So you
can build essentially you can diagram reusable functions as business knowledge models. So,
you know, these are the core shapes, the three shapes and two lines that that describes the
whole structure of the decision, everything you need to know about the decision really. The rest
is really about enhancing and refining it. Now, this obviously lets you lay out the whole decision
structure. But one of the things you're going to want to do is you're going to want to say, well,
um, where in this model, you know, I I got to specify the logic for all of this. I've got to
define exactly how each of these decisions are actually made. And I do that typically
by writing logic for each piece of the of the diagram. The the most common representation is
a decision table. And a decision table, you know, literally is a is a tabular layout. Well, I just
draw an example here. Um, you know, and it's got a sort of a header and it's got a it's got basically
condition columns over here on on the left and an answer column on the right. So, if we're doing the
origination decision, the answer here is well, am I going to originate it or not? Right? That's my
answer as to what I'm trying to decide in that decision. And my inputs are basically driven
by my dependency network. So I've got these four dependencies here. I'm dependent on the vehicle,
the type decision, the loan to value, and the credit. So I have four columns in this case
in my di- in my in my table. I have the is the vehicle new or used, right? That's a property of
the vehicle. So it's one of the properties, one of the bits of information inside that input data. I
have the type. So I have to decide how I classify this particular vehicle. Is it a boat, an RV,
an ATV? How do I classify it? I have to calculate your LTV, your loan to value ratio, so I can use
that. And I have to know how creditworthy you are. And only if I know some combin those things. Can I
reliably decide whether I'm going to originate you or not? And so in a decision table, you start off
with these columns that match your model. You have an answer. You know what you're trying to answer,
what question you're trying to answer, and you start writing rows. So you might say, well,
if it's a new boat, so it's new and I think it's a boat. I consider it a boat. So I have
an amphibious vehicle, maybe I think those are boats. If it's a boat, I think it's a boat and
so on. If you have uh a pretty, you know, I've classified the loan to value rating in this case
is good and your credit is excellent, you know, or good, then I'm going to basically say, yeah,
I'm going to approve your loan. And then perhaps I say, "But if it's a used boat,
yeah, you still need to have the good LTV, but now you need to have excellent credit. Can't write
excellent in the room." Uh, and then I'll still approve it. So I'm I'm specifying the different
rules for how I approve loans. So in each case, you can look at the rule and say the each
row is a rule essentially. So in this case, if it's a new boat with a good loan to value ratio,
then a person with excellent and good or good credit is approved to buy it. Each one of these
is a row. So you can think of the columns as anded together. All of them have to be true. And each
row is essentially like an or. You can think of each one as an alternative way to get an answer.
And I can fill this out. I can put dashes in if I don't care what the value is for this particular
scenario. And I can lay out my scenarios uh so that I can approve it. Now there's a lot
more complexity to a decision table. There are different kinds of decision tables. You can have
decision tables to come up with multiple answers. You can process the rows in different orders. Uh
there's a whole syntax that you can embed in the decision tables. It's called the friendly enough
expression language or feel. Uh and so feel is another whole part of the DMA model that enables
you to express the logic behind these pieces. Now many of the decisions in a model like this will be
decision tables. Some uh will be more traditional if then else kind of logic. Um others might be
uh functions or calculations that you're writing. Others still might use business knowledge models
to uh reuse functions that have been defined elsewhere and potentially parameterize the
code. Uh so you have a wide range of development options all within the context of this declarative
model for how your decision is supposed to work. It turns out these models are really really good
at at breaking down the logic and helping you normalize it. So you don't write logic that
repeats itself. You write the logic in one place. There's one place to go when you need to change
the logic. It's very very uh well structured logic that you get out of it. So you can manage it,
expose it through low code environments to non-technical users. Uh review it with
domain experts. It's really easy to go through these diagrams and have someone who actually
knows what your credit risk policy is say yes that's how we make the decision. Now,
not only do these models help you structure the logic for these models, which obviously is really
a key element of a decision agent, uh they also enable you to show how you're going to consume non
uh non-ruules-based pieces. When you talk about decision agents, we often talk about needing to
consume analytics, machine learning, predictions of one kind or another. And I can do that in a in
a decision model too. So, I can have a decision. Let's say I have a decision like um your default
risk. Now, how likely are you to default? That's part of my creditworthiness decision. Well, I may
not want to write rules for that. I might want to use machine learning to make a prediction. So,
I'm going to analyze all my credit history risk data and then I'm going to say, well,
build a model, an algorithm that predicts how likely you are to default on your loan,
and we'll consume that as part of your creditworthiness assessment. This is a machine
learning model. right now um I don't want to write rules for that because I've got a machine learning
model. So there are two ways in DMN that you can bring that in. You can have the decision in your
model and then you can say um I can use what's called the predictive model markup language or
PMML which is like an XML representation of the algorithm predictive algorithm and I can import
that and run it as a function and run that as my decision. Uh there's also a standard called ONNX,
the open neural network exchange, standard which is about how you exchange graphs for
machine learning models, neural networks, live language models uh between different modeling
platforms and lots of execution platforms support executing analytics models too. So you can have a
decision in your model that produces a score or a number that you consume as part of your decision
modeling but you didn't write any logic for it. you're just pointing it at a pre-existing machine
learning definition that your data scientists have provided you with. So I can I can do that too. Now
the last step I have to do is I have to somehow be able to package all of this up and deploy it as
a decision agent. Now some decision platforms uh don't really know how DMN works. So this is just
a really good design technique. This is how you design what you're going to put in there and you
use it as a requirements diagram. Just like you do a entity diagram for a database design, you would
do a DMN diagram for a decision engine. But some of them actually consume decision models. So you
can package up the whole model in XML well-defined industry standard notation and you can pass that
XML packet to the engine. The engine will execute it for you. Now to do that you have to obviously
has specified all of the logic and you also have to tell it what the packages are and DMN
has a final uh shape for that called a decision service. So you can think of a decision service
as it's a a restful service. Packages up and says this is what's going inside this service and and
it enables me then to define the the interface for that service and obviously then package that
up as a tool through a tools interface and MCP as an agent as a decision agent. So what I do is I
draw a box around all the things I'm going to have inside my service and then I draw another line to
say these are the ones. So this is the invocable decision. This is the decision I'm trying to make.
So I have an origination service. Obviously it makes the origination decision. So that's in
the top of the box. The rest of the stuff below the line is essentially the rest of the logic
that needs to be packaged into this service. So you can see all my calculations for type, LTV,
credit tier, debit, asset, all of those things are part and parcel of my decision agent. It knows how
to do those things. Every requirements line that crosses the border. So the links from vehicle,
the links from customer define the interface for the decisions. This is the data you have to give
the decision agent in order for it to make the decision for you. And you'll notice in this case
the default uh probability of default is outside the boundary. Well, that's because it's a separate
endpoint. It's deployed as its own analytical and machine learning agent and I'm going to consume
the result of that scoring exercise that that endpoint and use it as an input to my decision
service. So mechanically, if I'm a workflow agent and I'm calling this, I'm going to assemble the
vehicle data and the customer data. I'm going to call the default prediction agent and then
I'm going to pass the default prediction the customer and the vehicle and I'm going to pass
it all to my decision agent and say tell me if I should originate this customer for this vehicle
and it will give me an answer yes or no or maybe so that enables my agents then to execute. So I
can define this very robust very visual easy to review way to specify decision agents and then
I can if I fully specify them package them up and pass them often to a direct engine. So there are a
number of open source and commercial engines that just take DMN models and execute them for you. So
if I go through this exercise now what I've done is instead of using an LLM to make a decision and
taking all the risk of an LLM hallucinating or being inconsistent or whatever I have basically
built a hardened vi- reviewable and confirmable definition of how the decision agent should work.
But I can also use LLM to help me build that. So if you think about it um LLMs are really
good at reading a lot of material and helping you understand what's in it. So if I've got an LLM,
well, I might have a whole set of documents that describe these things. So I might have
policy documents, um, requirements documents, narratives of interviews with experts. All of
those documents can be consumed with an LLM and to help me build one of these models. So
you can ask it questions like, well, how will you structure this? What information is referenced in
this document? So you can consume your documents, process them with an LLM and use that to help you
build the right model. Many LLMs are getting trained on code. So if you've got a legacy
system that implements some of this, you may well be able to train an LLM to read that code
or buy an LM that can read that code and help you understand the logic that's embodied in that code
so that you can replicate that logic easily in your large language model. So there's there's a
variety of different ways to use large language models to help you with this. Um, you know,
there's there's some interesting work going on to say if I've got a version of my decision agent
already built and I have a document that it was based on and I get a new version of that document,
can you tell me what the differences are? LLMs are really good at summarizing the differences between
two documents uh in in a usable way. Uh, and that enables you then to say what changes do I have to
make to my decision agent in order to go ahead and update my decision agent. So, it's not like
LLMs have no role in all of this. you you're still going to want to use RLMs as part of your analysis
technique, as part of your requirements gathering to sort of accelerate that process of consuming
all the raw material that your organization has about how this decision should be made. So you
can turn it into a decision model, but you want to harden the decision model. uh make it a formal
definition of your decision agents because it's really important that your decision agents work
reliably, work transparently, uh consume uh probabilistic predictions effectively, uh and
do all this in a way that can be exposed then as a decision agent for use by the rest of your agents.