The thesis in one line: almost everything sold today as an "AI agent" is a workflow —a fixed sequence of steps, written by a human ahead of time— wearing a fancier name. Agent washing is exactly that: relabeling the same old automation to sell it as if it thinks. And the question that separates one from the other isn’t how many steps it has or how many models run under the hood. It’s one question: does it decide, or does it execute?
What a real AI agent actually is (and what agent washing is)
Agent washing is the same trick as greenwashing, applied to software: you stick the trendy word on top of something that hasn’t changed underneath, and you charge the trend premium. First it was "AI-powered". Then it was "machine learning". Now it’s "agent". The product underneath —a form that fires off a flow, three chained API calls, an if-else with an LLM in the middle to draft the final text— is the same one from two years ago. The only thing that went up is the price and the word in the headline.
A workflow, however well built, executes fixed steps: if A happens, do B; if not, do C. The human who designed it already decided, at the whiteboard, every possible branch. Whatever AI sits inside, if any, is limited to drafting an email or pulling a field out of a PDF —tasks it does well, but that isn’t deciding—. A real agent does something different: it faces a situation nobody fully anticipated, picks which tool to use to handle it, and that choice was never written into any flowchart beforehand. That ability to decide on the fly, with incomplete information, is the only thing that separates "agent" from "workflow with an AI step".
Why they hide it from you in the demo
A agent-washing vendor’s demo is built, almost always without conscious bad faith, to never show you the weird case. It shows you the happy path: the customer types exactly what was expected, the data arrives clean, the API of the day responds on the first try. On that path, a well-built workflow behaves exactly like a real agent —fast, safe, flawless—. The difference only shows up when something goes off-script: the customer asks something nobody planned for, two conditions fire at once and nobody anticipated which one wins, the API returns a half-broken error. That’s where the workflow stalls or improvises badly, because it has no room to decide beyond what someone wrote. And that moment, by definition, never makes it into the demo, because whoever runs the demo picks which case to show.
It isn’t necessarily deliberate deception. Often the vendor themselves confuses "uses an LLM somewhere" with "is an agent", because the industry’s marketing has spent two years pushing that confusion and it’s convenient for everyone: it sounds better in the proposal, it justifies a higher price, and a customer who’s never built one has no easy way to check before signing. The outcome is the same either way: you pay agent price for a workflow, and you find out the day the weird case shows up —usually in production, with a real customer watching.
The acid test: three questions a disguised workflow can’t survive
You don’t need to be an engineer to ask these. You need to ask them before signing, not after:
- "What does it do when the input doesn’t match any of the planned cases?" A workflow has a default branch —usually "escalate to a human" or "return a generic error"—. An agent evaluates the situation with the tools it has and decides on a reasonable course of action, even if imperfect.
- "Can it choose NOT to use a tool you gave it, if it decides it doesn’t apply?" If the answer is "no, it always follows the programmed sequence", that’s a workflow with conditional steps, however sophisticated it looks. An agent discards tools when context tells it they don’t apply.
- "What happens if I reorder the request, or give it two contradictory requests at once?" The workflow breaks or grabs the first matching rule. The agent reasons about the contradiction and, at minimum, flags it instead of blindly executing the first match.
If the vendor answers with confidence and concrete examples, not "that doesn’t usually happen", you probably have something real in front of you. If they dodge the question or answer with an adoption metric instead of a case, that’s your answer.
| Workflow with a name tag | Real agent |
|---|---|
| Every branch was decided at design time | Decides on the fly when something wasn’t planned |
| AI drafts or extracts text at one step | AI chooses which tool to use and when |
| The weird case breaks the flow or stalls it | The weird case gets reasoned through with what’s available |
| The demo always shows the happy path | It survives questions about the path that isn’t |
None of this means the workflow is bad. A well-built workflow —cheap, predictable, easy to audit— is the right tool for 80% of a company’s processes: the ones that genuinely have fixed steps and don’t need anyone to decide anything. The problem isn’t having a workflow. The problem is paying for it as if it were an agent, and finding out the difference the day it needs to decide and can’t. Anyone who wants to understand what it actually takes to build something that does decide —memory across interactions, tool choice, measuring its own work, not just an LLM bolted onto the end of a chain— has the full map in how to build an AI agent that isn’t a chatbot in a costume; this piece stops at how to spot the difference before you buy.
When the workflow is exactly what you need (and buying an agent would be throwing money away)
Here’s the part almost nobody on the sales side will tell you: if your process is repeatable, with steps that don’t change and exceptions rare enough to count on one hand, an agent is expensive over-engineering. You’re overpaying a system to "decide" something that always gets decided the same way anyway. That’s exactly the territory where automating a process with AI agents without it breaking on the first try means building the right workflow, done well, instead of dressing it up as something else to charge more. A real agent earns its price when the process has genuine variability: when every case arrives differently, when exceptions are the majority and not the minority, when you need someone —human or agent— to exercise judgment instead of following a script.
That’s the same logic behind building a team of AI employees instead of a pile of disconnected automations: it makes no sense to call a script that always does the same thing an "employee", same as it makes no sense to call a workflow an "agent". An employee —human or digital— earns their keep through judgment, not by repeating the same step. If what you need is the same step repeated a thousand times without deviation, that’s not an employee or an agent: it’s a workflow, and that’s fine. Pay for it as what it is.