Not Every Workflow Needs an Agent

An agent is not the next version of a workflow. It is a different architectural trade-off.

That distinction gets lost in most roadmap conversations, and the cost of losing it is real: teams migrate working deterministic processes to agents because the agent sounds more advanced, and inherit a set of problems the original process did not have.

Two different guarantees

A deterministic workflow gives us predictability. We define the possible paths, control how failures are handled, and know what the system is allowed to do. When something goes wrong we can point at the branch that produced it.

An agent gives us adaptability. It can examine the available context, choose the next action, observe the result, and change its approach. When the situation is one nobody anticipated, that flexibility is the whole point.

These are not two rungs on a ladder. They are two different guarantees, and you cannot have both at full strength in the same step.

What adaptability actually costs

Every decision delegated to an agent introduces four things at once:

• More possible execution paths. The set of things the system might do is no longer enumerable, which changes how you test it.
• A larger evaluation surface. You are no longer checking whether one output is correct; you are checking whether a range of behaviors stays acceptable.
• Broader permission concerns. A step that can choose its own action needs boundaries drawn around what it is allowed to reach.
• Less predictable cost and latency. A path that adapts is a path whose length you do not know in advance.

None of these are reasons to avoid agents. They are the invoice that arrives with the flexibility, and it should be a deliberate purchase.

Why the maturity model is wrong

This is why I do not read:

Assistant → Workflow → Agent

as a progression.

An assistant leaves the next decision with the user. A workflow follows a path designed in advance. An agent chooses the next step within defined boundaries.

Those are three different distributions of responsibility, not three levels of sophistication. A system that leaves a decision with a person is not immature. In some processes it is the only defensible design.

The architectural question is not which one is more advanced. It is where the process genuinely requires judgment.

Where the line actually falls

Most real processes are mixed, and drawing the line inside a single process is more useful than choosing one model for the whole thing.

Take a support request. Classification can be deterministic: the categories are known and the routing rules are stable. Retrieving the customer's data is deterministic. Approval against a threshold is deterministic; that is a condition, not a judgment.

Agency may only be necessary at one point in that process: when the system needs to investigate an unfamiliar issue across several tools and adapt based on what it finds. That is the step where the correct next action genuinely cannot be written down in advance, because it depends on what the previous step revealed.

Everything around that step can stay fixed. The agent does not need to own the workflow to be useful in it.

A default worth stating

Start deterministic. Introduce agency only where the fixed path stops being useful.

That default is doing something specific: it puts the burden of proof on autonomy. Rather than asking where could we use an agent here, it asks where does the predefined path actually break down. Those two questions produce very different architectures, and only one of them tends to survive contact with a production incident.

The signal to watch for is a workflow that keeps growing branches. When every new case adds another condition, and the conditions start contradicting each other, the fixed path has stopped describing the problem. That is usually the honest moment to introduce judgment, not the kickoff meeting.