A client came to us with an agent that approved expense reports. The process was simple and had been written down in a wiki for years: read the report, check it against policy, flag anything over the limit, route to the right approver, send the notification. Four or five steps, same order every time, no surprises.
They had built it as a single autonomous agent with five tools and a prompt that said, roughly, "approve this expense report following company policy." It worked about four times out of five. The fifth time it would skip the policy check, or notify the wrong approver, or call the policy tool twice and then stop. Same input shape, different behavior. The team had spent a month tightening the prompt and adding validation, and the failure rate had barely moved.
The problem was not the prompt. The problem was that they had asked a language model to rediscover a fixed pipeline on every single run. The steps never changed. The order never changed. There was nothing to decide about the structure of the work, and yet they were paying for a fresh structural decision on every report, and every decision was a fresh chance to get it wrong.
We rebuilt it as a flow in two days. The failure rate dropped to near zero, the cost dropped by two thirds, and for the first time the team could look at a failed run and say exactly which step broke.
What a flow actually is
A flow is deterministic orchestration. The control structure lives in code, not in the model's head. You write down the steps, the order, the branches, and the state that passes between them. Each step does one thing. Some steps are plain functions. Some steps are agents. But the flow itself never improvises.
Think of it as the difference between an assembly line and a craftsman. The autonomous agent is a craftsman you hand a pile of parts and a goal, hoping they assemble it correctly each time. The flow is an assembly line: each station has one job, the conveyor belt enforces the order, and you put intelligence only at the stations that genuinely need it.
For the expense agent, the flow was:
- Parse the report (code: extract fields from the submission)
- Check against policy (agent: this needs judgement about ambiguous line items)
- Apply the limit rule (code: a number comparison, no model needed)
- Pick the approver (code: a lookup table keyed on department and amount)
- Draft the notification (agent: this benefits from natural language)
- Send (code: an API call)
Two of the six steps actually needed a model. The other four were deterministic logic that a language model had been doing badly and expensively. Once we moved them into code, the only places left for the system to "decide" were the two places where deciding was the point.
The dividing line is reasoning density
The useful question is not "should this be an agent or not." It is "which parts of this require reasoning, and which parts only look like they do."
A step belongs in code when there is exactly one correct next action given the inputs. Routing by department, comparing a number to a threshold, formatting an output, calling an API in a fixed order. These have deterministic answers. A model can produce them, but it can also fail to, and you gain nothing from the variance.
A step belongs in an agent when the input is open-ended and genuinely requires judgement. Interpreting a vague policy clause against a messy real-world expense, summarizing a document, deciding which of several plausible tools fits an unstructured request. Here the variance is the value: you are paying for reasoning you could not write down as rules.
When you separate a real workflow this way, most "agent" projects turn out to be roughly 80% flow and 20% agent. The teams that struggle in production are usually the ones that pushed the whole thing into the 20% bucket and asked a model to handle the deterministic 80% out of convenience.
Why autonomous loops fail on fixed processes
A fully autonomous agent decides its own next step at every iteration. That flexibility is exactly what you want when the path is genuinely unknown, like research or debugging or exploration. It is exactly what you do not want when the path is known.
On a fixed process, autonomy buys you three failure modes for free:
- Step skipping. Nothing forces the agent to run the policy check before the limit rule. Most runs it does. Some runs it does not, because the order lives in a prompt, not in control flow.
- Drift under length. After a few tool calls the immediate observation dominates the agent's attention and it loses the thread of the overall task. This is the same loop death that makes ReAct stall on multi-step work.
- Non-determinism you cannot test. The same input produces different traces, so you cannot write a regression test that means anything. "Sometimes works" is the signature of a process that should have been a flow.
A flow removes all three by construction. The order is code. The steps cannot be skipped. The same input takes the same path, so it is testable.
The cost difference is not small
The expense client was making five to eight model calls per report under the autonomous design, because the agent kept reasoning between every tool call. The flow made two, one for the policy check and one for the notification draft. Everything else was code.
That is not a tuning win. It is a structural one. When you stop asking a model to make decisions that have deterministic answers, you stop paying for those decisions, and you stop paying for the retries when they come out wrong. For a process that runs thousands of times a day, the difference between two calls and six is the difference between a viable feature and a line item someone eventually questions.
Flows are operable, autonomous loops are not
The quiet benefit shows up the first time something breaks in production.
With the autonomous agent, a failed report gave the team a transcript: a wall of thoughts and tool calls they had to read like tea leaves to guess what went wrong. With the flow, a failure maps to a step. The notification went to the wrong approver, so the bug is in step 4, the approver lookup, and step 4 is twelve lines of code with a unit test. You fix it in an hour instead of a day, and you can be confident the fix holds because the path is deterministic.
This is the difference between a system you can operate and one you can only pray over. Most agent projects that stall before launch stall here, on the realization that nobody can confidently debug the thing. Flows give you the logging, the explicit branches, and the per-step failure attribution that production operations actually require. It is the same reason we tell teams to build observability before they launch, not after.
When you genuinely want autonomy
None of this is an argument against agents. It is an argument against using an agent to do a flow's job.
Reach for a fully autonomous loop when the path is genuinely unknown at design time: open-ended research, incident investigation, a support task where each user message can change the goal, anything where you cannot write down the steps in advance because the steps depend on what the agent finds. There the flexibility is the whole point, and forcing a rigid flow would break it. We covered the flip side of this in knowing when not to build an agent at all.
The mistake is treating autonomy as the default. It should be the exception you reach for when the structure of the work is genuinely undecidable in advance, not the wrapper you put around work whose structure has been sitting in a wiki for years.
The decision in one pass
When you are about to build an agent, sketch the process as steps first, before writing a prompt:
- Can you write the steps and their order down? If yes, that order belongs in code. Build a flow.
- For each step, is there one correct next action? If yes, it is a code step. If no, it is an agent step.
- Does the whole task have an unknown, input-dependent structure? Only then does a fully autonomous loop earn its place.
- Will you need to debug this in production? You will. Flows make that possible; autonomous loops make it luck.
Most teams discover that the thing they were about to build as "an agent" is actually a six-step flow with two agent-shaped holes in it. Building it that way is cheaper, more reliable, and operable from day one.
If your agent fails in ways you cannot reproduce
If your team has an agent that "sometimes works" on a process whose steps never actually change, the fix is usually structural, not another round of prompt engineering.
Sapota runs a one-week agent architecture audit that maps your current design, separates the deterministic flow from the genuine reasoning steps, and ships the rebuild as a working integration. We have done this for approval pipelines, document processing, support routing, and reporting workflows. The shape of the answer is similar each time; the specific steps depend on your domain.
Reach out via the AI engineering page with a description of what your agent is supposed to do and where it gets unpredictable. The diagnosis is usually clear within 30 minutes.
