Agent Washing: How to Tell a Real AI Agent From an Automation With a New Sticker

Sometime this year, every product you already owned became an agent. The email sequencer is an agent now. The form-filler is an agent. The ticket router that keyword-matches into three queues is, its pricing page insists, agentic. The architecture did not change. The sticker did, and the invoice followed it.

This matters for a colder reason than annoyance: the word decides what you pay, what failure looks like, and how much oversight you owe the thing. When the label lies, you either overpay for a macro or under-supervise something genuinely autonomous. Both are expensive, in opposite directions.

What makes something an actual agent

Strip the marketing and the test is short. A script replays steps that were fixed before the work arrived. An agent pursues a goal: it plans an approach, chooses which tools to use, reads the result of each action, and adapts, including knowing when to stop and hand the case to a person. The difference is not intelligence in the abstract. It is who decides the path: the author at design time, or the system at run time.

Both shapes are legitimate engineering. We have written about when a copilot beats an agent and when one agent beats several, and nothing in either post requires the fancier architecture to win. The problem is purely the mislabel, because the two shapes carry different price tags and different risks, and the sticker is how vendors move a product from the cheap column to the expensive one without touching the code.

Why the label changes what you owe it

A workflow’s failure is boring: an input arrives that the author never imagined, and the line breaks, loudly, in the same place every time. You test it once and it stays tested. An agent’s failure is creative: it can take a path nobody predicted, which is exactly why it needs evals that score its judgment, guardrails on what it can touch, and a probation period like any new hire. Oversight is a real, recurring cost, and it only buys you something when there is judgment to oversee.

That gives agent washing two victims. The buyer who pays agent prices for an if-then script overpays and then wastes review effort supervising a thing that cannot surprise them. And the buyer who assumes “agent” is just branding puts a genuinely autonomous system into production with workflow-grade oversight, which is how a surprise ends up in front of a customer. Try telling the two apart yourself:

The fork a buyer is actually standing at

Behind the sticker, one of three things

Strip the word agent off the pitch. What did the vendor actually build, and what should you pay and supervise it like?

A scripted workflow

Fixed steps, fixed trigger. Cheap, testable, predictable. Often the right buy, at workflow prices.

A copilot

Drafts and suggests inside your tools; a person decides. Honest middle ground, priced and supervised as such.

A goal-driven agent

Plans, picks tools, adapts, escalates. Powerful, and it earns evals, guardrails, and a probation period.

The five questions that cut through the sticker

You do not need to read the vendor’s code. Five questions on a call expose the architecture, because only one of the three shapes above can answer all five well.

1. Show us two run logs of the same task with different obstacles. Identical traces mean a script. Different tool calls, different order, an escalation in one of them: that is run-time judgment.
2. What happens on an input your demo never covered? A workflow vendor will talk about adding rules. An agent vendor should talk about confidence, escalation, and what the system refuses to do alone.
3. What tools can it invoke, and who bounded that list? A real agent has an explicit, auditable tool list with permissions. No list, or “it can do anything your API can,” is a red flag in either architecture.
4. What happens when one of its tools fails mid-task? Retry, route around, or escalate is an agent answer. “The run errors and you re-trigger it” is a workflow answer, priced accordingly.
5. Where is the human gate, and can it be moved? Whatever the architecture, the consequential actions need a person at the moments that matter. A vendor who cannot show you the gate is selling trust they have not built.

The test is never the demo. It is who decides the path: the author at design time, or the system at run time.

The twist: sometimes the macro is exactly what you should buy

Here is what the washing hides in both directions: for a stable, high-volume, well-understood process, the deterministic workflow is frequently the better purchase. It runs for a fraction of an agent’s token bill, it never has a creative day, and its failures page someone immediately. Some work should not even be automated at all, as we argued in what you should refuse to automate. The dishonesty is not in shipping a script. It is in charging agent prices for one, and in the quieter damage that follows: buyers burned by a washed “agent” conclude agents do not work, and walk past the real ones.

What to do Monday

Pull up the pitch deck of the most agentic thing you are currently evaluating and run question one: two run logs, same task, different obstacles. It takes the vendor ten minutes if the answer is good and ten days if it is not, and either result tells you what you are actually buying. Then price it, and supervise it, as what it is, not as what the sticker says.

---

Evaluating something that calls itself an agent? Book a free consult and we will run the five questions against the pitch with you, and map what the workflow actually needs: a script, a copilot, or the real thing.