Agent workflows: a fixed path with one step that thinks

Most systems that survive contact with production are neither a pure workflow nor a pure agent. They are a fixed sequence, written in advance and orchestrated by ordinary tooling, with exactly one step in the middle where the next action genuinely cannot be known until the situation is examined. Everything before and after that step is deterministic: it reads a file, validates a field, writes a record, notifies somebody. Those parts are testable, cheap, fast and debuggable by whoever is on call, and making them agentic would buy unpredictability on the portions of the job that never had any. The interesting design question is therefore not whether to use an agent. It is which single step deserves to be the flexible one, and the answer is almost always the point where the branches stop being countable.

Why this shape keeps winning

It concentrates the unpredictability. A system with one agentic step has one place where behaviour varies, which is one place to trace, one place to cap, one place to evaluate. A system that is agentic throughout has variation everywhere and no fixed point to reason from.

It also keeps the cost proportionate. The expensive part of an agent is the loop, and confining the loop to a single step means the deterministic majority of the work costs what deterministic work costs. On a five-step process, that difference is frequently a factor of four on the bill.

And it keeps the system operable by people who did not build it. The surrounding workflow uses orchestration your team already runs, with the failure modes they already know. Only one component behaves unusually, and the runbook for it can be one page.

Finding the step that should think

Write the process out as a sequence, on paper, with the branches named. Most teams can, and are mildly surprised that they can, because the feeling that a process is too complicated to sequence usually comes from never having tried.

Then look for where the branch list stops being finite. There is usually exactly one such point, and it has one of two causes. The input at that point is arbitrary human text, so the cases cannot be enumerated. Or the next action depends on what was found in a lookup, across a space too wide to encode.

If you find no such point, you do not need an agent at all and the workflow is the whole answer. If you find three, look harder: two of them are frequently the same decision expressed at different stages, and merging them is cheaper than making three steps flexible.

What the flexible step needs around it

A contract. The step should take defined inputs and return a defined shape, so the surrounding workflow can validate what came back. An agentic step that returns free text into a deterministic pipeline has moved the unpredictability downstream rather than containing it.

A cap. Maximum steps, maximum time, maximum spend. Not for efficiency: to prevent the run that explores for an hour. The cap should sit well above normal operation and raise an alert when it fires.

A defined behaviour when it fails. The workflow needs to know what to do when the step returns nothing usable, and the answer is almost always to route to a person rather than to retry indefinitely. A system that silently retries is a system whose cost is unbounded.

Evaluating a system with one flexible step

The evaluation set can be smaller and sharper than for a full agent, because only one component varies. Cases target that step: given this input at this point, what should come back. The deterministic parts are covered by ordinary tests, which are cheaper to write and faster to run.

That separation has a practical benefit teams notice immediately. When quality drops, you know where to look. In a system where every step reasons, a regression could have come from anywhere, and the investigation starts with narrowing down rather than with fixing.

It also makes provider changes survivable. When the model behind the flexible step is updated, the evaluation set for that step tells you whether anything moved, and nothing else in the system is affected. Migrating a fully agentic system is a much larger exercise, because the change propagates through every decision it makes.

When one step is not enough

Genuinely investigative work does not fit this shape. Finding why two systems disagree, or assembling evidence from several places where each finding changes where to look next, is a task whose whole structure is decided at runtime.

For those, a fuller agent is the right design, and the compensating discipline is on permissions rather than on structure: constrain what it can touch, keep every action reversible, and put a person on anything that is not. That is covered on our page about agent security, and it is the trade being made when the fixed sequence is abandoned.

The mistake to avoid is arriving at a full agent by accretion. A workflow that acquires a second flexible step, then a third, has become something else without anyone deciding, and the testing, tracing and approval assumptions made for the original design no longer hold.

Questions people actually ask

Why not make the whole thing an agent?

Because most of the sequence is genuinely known. The steps that read a file, validate a field, write a record and notify someone do not need deciding at runtime, and making them agentic buys unpredictability, cost and latency on parts of the job that had none of those problems.

How do I find the step that should be flexible?

Look for where the branches stop being countable. Most processes have one point where the next action depends on something that cannot be enumerated in advance, usually because the input is arbitrary human text or because the answer requires looking something up first. That is the step.

Can there be more than one flexible step?

Yes, and each one multiplies the space of behaviours you have to reason about, so the second should be added deliberately rather than by drift. Two agentic steps in a five-step workflow is a different system to test and debug than one, and the difference is not linear.

Does this work with existing orchestration tools?

Usually, because the surrounding workflow is ordinary orchestration and the flexible step is a service call like any other. That is part of the appeal: the deterministic majority of the system uses tooling your team already operates and already knows how to debug at three in the morning.

Read next

Sources

Radif Partners

Written and maintained by Radif Partners

Applied AI deployment practice · Forward deployed engineering

Covers 2026, · last reviewed 2026-09-24