Agentic Workflows vs Rule-Based Automation: Choosing the Right One

A rule-based workflow encodes the decision tree at design time. You enumerate the branches; the system executes them. Given the same input it produces the same output, forever.

An agentic workflow decides the path at run time. You give it a goal, a set of tools, and constraints, and it chooses what to do next based on what it observes. Given the same input it produces a similar output, usually.

That "usually" is the entire trade. You are buying flexibility with determinism.

Choose rules when most of the following hold:

• The inputs are structured — form submissions, API payloads, database records.
• The branches are enumerable. You can list them, even if there are eighty.
• The same input must always produce the same output. Compliance, billing, and anything auditable.
• Volume is high and margins are thin. A rules engine costs effectively nothing per execution.
• Failures must be diagnosable. You can trace exactly which rule fired.

Absentbox is a good example. Turning absence emails into structured status updates sounds like agent territory, but the useful behaviour is narrow and repetitive: recognise the message type, extract dates and person, create a record. Predictability is the feature. An agent would add cost and variance for no benefit.

Reach for an agent when the path genuinely cannot be enumerated:

• Inputs are unstructured and varied — free text, mixed documents, screenshots, messy real-world data.
• The exception rate is high. If more than roughly a fifth of cases fall outside your rules, the rules are no longer the system; the exception handling is.
• The work requires investigation. Look something up, decide what it means, look up something else based on that.
• Requirements change faster than you can ship rule updates.
• A good-enough answer with a human check beats no answer.

The clearest signal is a rules system where the exception queue has become someone's full-time job. That is a process telling you its branches were never enumerable.

In practice the best designs are rarely purely one or the other. The pattern we implement most often:

1. Rules handle the well-understood majority. Cheap, instant, auditable — typically 70 to 90 percent of volume.
2. An agent handles the exception queue instead of a person, with access to the same tools.
3. The agent's actions run through the same validation as the rules. It proposes; the deterministic layer enforces.
4. Resolved exceptions become new rules where a pattern repeats, so the deterministic share grows over time.

This gives you the economics of rules on the bulk of the work and the flexibility of an agent exactly where it is needed. It also keeps the agent inside a validation boundary, which is the single most important safety property.

Two ledgers, and teams usually only price the first.

Rules

Cheap to run, expensive to maintain as branches multiply. The failure mode is a slow accumulation of special cases until nobody can safely change anything.

Agents

Per-execution cost is real and scales with volume. Latency is seconds, not milliseconds. But the underrated costs are observability — you need to log decisions to debug anything — and evaluation, because without a test set you cannot change the prompt safely. Budget for both up front; they are not optional extras.

Ask one question: could you write the acceptance criteria as a flowchart before building?

If yes, build the flowchart. It will be faster, cheaper, and more reliable, and you will be able to explain its behaviour to an auditor.

If you genuinely cannot — if every attempt produces "and then it depends" — that is the signal that the flexibility is worth paying for.

The mistake we see most often is teams answering "no" because the flowchart would be tedious to draw, not because it is impossible. Tedious is not the same as unknowable, and an agent is an expensive way to avoid an afternoon of thinking.