Designing Routing Decisions

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

Programming

A Design Question Worth Asking First

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 that 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?

EASY

Pause before reading on. Pick a task you might automate, such as sorting incoming customer messages or processing a batch of invoices. Could you draw the full set of steps on paper before the system ever runs? Keep your answer in mind, because the rest of this article turns on that distinction.

Hints

Think about the first step, then the step after it, and ask whether the step after that depends on something you cannot know yet.
If every possible path can be written as a rule, the sequence is knowable in advance.

Your attempt (not saved)

Who Chooses the Next Step

The central claim is that most production systems do not need an agent. They need a workflow. A workflow handles a predictable sequence of steps through deterministic orchestration, meaning the control flow is decided by explicit rules that the designer wrote and can inspect. 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.

When a workflow reaches a decision point, the decision is made by a routing rule, and the result of that rule determines which step runs next. Every path out of the decision is written by the designer. Nothing about the route is improvised at run time, which is why a workflow is easy to test and to reason about.

Definition

An agent is the more flexible option, in which the next step depends on the result of the previous step in a way that cannot be captured in a routing decision. In a workflow the next step is fixed by rules written in advance. In an agent the next step is determined by the situation as it unfolds.

Tracing a Message Through a Routing Rule

The source describes a small workflow in which the steps are fixed and the routing decision is a plain rule. The example below is an original illustration with invented category and queue names. Read it as a trace: each call moves one message through a single decision and lands in exactly one queue.

Code walkthrough

def route_message(category):
    if category == "billing":
        return "billing_queue"
    elif category == "technical":
        return "support_queue"
    else:
        return "sales_queue"

print(route_message("technical"))

1
The function receives the category string and checks it against the billing rule first.
2
A category of technical fails the billing check, so the elif rule is tested next.
3
The technical rule matches, so the function returns support_queue and nothing else runs.
4
The print call displays that queue name, which is the final destination of the message.

The function takes one value, the category assigned to the message
Each branch is a routing rule written in advance by the designer
Exactly one return statement runs for any given category

Output

support_queue

What do you think happens?

What does route_message("billing") return?

Reveal answer

Answer:

billing_queue

The first if rule matches the category billing, so the function returns billing_queue and the later branches are never checked.

Notice what this code does not need. It does not decide partway through to try a new approach, and it does not plan a sequence that was not already written. The result of the 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 an Invoice Through a Predictable Pipeline

Batch invoice processing is a useful case for tracing, because its steps can be listed in advance. The sequence below is an original illustration. Each invoice passes through the same steps in the same order, and only one decision point changes its route.

Trace a single invoice of 320 through the pipeline. It is received, its amount is extracted, and the amount check finds it under 500, so the routing rule sends it to auto-approval. An invoice of 1,200 would follow the identical first two steps and then take the manager review branch. The designer can list every possible path before the system runs, which is the signature of a task that belongs in a workflow.

The Predictability Test

Task complexity alone does not decide the choice. A task can have many steps and still be a workflow, and a task can look simple and still need an agent. The key question is whether the sequence can be known in advance. The source also gives a practical check: before concluding that a sequence is unknowable, ask whether a finite set of routing rules could cover it. If it could, the task is a workflow, even if writing those rules takes effort.

Question	Points toward a workflow	Points toward an agent
Can the full set of steps be drawn before the system runs?	Yes	No
Does the next step depend only on a result a rule can check?	Yes	No, the dependency cannot be written as a rule
Would the same input always take the same path?	Yes, given the same rules	Not necessarily
Could a finite set of routing rules cover every case?	Yes, even if the rules take effort	No, the designer cannot write them in advance

Checks for deciding between a workflow and an agent, based on the predictability of the steps

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 following mistakes come up repeatedly when teams make this choice.

Common mistake
Choosing an agent because the autonomous option sounds more sophisticated
What it looks like
A team picks an agent for invoice routing because agents seem like the advanced choice.
Why it fails
The source states that the more autonomous option is not the better one for most production work, and the choice should follow from whether the sequence can be known in advance.
Do this instead
Ask whether the full set of steps can be drawn beforehand, and choose a workflow if it can.
Common mistake
Deciding by task complexity rather than predictability
What it looks like
A long multi-step batch job is assumed to need an agent simply because it has many steps.
Why it fails
Task complexity alone does not decide the choice. Many steps can still follow a fixed order.
Do this instead
Test whether a finite set of routing rules could cover every path through the task.
Common mistake
Treating unlisted cases as proof that a sequence is unknowable
What it looks like
A designer has not yet written down the edge cases for customer messages and concludes an agent is needed.
Why it fails
Many tasks feel unpredictable only because the cases have not been listed yet.
Do this instead
List the cases first and check whether they can be captured by routing rules before deciding.
Common mistake
Assuming an agent makes a workflow's rules unnecessary
Why it fails
A workflow's value lies in rules the designer can inspect and test, and those rules disappear when the decision is left to the system at run time.
Do this instead
When a rule can express the dependency, write the rule and keep the workflow.

Classifying Three Production Tasks

MEDIUM

For each task, decide whether it calls for a workflow or an agent: (a) sorting incoming customer messages into billing, technical, or sales queues using a fixed set of categories; (b) a support assistant that must choose its next action based on what a previous action revealed, in a situation no one has listed in advance; (c) processing a batch of invoices where every invoice passes the same validation steps and is routed by amount. Explain your answer by naming the question each task answers about its steps.