A team builds something that calls a language model, lets it pick a tool, and routes the answer somewhere useful. In the standup, in the deck, in the job posting, they call it an agent. It usually is not one. The gap between what they built and what they named it is not pedantry. It is the reason the thing is slower than it should be, costs more than anyone forecast, and fails in ways nobody can reproduce.
One distinction in applied AI pays for itself the moment you understand it. It separates two kinds of systems that look almost identical on a whiteboard and behave nothing alike in production. One is a workflow. The other is an agent. Most teams should be building the first and think they are building the second, and that single confusion drives a large share of wasted spend and broken reliability in the field right now. Get the distinction right and most architecture decisions get easier. Get it wrong and you pay agent prices for workflow problems.
Origin: where the line was drawn
The cleanest definition comes from Anthropic, whose engineering team published Building Effective Agents in late 2024 after working with dozens of teams shipping these systems. They split the world in two. A workflow is a system where language models and tools are orchestrated through predefined code paths. An agent is a system where the model dynamically directs its own process and tool use, keeping control over how it accomplishes the task.
The difference is who owns the control flow. In a workflow, you do. You write the steps. The model fills in the hard parts inside those steps, but the sequence is yours, fixed in code before the request ever arrives. In an agent, the model does. You hand it a goal and a set of tools, and it decides what to do first, what to do next, and when it is finished. You own the plumbing in a workflow. The model owns the plumbing in an agent.
That second mode needed an idea to make it work, and the idea predates the word agent becoming a marketing term. In October 2022, weeks before ChatGPT shipped, researchers at Princeton and Google published ReAct, short for reasoning and acting. The insight was to interleave the two: let a model produce a reasoning trace, take an action, observe the result, and reason again with that result in hand. Google's writeup showed it beat reasoning-only and acting-only approaches on interactive tasks, because the model could correct its plan against what the environment actually returned instead of hallucinating forward. ReAct laid the groundwork for the autonomous systems that followed.
That loop is the agent. Strip away the framework branding and an agent is a model running a cycle: plan a step, act by calling a tool, observe what comes back, repeat until the goal is met or a limit is hit. Oracle's description of the agent loop calls it the execution primitive behind every agentic system, and primitive is the right word. It is a new unit of computation, the way a function call or a database transaction is a unit. The reason an agent can debug code across several files or research a question through a dozen sources is that it does not try to solve the whole thing at once. It takes one small action, sees what happened, and adjusts.
Present: why a workflow is usually the right answer
Here is the part most teams skip. The agent loop is the more impressive primitive, so it gets reached for by default. It is the wrong default. For the large majority of real tasks, a workflow is the better system, and Anthropic says so plainly in the same guide: find the simplest solution possible, and add complexity only when it demonstrably improves the outcome. They go further. For many applications, a single well-built model call with retrieval and good examples is enough. No loop at all.
A workflow wins on three properties that matter more in production than raw flexibility.
It is predictable. The path is fixed, so the same input moves through the same steps every time. You can reason about what it will do before it does it.
It is cheap. A deterministic orchestration costs close to nothing per run beyond the model calls you explicitly placed in it. Compare that to an agent. Gartner's March 2026 analysis found agentic systems consume 5 to 30 times more tokens per task than a standard chatbot interaction, because an agent reasoning through a task, calling tools, checking its own work, and self-correcting can trigger 10 to 20 model calls to finish one user request. A workflow with three planned steps makes three calls.
It is debuggable. When a workflow fails, the failure has an address. Step four broke, with this input, producing this output. You open step four. When an agent fails, you are reconstructing a path the model chose at runtime, one that may never occur the same way twice. One field analysis of agents in production names the quiet killers: concurrency collisions when parallel tool calls conflict, silent cost creep with no visible error, and context drift where the agent's internal picture of the world stops matching the real system state. None of those announce themselves.
There is a structural point underneath all three. An agent's freedom is exactly what compounds error. The reliability math is unforgiving: chain five steps that each succeed 95 percent of the time and the whole chain succeeds about 77 percent of the time. Push to twenty steps and you are near 36 percent. The worst version of this failure is the invisible one: an agent makes a wrong turn at step two, produces output that looks plausible, and every later step builds confidently on the mistake. Nothing throws an error. The answer is just wrong. A workflow with fixed paths and validation between steps gives that error far fewer places to hide. This is a central reason agents that dazzle in a demo collapse in production, covered in full in why agents fail in production.
The cost gap is not theoretical. Researchers measuring agents on software engineering tasks have seen an unconstrained agent run 5 to 8 dollars per task. Latency follows the same shape: a single model call lands in under a second, a multi-agent orchestration with a reflection step runs 10 to 30 seconds. Across agents hitting similar accuracy, one 2026 benchmark roundup found cost varying up to 50 times depending on architecture. Choosing an agent where a workflow would do is not a small inefficiency. It is a different cost structure.
Present: when the task genuinely needs an agent
None of this means agents are a mistake. It means they are a specific tool for a specific shape of problem, and that shape has a precise definition. A task needs an agent when the steps cannot be known in advance.
That is the whole test. If you can write down the sequence before the request arrives, you have a workflow, even when individual steps call a model to do something hard. An LLM step inside a workflow is just a smarter function call. If you genuinely cannot write the sequence, because each step depends on what the previous step discovered, you are in agent territory.
The honest examples are open-ended by nature. Research, where the next source to consult depends on what the last source said. Debugging, where the next file to open depends on the last error. Triaging an unfamiliar customer issue, where the resolution path is unknown until you have pulled on a few threads. Anthropic's framing is that workflows suit well-defined tasks where predictability matters, and agents suit problems that need flexibility and model-driven decisions at scale.
There is a useful warning sign for spotting a real agent task early. If you are building a workflow and you keep adding branches, a new conditional for every edge case, and the branch count keeps growing without converging, the problem is telling you its paths are variable. That is the moment to consider an agent for that part of the system. Not before.
Even then, the field has settled on a middle path rather than a binary. The dominant production pattern in 2026 is a hybrid: a deterministic workflow as the outer shell, with a bounded agent handling the one genuinely open-ended subtask inside it. Practitioner guidance puts the rough split at deterministic workflows for around 80 percent of automation and agents for the 20 percent that involve real ambiguity. You contain the unpredictability instead of letting it run through the whole system. Anthropic's own multi-agent research system follows this logic: even their most autonomous design uses an orchestrator with isolated sub-agents, and they were candid that the system uses about 15 times the tokens of a plain chat, which only pays off when the task is valuable enough to justify it.
Future and impact: the decision rule, and where it is heading
Here is a decision rule you can apply this week.
Start with the simplest thing that could work. For most tasks that is one well-built model call, or a short workflow of model calls along a fixed path. Reach for an agent only when you can say, concretely, why the steps cannot be scripted in advance, and confine the agent to the smallest part of the system that truly needs it. Before you ship anything agentic, answer one question: what happens when a tool call fails halfway through a multi-step task? If you cannot answer it, you have built a demo, not a production system.
That rule matters because the pressure runs the other way. The word agent sells. It is in the funding pitch and the product page, and architecting toward the label is tempting. The cost of doing that is now measurable. Token prices have fallen sharply, yet some enterprises now report monthly inference bills in the tens of millions, because usage outran the price drop once agentic loops ran thousands of times a day. Pilot economics calculated on single calls bore no relationship to production economics. A product category now exists purely to contain the damage: Portal26's Agentic Token Control module, launched in April 2026, lets administrators set token budgets per agent and throttle or kill ones that blow past a cap. When tooling emerges to cap the cost of a primitive, the primitive is being overused.
Two shifts will sharpen this distinction rather than dissolve it. Models keep getting better at following instructions and at staying coherent across long, structured inputs, which means a careful workflow now does work that looked like it needed an agent two years ago. The floor is rising, and a rising floor favors the simpler system. At the same time, an emerging pattern flips the roles: an agent figures out the right sequence once, then emits a deterministic workflow that runs reliably and cheaply forever after. The agent becomes a design-time tool, the workflow the run-time system. That is the distinction maturing, not disappearing.
The reliability problem is the backdrop for all of it. MIT's NANDA study found that roughly 95 percent of generative AI pilots deliver no measurable P and L impact, and the failure is almost never the model. It is workflow integration and the absence of a defined outcome before the build starts. Teams that reach for an agent by reflex are buying a harder version of an already hard problem. Asking whether a workflow would do is one of the cheapest reliability gains available, and it costs nothing but the honesty to look at the real shape of the task. The same discipline runs through the agent design patterns that survive contact with production: each one earns its complexity or it does not ship.
This is the seam where an implementation partner like Perform Digital tends to earn its place. The hard part of an enterprise AI project is rarely picking the model. It is drawing this line correctly, system by system: scripting the paths that can be scripted, reserving the agent loop for the genuine unknowns, and building the evaluation that proves the choice was right. The teams that do this ship systems that are predictable, affordable, and debuggable. The teams that call everything an agent ship the 95 percent.
Council summary
This post argues that the workflow versus agent question is the architecture decision most teams get wrong, and that the test is simple: a workflow is any system whose steps you can write down before the request arrives, an agent is one whose steps the model must discover at runtime. It earns the claim with hard numbers, agentic systems burn 5 to 30 times the tokens of a chatbot, reliability compounds downward as steps multiply, and most teams reach for the loop when a fixed path would be cheaper, faster, and debuggable. The reader leaves with a decision rule they can apply this week: start with the simplest thing that works, demand a concrete reason before adding an agent, and confine any agent to the smallest open-ended subtask, ideally inside a deterministic shell. The honest core of the piece is that picking the agent label is a cost decision, not a status one, and the discipline to ask whether a workflow would do is one of the cheapest reliability gains on offer.
Comments