Most things sold to you as AI agents
in 2026 are if-statements with a personality. That sounds harsh, but there is a one-question test that tells you which ones are real — and it is not the demo, the branding, or how clever the output looks. The AI agent vs workflow question comes down to a single line of control, and once you can see it, you can never unsee it.
By the end of this post, you’ll be able to look at any agent
— yours or a vendor’s — and say, with confidence, whether it is actually an agent or a workflow wearing the label.
- The one test: at runtime, does the model decide the next step, or did you hardcode it?
- Workflow = your code picks the path. Agent = the model picks the path. That’s the whole distinction.
- Neither is better. Workflows win on predictability and cost; agents win on flexibility. The skill is knowing which one the task needs.
Why Everyone’s Confused
The word agent
got blurry because marketing stretched it to cover anything with a language model inside. A chatbot with a system prompt, a one-shot summarizer, a fixed pipeline with an LLM in step three — all of them shipped as “agents” in 2026. No wonder developers are frustrated; the question that keeps coming up about any flashy demo is simply whether it’s a real agent, or just a persona and some skills.
The cleanest definition comes from Anthropic’s Building Effective Agents: workflows orchestrate models and tools “through predefined code paths,” while agents are systems where models dynamically direct their own processes and tool usage.
Read that twice. The difference isn’t intelligence or capability — it’s who holds the steering wheel at runtime. If you want the broader picture of what these systems are, the complete guide to AI agents sets the scene; here we draw the one line that matters.
Workflow vs Agent: The 5-Dimension Test
Run any system through these five dimensions and the label sorts itself out. The first row is the one that decides it; the rest follow from it.
| Dimension | Workflow | Agent |
|---|---|---|
| Who picks the next step | Your code | The model, at runtime |
| The path | Fixed, written in advance | Chosen on the fly |
| A new kind of input | Breaks, or needs new code | Adapts within its tools |
| Predictability | High — same path every time | Lower — varies by run |
| Cost & latency | Low and stable | Higher and variable |
Notice the trade running down the table. A workflow gives you control and predictability; an agent gives you flexibility and pays for it in cost, latency, and the occasional surprise. You are not choosing the “smarter” option — you are choosing where to spend your predictability budget. I keep this table in my head every time someone says “let’s make it an agent,” because half the time the honest answer is that a workflow would be cheaper, faster, and easier to trust.
The Same Task, Two Ways
Theory is slippery, so here is the difference in code. The task: answer what was our Q2 revenue?
First, as a workflow:
# Workflow: YOU decide the steps, in order, every time.data = search("Q2 revenue report")summary = summarize(data)print(summary)
That works — for exactly this question. Now the same task as an agent:
# Agent: the MODEL decides the next step, in a loop.while True:reply = model(messages, tools=[search, summarize])if not reply.tool_calls: # model has an answer -> stopprint(reply.content)breakfor call in reply.tool_calls: # run whatever the model chosemessages.append(run_tool(call))
Look at what changed. In the workflow, you wrote search then summarize — that order is your decision, baked in. In the agent, you never specified the order. The model might search once, search twice, skip summarizing, or ask a follow-up — it decides, then your loop runs whatever it picked. That loop is the actual mechanism of an agent; if you want to build it line by line, the agent loop from scratch walks through every part.
A real example makes the gap obvious. I once upgraded
a working report-summarizer into an agent because it sounded better in the standup. The workflow had answered one revenue question reliably for weeks. The agent answered the same question three different ways across three runs, cost four times as much, and once decided to search twice for no reason. It was more capable and worse for the job — the task never needed the model to choose anything. That mistake is the whole reason this distinction matters in practice, not just on a slide.
The Grey Zone: Agentic Workflows
Real systems aren’t always pure. The most common shape in production is the agentic workflow — a mostly fixed path with one or two points where the model genuinely decides. Think of a support pipeline that always classifies, always logs, but lets the model choose whether to escalate, refund, or ask a question.
Is that an agent? Partly. It’s more honest to call it an agentic workflow than to pretend it’s fully autonomous. I actually prefer this shape for most real products: you get predictability where you need it and model-driven flexibility only at the decision that benefits from it. The confusion isn’t that these exist — it’s that they get marketed as fully autonomous agents when they’re 90% rails.
When You Actually Want a Workflow
Here’s the part the hype skips: for most well-defined tasks, a workflow is the right answer, and reaching for an agent is over-engineering. Anthropic’s own guidance is to use the simplest thing that works and only add agency when the task demands it.
Choose a workflow when:
- The steps are known and stable — you can write them down, so write them down.
- Predictability matters — billing, compliance, anything audited, anything where “it varies by run” is unacceptable.
- Cost and latency are tight — a fixed path makes one or two model calls; an agent can make many.
Reach for an agent only when the task is genuinely open-ended — when you can’t enumerate the steps in advance because they depend on what the model finds along the way. Multi-system tasks that cross boundaries are a good signal; that’s also where protocols like MCP and A2A start to matter.
This is also the honest answer to a question that trips up beginners learning how to build AI agents: you start with the simplest workflow that solves the task, and you only graduate to an agent when a fixed path genuinely can’t cover the inputs you’ll see. Building an agent first, then discovering a three-line workflow would have done it, is one of the most common — and most expensive — early mistakes.
Quick Recap
The whole agent-vs-workflow question, distilled:
- Workflow: Your code decides the path. Predictable, cheap, easy to test.
- Agent: The model decides the path at runtime. Flexible, pricier, less predictable.
- Agentic workflow: Mostly fixed, with one or two model-decided branches, and very common.
- The test: Who picks the next step, your code or the model?
- Default to the simplest option That does the job; add agency only when the task is truly open-ended.
Conclusion
The AI agent vs workflow debate isn’t really a debate once you find the line: an agent is a system where the model decides its own next step, and a workflow is one where you decide it in advance. Everything else — the branding, the demo, the autonomous
label — is noise around that one fact. Knowing which one you’re building is what keeps you from paying agent prices for workflow problems, or trusting a fixed pipeline to handle something it was never built to.
Which “agents” in your own stack do you think would fail the test — the model decides, or you do? Tell me in the comments; I suspect a lot of us are running workflows we’ve been calling agents.
Read next: The AI Agent Loop in Python — build a real agent, the kind that passes the test, in about thirty lines of plain Python.



