Deterministic Orchestration in Production Workflows

Most production systems do not need an agent; they need a workflow.

Programming

Why Most Systems Need a Workflow

When a team starts building a system that handles a multi-step task, one of the first design decisions is whether the system should be an agent or a workflow. The two words can sound like different levels of sophistication, and it is tempting to assume the more autonomous option is the better one. For most production work, that assumption is wrong. The choice should be driven by a single question: can the sequence of steps be known in advance?

The central claim of this article is that most production systems do not need an agent. They need a workflow. The workflows that do useful work handle a predictable sequence of steps through deterministic orchestration, meaning the control flow is decided by explicit rules that the designer wrote and can inspect. The extra flexibility of an agent is only worth its cost when the designer genuinely cannot write those rules down.

The Question That Decides the Architecture

A workflow fits when the sequence of steps is predictable and can be deterministically orchestrated. An agent is justified only when the next step depends on the previous result in a way that cannot be captured in a routing decision. The distinction is about predictability, not size. Task complexity alone does not decide the choice. A task can have many steps and still be a workflow, provided the sequence of those steps can be known in advance.

Definition

Deterministic orchestration means that, given the same input and the same routing rules, the system takes the same path every time. Control flows from one step to the next according to rules the designer controls.

Notice the phrase the designer controls. In a deterministic workflow, nobody has to guess what the system will do next. The designer can read the rules, test them against sample inputs, and predict the path a task will take before the system ever runs. That property is what makes a workflow easy to test and to reason about.

How the Next Step Is Determined

The clearest way to see the difference between the two architectures is to ask who decides the next step, and when that decision is made. In a workflow, the decision is made by a routing rule that the designer wrote before the run began. When the workflow reaches a decision point, the result of that rule determines which step runs next. In an agent, the next step depends on the result of the previous step in a way the designer could not write down in advance, so the choice of action is left open until the system is running.

In each system, who or what decides the next step, and at what point in the run is that decision made?

Read the diagram column by column. The workflow column places the decision in a rule the designer can inspect before deployment. The agent column places the decision in a judgment made while the system runs. Both systems take several steps, but only the first can be fully specified and checked in advance.

Tracing a Routing Decision Through Fixed Steps

The following example shows a small workflow written in Python. The steps are fixed, and the routing decision is a plain rule. The category names and queue names are invented so you can follow the logic without any other context. Each incoming message is given a category, and the routing rule sends it to exactly one of three queues.

Code walkthrough

def route_message(category):
    if category == "billing":
        return "billing_queue"
    elif category == "technical":
        return "technical_queue"
    elif category == "account":
        return "account_queue"
    else:
        raise ValueError("unknown category: " + category)

print(route_message("technical"))

1
Line 1 defines route_message, which takes the category produced by an earlier step.
2
Lines 2 to 7 check the category against each known value in order. The first matching rule decides the destination.
3
Line 8 handles any category the rules do not name by stopping with an error rather than inventing a route.
4
Line 10 calls the function with technical. The rule for technical matches, so the function returns technical_queue, which is printed as the output.

The function has one input, the category, and returns the name of a queue
Each branch is a routing rule the designer wrote in advance
The else branch refuses inputs the rules do not cover, so the workflow never improvises a destination

Output

technical_queue

Notice what this code does not need. It does not decide, partway through, to try a new approach, or to plan a sequence that was not already written. The result of each step feeds a rule that was already defined. That is the defining feature of a workflow: the routing decision captures the dependency between steps, and the rule is simple enough to write down.

Following a Task Through the Router

Now trace what happens to one task as it moves through the system. A message arrives, the router examines its category, and the routing rule selects one branch. The diagram below shows a workflow in its simplest form. Every path out of the decision is written by the designer, and the system can only go to one of the three queues. Nothing about the route is improvised at run time.

When a task arrives, which branch does the router take, and what are the exact steps that follow in order?

Trace a message whose category is technical. It enters at the incoming node, reaches the routing rule, matches the technical branch, and ends in the technical queue. Feed the same message through the system a thousand times and it will follow the same path each time, because the same input and the same rules produce the same route. That repeatability is what deterministic orchestration means in practice.

When an Agent Is Justified

An agent becomes the appropriate choice in a narrower set of cases. The defining condition is that the next step depends on the result of the previous step in a way that cannot be captured in a routing decision. The designer cannot write, in advance, a rule that picks the right next action for every situation the system may encounter.

This check is the practical test to apply to any candidate task. Ask whether you could list every case the system will meet and write a rule for each one. If the honest answer is yes, even a long and tedious list, the task belongs to a workflow. If the cases are open-ended and the right next action truly cannot be fixed ahead of time, an agent may be justified.

Mistakes That Push Teams Toward Agents

The most common error is choosing an agent because it sounds more capable, without checking whether the sequence of steps is actually unknowable. The mistakes below come up repeatedly when teams make this choice.

Common mistake
Choosing an agent because it sounds more capable
What it looks like
A team proposes an agent to sort incoming customer messages into three queues.
Why it fails
Sounding capable is not the test. The question is whether the sequence of steps can be known in advance, and for sorting into a fixed set of queues it usually can.
Do this instead
Ask whether the routing rules can be written down. If they can, build a workflow.
Common mistake
Equating task complexity with unpredictability
What it looks like
A multi-stage invoice process with many steps is assumed to need an agent because it has many steps.
Why it fails
Task complexity alone does not decide the choice. A long sequence of known steps is still a predictable sequence.
Do this instead
Count the steps only as a rough signal, then check whether each decision point can be captured by a rule.
Common mistake
Declaring a sequence unknowable before listing the cases
Why it fails
Many tasks feel unpredictable only because the designer has not yet enumerated their cases.
Do this instead
List the cases and test whether a finite set of routing rules covers them before deciding.
Common mistake
Building an agent when the requirement is met by a simple rule
Why it fails
An agent adds run-time judgment that is harder to test, inspect, and predict, and that cost is only worth paying when the rules truly cannot be written.
Do this instead
Build the simpler workflow and add an agent only for the specific step whose next action truly cannot be routed by rule.

Practice Sorting Tasks

MEDIUM

For each task, decide whether it calls for a workflow or an agent. Task A: sorting incoming customer messages into billing, technical, and account queues. Task B: processing a batch of invoices where every invoice passes through the same fixed checks in the same order. Task C: a process where the correct next action after each result cannot be listed in advance because the cases are open-ended. For each task, state the single question you used to decide, and say whether you could draw the full set of steps before the system runs.

Hints

Start with the single question from this article: can the sequence of steps be known in advance?
A task with many steps can still be a workflow if every decision point can be captured by a rule.
Before choosing an agent for Task C, check whether a finite set of routing rules could cover its cases.

Your attempt (not saved)

Key Takeaways for Production Design

The architecture decision rests on one question about predictability. The points below summarize how to apply it.

At a glance

Most production systems do not need an agent; they need a workflow, because a workflow handles a predictable sequence of steps through explicit, inspectable rules.
In a workflow, the next step is determined by a routing rule the designer wrote in advance; in an agent, the next step depends on a result that cannot be captured in a routing decision.
Deterministic orchestration means the same input and the same routing rules always produce the same path through the system.
Task complexity alone does not decide the choice. Ask whether the sequence of steps can be known in advance, and check whether a finite set of rules could cover the cases before concluding otherwise.
Choosing an agent because it sounds more capable is the most common mistake; build an agent only when the designer genuinely cannot write the rules down.