Most Things Called "AI Agents" Are Workflows With Better Marketing

The distinction nobody selling you an agent will draw for you

Every vendor pitch this year uses the word "agent." Half of what gets called an agent is a chatbot with a nicer UI. A quarter is a scripted automation with an LLM bolted on for the parts that need language understanding. The rest is somewhere in between, and almost none of the pitches tell you which bucket their product is actually in — because the word "agent" sells better than "workflow," regardless of which one you're buying.

This isn't just marketing cynicism. Anthropic's own engineering writeup on the topic draws a specific line: a workflow is a system where an LLM and some tools are orchestrated through predefined code paths — the control flow is fixed, the LLM fills in the reasoning or language at defined steps. An agent is a system where the LLM dynamically directs its own process and tool use, deciding what to do next based on what just happened, with a human mostly stepping back in only to give the initial instruction or review the outcome. Both get grouped under "agentic systems." Only one of them actually behaves the way "agent" implies.

The distinction isn't academic. It determines what the system can do, what it costs, how it fails, and whether you can predict its behavior — which is exactly what you need to know before you sign a contract for one.

What an agent does that a workflow doesn't

A workflow looks like: retrieve a document, extract fields with an LLM call, validate against rules, write to a database, send a notification. Every step is wired by a developer in advance. The LLM is doing one well-scoped job inside a path that doesn't change no matter what the LLM returns, short of basic branching. This is most of what gets sold as "AI-powered automation," and it's often the right tool — it's predictable, it's debuggable, and you can put a cost ceiling on it because the number of LLM calls per run is fixed.

An agent looks different: given a goal, it decides which tool to call, evaluates the result, decides whether that was enough or whether it needs another tool call, and keeps looping until it judges the goal met or it hits a stopping condition you set. Nobody wrote the sequence of steps in advance because the sequence depends on what the model finds along the way — a customer support agent that has to look up an order, notice the order doesn't exist, search for a likely typo in the order number, and adjust — a chain of decisions no one could fully script ahead of time.

That open-endedness is the entire value proposition of an agent over a workflow: it can handle cases nobody enumerated. It's also the entire cost: more model calls per task, less predictable spend, and failure modes that compound instead of stopping cleanly. An agent that misreads a tool result on step 2 doesn't just get step 2 wrong — it carries that wrong belief into steps 3 through 10, and the final output can look perfectly confident while being built on a false premise several steps back.

Why the distinction matters more than the word does

Analysts have started calling the mislabeling problem "agent-washing" — vendors relabeling chatbots, RPA scripts, or scheduled report generators as "AI agents" because the term commands a premium. You don't need to take a side on how widespread that is to act on the underlying point: the label on a product tells you nothing about which architecture you're buying, and the two architectures have genuinely different risk profiles.

If a vendor's "agent" is actually a workflow, that's not automatically bad — it might be exactly what you need, and it should cost and behave like a workflow: fixed steps, predictable latency, a bounded number of LLM calls, deterministic enough that you can write a test suite against expected outputs. If it's actually an agent, you should expect variable runtime, variable cost per task, and you need to ask different questions: what happens when it's wrong, how many retries before it gives up, what's the maximum number of tool calls before someone has to intervene, and what does the audit trail of its decisions look like when you need to find out why it did something.

The failure mode for buyers is paying agent prices for workflow behavior, or worse, deploying workflow-level trust in something that's actually making autonomous multi-step decisions with no one checking the intermediate steps.

How to tell which one you're being sold

Ask the vendor three concrete questions, not "is it an agent":

• Does the sequence of actions change based on what happens mid-task, or is it the same sequence every time with different data filled in? Same sequence every time is a workflow, whatever it's called.
• If step 3 of 7 gives an unexpected result, what does the system do? A workflow either breaks or follows a pre-written fallback branch. An agent re-plans — it has to be able to decide a new course of action, which means someone has to have built in a way to bound how far that re-planning can go.
• Show me a run where it did something you didn't expect, and tell me why it did that. If the answer is "it can't do anything we didn't expect," that's a workflow and that's fine — but it's not what "agent" implies. If they can't produce a real example at all, be skeptical of how much testing has actually happened.

When you actually need the real thing

Most SMB use cases that get pitched as agents don't need the open-ended version. Processing invoices, routing support tickets by category, generating a weekly report, answering FAQs from a knowledge base — these have a known, finite set of steps. A workflow handles them more cheaply and more predictably than a true agent, and you should push back if a vendor is charging agent rates for workflow scope.

The real thing earns its cost when the task genuinely can't be fully specified in advance — when the number of possible paths through the problem is too large to enumerate, and the cost of a human doing it by hand is high enough to justify the agent's variable overhead and occasional wrong turn. Triaging an open-ended customer inquiry across multiple systems, debugging a failure by exploring logs and code, researching a question that requires several dependent searches — these are shaped like agent problems because no one can write the fixed script for them ahead of time.

The takeaway

Before you evaluate an "AI agent" pitch on price or features, evaluate it on architecture: ask whether the sequence of steps is fixed or decided at runtime, and size your expectations — and your contract's testing and audit requirements — to whichever one you're actually buying. The word on the slide deck isn't a spec.