Agent washing: how to tell a real agent from an AI wrapper

Who this is for. Buyers evaluating agent products, and anyone trying to work out what they are actually being sold. It is a deliberately vendor-neutral test — the questions below are ones we would expect a buyer to put to us, and they should.

The term, and why it exists

It exists because “agent” became the word that sells, and words that sell attract products that do not deserve them. The result is a market where the label has decoupled from the capability, and a buyer cannot infer from “AI agent” on a landing page whether the thing loops, acts, or merely chats.

The stakes are practical, not semantic. If your task needs multi-step autonomy and you bought a wrapper, it fails at the task. If your task needs one reliable call and you bought an autonomous loop, you are paying for unpredictability you did not need. Getting the category right is the difference between a tool that fits and one that does not.

The wrapper-to-agent spectrum

The second rung is where most of the confusion lives, because a single tool call feels agentic — the thing “used a tool”. But one round of tool use followed by an answer is not a loop; the model did not observe a result and decide what to do next. Tool use is necessary for an agent and nowhere near sufficient, which is exactly the ambiguity agent washing exploits.

The five questions

Question three is the one that matters most for anything consequential, and it has two parts on purpose. “Can it act?” distinguishes an agent from a chatbot. “What stops a wrong action?” distinguishes a safe agent from a reckless one — and a vendor who can answer the first but not the second has built the dangerous half of an agent without the half that makes it deployable.

The tells in a live demo

The forced-failure probe is the most revealing and the hardest to prepare for, which is why it works. Ask the system to do something where one step will fail — a record that does not exist, a tool that returns an error — and watch. An agent notices, reasons about the failure, and tries something different or escalates. A wrapper either produces a confidently wrong answer as if the step had succeeded, or repeats the same failing action, because it has no loop in which to notice.

The give-aways in the language

Vendor language leaks the category. “Powered by advanced AI” with no description of a loop is a wrapper tell. “Trained on your data” describes retrieval or fine-tuning, not autonomy. “Understands context” is a chatbot claim. What you are listening for is the opposite: concrete talk of steps, tools, state, limits and escalation — the vocabulary of something that actually runs a loop and knows its own boundaries.

A wrapper is not an insult

This is worth being emphatic about, because the whole framing could read as “agents good, wrappers bad” and that is exactly wrong. A large fraction of useful AI products are and should be wrappers or workflows. An autonomous loop is a liability where the task does not need one — more cost, more latency, more ways to fail, and behaviour you cannot fully predict.

So the honest buyer’s question is not “is this a real agent?” as a test of worth. It is “is this the category my task needs, and is it being described honestly?” A wrapper sold as a wrapper for a wrapper-shaped task is a good purchase. An agent sold as an agent for an agent-shaped task is a good purchase. The failures are the mismatches, and agent washing manufactures mismatches.

The buyer’s battery

AGENT REALITY SCORECARD                          product: ____________

Q1  Multiple dependent steps, autonomously?      □ yes  □ one pass only
Q2  Holds state across the conversation?         □ yes  □ only resent context
Q3a Can it take a real action (not just answer)? □ yes  □ answers only
Q3b If yes — what stops a wrong action?          ____________________________
     (no answer here = the dangerous half only)
Q4  On a forced failure, does it adapt?          □ adapts  □ repeats/hallucinates
Q5  Can it show a trace of what it did?           □ yes  □ one req/response

DEMO PROBES (do these live, not from slides)
  • "Find X, then do Y based on X"      → loops?  ______
  • "Now act on what you just found"    → state?  ______
  • [task with a broken step]           → recovers? ______

VERDICT
  4–5 yes, trace shown ............... a real agent — evaluate on merit
  2–3 yes ............................ a workflow with agent marketing
  0–1 yes ............................ a wrapper — fine, if that is what you need
                                        and what you were told you were buying

The uncomfortable part

There would be something hollow about publishing a detector for agent washing while asking to be taken on trust. So: the questions above are the ones to put to us, and the answer to question 3b — what stops a wrong action — is the one we would want you to press hardest on, because it is the one that most cleanly separates a system built to be deployed from one built to demo. If the answer is a system prompt, that is a wrapper wearing an agent’s clothes, and you should say so.

The deeper reason the test holds is that the honest distinctions are structural, not rhetorical. Whether a system loops, holds state, acts within a boundary and leaves a trace are facts about the architecture that no amount of positioning changes — which is why a buyer armed with five questions is better protected than one armed with a category name. For what an agent that passes all five actually requires underneath, see the seven-layer stack, and for the specific question 3b answer done properly, authority as code.