Agentic Essentials #2: Agentic Vs Linear Process Vs DMN

The first agentic essentials article was about how agentic orchestration works. This one is about when to use agentic orchestration at all. That is a different question, and I think it matters more. Teams often reach for AI before they have confirmed it fits the problem they actually have.

In this article I compare three problem shapes in the same baggage-support world: a fixed workflow, a rule-based decision, and a messy inbound email that neither of those can handle cleanly. The rule-based part uses DMN, short for Decision Model and Notation, which is a standard way to write business decisions as explicit rule tables. The goal is one honest threshold for when agentic orchestration is the right call and when it is not. I will continue to use the missing-baggage example here.

All three examples below stay in the same baggage-support world. What changes is how much the system already knows when the case arrives, and how hard the next step is to pre-model.

Imagine the passenger uses the portal. They pick “missing baggage”, enter a booking number and bag tag, and confirm their contact details. From there, the process follows the same order every time: query for the bag, contact the last known airport, provide a voucher and then update the passenger.

The steps are known before the case starts. I would not add AI here. Every model call adds latency and cost. On a step with no judgment in it, that overhead buys you nothing.

Now look at the next action decision. A policy might allow different voucher amounts based on route length or delay. That is a business rule, not an open-ended judgment call.

This is where DMN fits better than AI. You put the policy into a decision table. The engine evaluates the inputs and returns a result. You can also explain later exactly why the outcome was accepted or rejected.

Every rule is visible. Every outcome is traceable. No model call needed. If you want to go deeper on DMN, I covered it in a separate article.

Now take the messy version. The passenger sends a plain email. Their bag didn’t arrive, they have moved to a different hotel, and they only have an old photo of the tag.

The first useful step is not obvious. The system might need to check whether a claim already exists, ask only for the missing hotel address, and then continue the search. That is a much better experience than a rigid form that asks for everything upfront or a decision table that refuses to run without clean input. That is where agentic orchestration starts to make sense. The AI works within guardrails and has access to a small set of approved tools, but it decides which tool to use first based on reading the message.

But messy intake is only one case. The same reasoning applies mid-process. A process engine follows the path it was given. A rule table matches conditions to outputs. Neither one reasons. If the passenger’s next message mentions that their medication was in the bag, a fixed flow has no branch for that. A DMN table has no row for it either. An agentic step can read the message, understand what changed, and act on it, for example by sending a care voucher or escalating the priority, without a developer having anticipated every situation the passenger might bring up.

This part often gets skipped in demos. AI adds real overhead:

• Every model call costs money.

• Responses are slower than a rule table.

• The behavior needs evaluation on real, messy inputs.

• Operations teams get one more thing to monitor.

If there are only a few known next steps, that overhead is usually not worth it. A workflow or a decision table will be easier to run and easier to explain.

Do not start from “where can I add AI?” Start from “where does structured modeling stop being enough?” For most processes, a workflow or a rule table is already the right answer.

• Many processes just don’t need AI. If the path is known, use deterministic BPMN. If the decision has clear rules, use DMN.

• Agentic orchestration fits when the input is messy, the next step depends on interpretation, or the situation can change mid-case in ways that were never modelled.

• The fundamental difference is reasoning. A process engine follows its path. A rule table matches its conditions. An LLM reads the situation and decides what to do next.

• AI adds real cost and operational overhead. Start from the problem, not the technology.

Once you decide that agentic orchestration is the right fit, the next question is practical: how does the AI step actually call tools and systems from inside the process? That is what the next article is about.