Most of the "agent" systems presented at conferences this year are not agents. They are deterministic workflows with one conditional branch and a large language model call in the middle. The demo looks autonomous because the presenter chose the input. Change the input, and the seams show.
That matters, because you are probably being asked to "use agents" for a problem that does not need one. And an AI agent is the most expensive architecture you can choose to solve a problem you could have enumerated.
Here is the claim, up front: an AI agent is the right tool when the task has genuine state-dependent branching that cannot be enumerated in advance. For everything else, a deterministic workflow is cheaper to run, easier to test, simpler to audit, and far less painful to maintain. The rest of this article is about earning that claim — and about the operating conditions where it flips.
The distinction that actually matters
The word "agent" has been stretched until it means almost nothing. So let me be precise about the two architectures I am comparing, because the difference is operational, not philosophical.
A deterministic workflow is a graph you draw in advance. You know the nodes. You know the edges. You know the conditions under which control moves from one node to the next. A LangGraph-style stateful graph is the clearest modern example: it holds state, it can loop, it can branch, it can call an LLM at any node — and yet the topology of the graph is fixed by you, the engineer, before the first request arrives. The LLM decides content. It does not decide the shape of the execution. If a step can retry, you wrote the retry edge. If it escalates to a human, you placed that gate.
An autonomous agent is different in one specific way: it selects its own path at runtime. It decides which tool to call next based on what it just observed. It can enter a self-correction loop, re-plan after a failure, and choose a sequence of actions that you never explicitly drew. The control flow is a product of the model's reasoning over the current state, not a graph you can print and hand to an auditor.
That single difference — who chooses the next step, the engineer or the model — is the whole decision. Everything downstream (testing, observability, rollback, cost) follows from it.
A LangGraph graph with conditional edges is still deterministic in the sense that matters here: you can enumerate every path. An agent that dynamically composes tool calls cannot be enumerated, by design. That is its value, and its liability.
Why the deterministic default is the correct default
Start from the workflow and justify moving away from it. Not the other way around.
When you can enumerate the branches, you get properties that enterprise systems are built on:
- Testing is tractable. A fixed graph has a finite set of paths. You can write a test per path, cover the conditional logic, and know your coverage number means something. You cannot write a meaningful coverage number for a system that invents its own paths.
- Observability is cheap. In a deterministic workflow, a trace is a list of nodes visited. It reads like a stack trace. In an autonomous agent, a trace is a transcript of reasoning steps and tool calls that differs on every run, and you need to store, index, and interpret all of it to debug a single incident.
- Rollback is a code change. When a deterministic workflow behaves wrongly, you find the node, you fix the logic, you redeploy, and the fix is permanent. When an agent behaves wrongly, you are tuning a prompt or a policy and hoping the distribution of behaviors shifts in the direction you want.
- Cost is bounded. A workflow calls the LLM a known number of times. An agent calls it until it decides it is done, which on a bad day means a self-correction loop that burns tokens re-reading its own confusion.
None of this makes the agent bad. It makes the agent expensive — in engineering effort, in operational surface area, in the difficulty of proving to a compliance team that the system does what you say it does. You pay that price willingly only when the problem genuinely requires it.
When the workflow actually breaks down
The design breaks down when you cannot enumerate the branches ahead of time — not because you were lazy, but because the branching is a function of state you only discover at runtime.
Concrete signals that you have crossed into agent territory:
- The number of valid next actions depends on data you will not see until the task is running, and the combinations are effectively unbounded.
- The task requires investigation: reading a result, forming a hypothesis, choosing the next probe based on what came back — a loop whose length you cannot predict.
- Tool selection is itself the hard part. If choosing which of forty tools to call, in which order, is the intellectual work, a fixed graph becomes a combinatorial mess that is harder to maintain than an agent.
- The task is open-ended enough that "success" is not a fixed output shape but a judgment the system has to make about whether it is finished.
A support-triage flow that routes tickets by category is not this. A system that debugs a failing deployment by reading logs, forming a theory, running a diagnostic, and revising the theory — that is. The first is a switch statement wearing a trench coat. The second has irreducible state-dependent branching.
The pattern that settled this debate was a hybrid. Most of the work stayed a deterministic graph — fixed steps, enumerable branches, the kind of sequence you can draw on a whiteboard. Exactly one sub-problem was genuinely open-ended: it required reading an unfamiliar failure, forming a hypothesis, and deciding whether the fix had actually worked. That sub-problem went to a supervised agent, with an approval gate on every state-changing tool call, while everything before and after it remained a graph.
The lesson is not that agents are cheaper. It is that the boundary is worth drawing on purpose. The rule we converged on: if you can name the exit condition in advance, it belongs in the graph. If the agent has to decide whether it is finished, that is the part that genuinely needs a model — and a human on every consequential action.
The decision matrix
Rate a task against six characteristics. The columns are four architectures on a spectrum of autonomy: a fixed workflow (hardcoded steps), a parameterised workflow (same graph, config-driven branches — a LangGraph-style stateful graph lives here), a supervised agent (dynamic tool selection, but a human approves consequential actions), and an autonomous agent (self-directed, self-correcting, acts without per-step approval).
| Task characteristic | Fixed workflow | Parameterised workflow | Supervised agent | Autonomous agent |
|---|---|---|---|---|
| Branching predictability — can you enumerate the paths? | Good fit — fully enumerable, one topology | Good fit — branches known, chosen by config/state | Conditional — use only if paths are genuinely unbounded | Poor fit unless truly non-enumerable — otherwise wasted cost |
| Tool count needed | Good fit — few, fixed tools | Good fit — moderate, all wired in advance | Conditional — many tools where selection is the hard part | Good fit — large/dynamic toolset where order emerges at runtime |
| Approval requirements | Good fit — gates hardcoded at fixed points | Good fit — gates placed on known branches | Good fit — human is the approval gate by design | Poor fit — no natural, reliable place for per-action human sign-off |
| Audit obligations | Good fit — trace is a fixed path, trivially reviewable | Good fit — every path enumerable and loggable | Conditional — auditable only with heavy per-run trace capture | Poor fit — non-reproducible paths make audit expensive and contestable |
| Latency tolerance | Good fit — minimal overhead, one pass | Good fit — predictable, bounded step count | Conditional — adds human wait time at approval points | Poor fit for tight SLAs — loop length and token cost are variable |
| Cost of failure | Good fit — deterministic, blast radius is known | Good fit — failures map to a specific branch | Good fit — supervision contains high-stakes actions | Poor fit for high-stakes, reversible-only-with-effort actions |
Read the matrix as a bias, not a verdict. The pattern is deliberate: fit degrades as you move right unless a specific characteristic — unbounded branching, dynamic tool selection — forces you rightward. The autonomous column earns its "Good fit" only on the two rows that describe genuine, irreducible dynamism. On governance rows (approval, audit, cost of failure) autonomy is a liability you must buy down.
The supervised agent is the underused middle. It gives you dynamic tool selection where you need it, while keeping a human on the consequential actions. For many enterprise tasks that feel "too complex for a workflow," a supervised agent is the honest answer — not full autonomy.
Trade-offs you are actually choosing between
The matrix compresses four trade-offs worth spelling out, because they are where projects quietly fail.
Observability cost
A deterministic workflow gives you observability almost for free: the path is the log. With an autonomous agent, observability is a system you have to build and pay for. You need to capture every reasoning step, every tool call and its arguments, every intermediate result — on every run, because the run you did not trace is the one that failed. Budget for the storage, the indexing, and the human time to read transcripts. If you are not willing to fund that, you are not ready to run an agent in production.
Approval gate placement
In a fixed graph you place approval gates at known junctions and they cannot be skipped — the edge simply does not exist without the gate. In an autonomous agent, there is no fixed junction to attach the gate to, because the agent can reach a consequential action by a path you did not anticipate. This is exactly why the supervised-agent pattern exists: you constrain the agent so that any state-changing tool call routes through a human, regardless of how the agent got there. Get this wrong and the agent self-heals its way around your one mandatory approval.
Testing strategy
You test a workflow by enumerating paths and asserting outcomes. You cannot test an agent that way, because it does not have a fixed set of paths. Agent testing is evaluation, not assertion: you build a dataset of scenarios, you score behavior against rubrics, you track regressions statistically, and you accept that "passing" is a distribution, not a green checkmark. This is a different discipline with different tools, and teams that assume unit tests will cover an agent are unpleasantly surprised.
Failure recovery
A deterministic workflow recovers deterministically: you wrote the retry, the compensation, the fallback edge. An autonomous agent recovers by deciding to recover, which is powerful when the failure is novel and dangerous when the recovery loop itself misbehaves. Self-correction is the agent's headline feature and its most common failure mode — the loop that keeps "fixing" a problem it does not understand, spending tokens and, worse, taking actions. If you cannot bound the loop and cannot roll back its actions cleanly, do not give it autonomy over anything that writes.
A note on "agentic" as a spectrum
The four columns are not four species. They are points on one axis: how much of the control flow you cede to the model. The mistake is treating the choice as binary — "workflow or agent." Most robust enterprise systems are mostly deterministic with small, well-bounded agentic pockets: a stateful graph that, at exactly one node, hands a genuinely open-ended sub-problem to a supervised agent, collects the result, and returns to deterministic ground. You get the dynamism where it pays and keep the auditability everywhere else.
This is also where a coordination layer earns its place. When you do run multiple agents or mix agentic and deterministic steps, something has to own state, scope tools per task, and enforce the approval gates. Agent Shaker, our open-source platform for coordinating agents, tasks, and teams, exists for exactly that seam — but the architectural point stands with or without a specific tool: keep the agentic surface small and governed, and make the deterministic scaffolding do the heavy lifting.
Conclusion — how to decide, in practice
Run the task through three questions before you write any code.
- Can I draw the graph? If you can enumerate the paths on a whiteboard, build the workflow. A LangGraph-style stateful graph handles far more "complex" branching than people assume, and it stays auditable.
- Is tool selection the hard part, or tool execution? If the sequence of tools is known and only the data varies, that is a parameterised workflow. If choosing the next tool from a large set, based on runtime state, is the actual problem, you are looking at an agent.
- What happens on a bad day? If a wrong action is expensive or hard to reverse, keep a human in the loop — a supervised agent, not an autonomous one. Autonomy over irreversible, high-stakes actions is a bet you will eventually lose.
The default is the deterministic workflow, and you should feel the burden of proof when moving away from it. Reach for an agent when the branching is genuinely unbounded and tool selection is the intellectual core of the task. Reach for a supervised agent, not a fully autonomous one, whenever the cost of failure is real. And keep the agentic surface as small as the problem allows — because every step you cede to the model is a step you can no longer enumerate, test cheaply, or hand to an auditor without a story.
I would not choose an autonomous agent for anything that writes to a system of record without a human gate. That is not caution for its own sake. It is that the properties you give up — enumerable paths, cheap traces, deterministic rollback — are exactly the properties an enterprise needs when something goes wrong. And on a long enough timeline, something goes wrong.
Related: Governed Agentic Workflows: Architecture for Enterprise AI | Three Failure Modes of Multi-Agent Systems
Sources
- LangGraph — GitHub — a low-level orchestration framework for building stateful agents: a graph with state, cycles, and human-in-the-loop
- LangGraph overview — Docs by LangChain — how the graph is put together: nodes, edges, state, and control flow
- OpenAI Agents SDK — agent orchestration, handoffs, guardrails as approval gates, and run tracing
- Agent Shaker — GitHub — an open-source platform for coordinating agents, tasks, and teams
Discuss an enterprise AI architecture or delivery challenge → techbuzzz.ru
