Agent washing versus AI washing

AI washing is the broader practice of overstating whether a product uses artificial intelligence or what its AI can accomplish. Agent washing focuses on claims about goal-directed behavior, action-taking, autonomy, and the outcomes attributed to agents.

For example, calling a conventional search feature AI-powered could be AI washing. Calling a fixed sequence of searches and summaries an autonomous research agent could be agent washing if the description implies decisions and capabilities the system does not possess.

The term also applies when an actual agent is oversold. An agent that completes a narrow task under supervision should not be presented as independently running an entire department. Being technically agentic does not make every claim about it accurate.

A 2026 analysis highlights this broader problem: firms can exaggerate agent capabilities and impact or understate material deployment limitations. Buyers should therefore examine both what a system can do and the conditions under which it works.

Why agent washing happens

Demand encourages ambitious labels. 81% of leaders expected agents to be moderately or extensively integrated into their organisations’ AI strategy within 12 to 18 months. That finding reflects expectations at the time of the survey, not completed deployment.

The term agent also has flexible boundaries. Teams use it for systems ranging from conversational tools to software that selects actions across multiple applications. Without an agreed scope, the same label can describe very different products.

Meanwhile, deployment remains uneven, with 23% of respondents reporting scaling an agentic AI system somewhere in their organisation, while another 39% had begun experimenting. Scaling in at least one function is different from enterprise-wide deployment.

Together, these findings show strong interest and mixed maturity. They do not measure agent washing. They explain why buyers need to distinguish an announced ambition, a pilot, and a working production system before comparing offers.

What makes a system agentic

An AI agent is a system that uses AI to select steps or tools in pursuit of a goal, responds to the results of its actions, and operates within defined permissions and oversight. Its autonomy can be narrow and supervised.

A useful architectural distinction comes from Anthropic’s guidance on building effective agents: workflows follow predefined execution paths, while agents allow the model to direct how a task proceeds and which tools it uses. Terminology varies, so buyers should evaluate behavior rather than rely on a universal label.

Consider the difference between these common implementations:

• A chatbot answers questions from a knowledge base. Unless it can decide and execute further steps, an accurate answer does not establish that it can resolve the underlying business request.
• A scripted workflow reads a form, checks fixed conditions, and routes it to an approver. It may be dependable and valuable while offering very little discretion over the execution path.
• A tool-using assistant retrieves a customer record or drafts an update at the user’s request. A connected application proves access to a tool; it does not by itself prove sustained goal-directed execution.
• An agent pursuing a supplier-review goal can identify missing information, choose relevant searches, inspect results, and revise its next step. It can still require approval before contacting a supplier or changing a record.

Production systems often combine these patterns. Fixed rules can enforce approval limits while AI handles interpretation or selects the next permitted action. That combination can be entirely appropriate.

The important distinction is not whether rules exist. It is whether the description accurately explains where the model makes decisions, what actions are possible, and what people still need to do. Multiple agents do not automatically provide more autonomy or better results, either.

Need to establish what your workflow actually requires? Explore custom AI agent development with JADA.

Examples of agent washing in business

The following scenarios are illustrative to show how a modest capability can become misleading when the surrounding claim expands its scope.

Agent washing in procurement 

A product described as an autonomous supplier evaluation agent might simply summarise uploaded proposals. Summaries can help a buyer, but they do not establish that the system checks missing evidence, compares requirements, resolves inconsistencies, or follows up appropriately.

An agent designed for that workflow could examine the evaluation criteria, retrieve permitted supplier information, and identify gaps. It might draft clarification requests and ask the buyer to approve them. The buyer still owns the award decision. That approval boundary should be visible in the product description.

Agent washing in customer service 

An agent may be advertised as resolving complaints when it only suggests responses. Resolution requires more: understanding the issue, accessing relevant records, taking permitted corrective action, and confirming the result. A draft reply is an intermediate output, not evidence of completion.

Agent washing in finance

An agent might flag invoice discrepancies while people investigate and correct every exception. Marketing that as fully autonomous accounts payable would hide the actual workload. Accurately describing it as assisted exception review would let buyers assess its usefulness on honest terms.

These examples also show why buying the most autonomous system is not always the right decision. A predictable workflow may solve the problem at lower cost. The requirement should determine the architecture and the claim should describe that architecture fairly.

Warning signs to investigate

Warning signs are prompts for diligence, not proof of misconduct. Ask the vendor to explain discrepancies and demonstrate the relevant behavior before concluding.

• The capability is described only as autonomous or intelligent. Ask for the specific goal, inputs, decisions, permitted actions, and conditions that trigger escalation. Broad adjectives make it difficult to establish acceptance criteria.
• Every demonstration uses the same ideal input. Request a task the vendor has not rehearsed, using representative data and clear evaluation criteria. Include incomplete information or a business rule that changes the appropriate response.
• Human involvement is missing from the explanation. Ask who prepares inputs, approves actions, repairs outputs, and handles failures. Count both routine supervision and exception work when estimating the effort the system saves.
• Tool connections are presented as proof of agency. Request a trace showing how the system chose an action, received the result, and decided what to do next. An integration badge alone cannot demonstrate adaptive execution.
• Pilot findings are presented as established business performance. Ask for the deployment period, eligible task volume, adoption level and measurement method. A successful demonstration cannot establish sustained performance across real users and changing conditions.
• Success rates exclude difficult cases or failed attempts. Ask how the denominator is defined and whether retries, escalations, and abandoned tasks are included. Otherwise, apparently strong performance may describe only a selected subset of work.
• Governance claims remain abstract. Ask to see permissions, approval enforcement, operational logs, and a demonstrated stop mechanism. A slide about control is less useful than evidence that the system stays within its authorised scope.

How to evaluate AI agent claims

Evaluate each claim against observable evidence. For a business buyer, a practical assessment connects six questions rather than asking only whether the product deserves the agent label.

Start by defining a task that matters. For supplier review, that could mean producing a comparison against agreed criteria, identifying unsupported claims, and preparing clarification questions. Specify what counts as completion before the demo begins.

Then apply this claim-to-proof checklist:

Goal

What result is the agent responsible for delivering? Request a written scope that names eligible cases, exclusions, and acceptance criteria. A description such as supports procurement is too broad to test or price meaningfully.

Decisions

Which steps can the model select or revise? Request representative execution traces showing the next action chosen after new information arrives. The evidence should separate fixed routing rules from decisions the model actually makes.

Actions

What can the system read, write, send, or change? Request the tool inventory, permission model, and a demonstration of an attempted action outside its authority. Access should match the task and remain constrained by enforceable controls.

Human involvement

What requires preparation, approval or correction? Request intervention records and sample handling times. A system can be a genuine agent while still creating substantial work for employees, so include that effort in the business case.

Exceptions

What happens when information is missing, contradictory or unavailable? Test a failed tool call and an unresolved ambiguity. Ask the vendor to demonstrate when the system retries, stops or escalates instead of silently inventing an answer.

Outcomes

What evidence supports the claimed benefit? Request a baseline, representative sample, and measurement period. Compare completed work at an acceptable quality level, including operating costs and rework, rather than counting outputs or model calls.

This checklist is a practical evaluation method. The appropriate test depth depends on the workflow and consequences of failure. A low-risk research assistant and a system with payment authority require different acceptance criteria.

Execution records can show inputs, tool calls, returned results, approvals, and state changes. They do not need to expose a model’s private chain of thought. Testable behavior provides a stronger basis for evaluation than a generated explanation of why the agent believes it acted correctly.

Bring a real workflow to JADA and explore how we bring in agent AI adoption and build capabilities around its requirements.

Measure the result after the demo

A genuine agent can still be a poor investment. Reliability, adoption, and operating cost determine whether the system improves the workflow after deployment.

A useful production scorecard tracks the outcome and the work required to achieve it:

Successful task completion

Divide tasks completed to agreed quality and policy requirements by all eligible attempted tasks. Report exclusions, failures, and escalations separately so the rate cannot conceal work the system could not finish.

Human intervention

Track how often someone must approve, correct, or take over, and how long that work takes. Approval required by policy should remain distinguishable from intervention caused by a system failure.

Quality and rework

Sample outputs against the same criteria used for the existing process. Include missed requirements, incorrect actions and downstream corrections. Faster delivery has limited value if other teams must repair the result.

Cost per successful task

Include model usage, infrastructure, licences, monitoring and human handling. Divide by acceptable completions rather than total outputs. A low cost per model call can coexist with an expensive business process.

Measure time to completion and adoption

Track elapsed time from request to accepted result, alongside use by the intended team. Compare similar tasks and volumes; a fast system with little adoption may have little operational impact.

Establish the baseline before introducing the system. Review performance over a representative operating period and repeat checks when models, integrations, or business rules change. These measurements make claims about business value more defensible and help identify where ongoing management is needed.

Build and manage actual AI agents with JADA

The right partner should help you establish what an agent needs to do, build it around your systems, and keep it useful as the business changes. That is where JADA fits.

We assess workflows for measurable value, build custom AI agents within your technology and data environment, and manage them after launch. Human control is part of the design. Your organisation owns the code and IP, and collaboration and knowledge transfer help your team build the capability to operate the system.

That makes JADA a strong partner for businesses that want working agents, clear ownership and continued support. Talk to JADA about the workflow you want to improve and the result you need to measure.

Frequently asked questions

What is agent washing in AI?

Agent washing means presenting software as more agentic than its actual capabilities justify. It can involve rebranding automation as an AI agent, exaggerating autonomy or results, or obscuring human involvement and important limitations. The central issue is the gap between the claim and the evidence.

What is an example of agent washing?

A vendor calls a tool an autonomous customer service agent, but it only drafts replies and employees perform every account check and corrective action. If the marketing implies independent resolution, the claim exceeds the capability. Accurately describing the same tool as a reply assistant avoids that mismatch.

How can you tell an AI agent from scripted automation?

Ask what determines the next step. Scripted automation primarily follows predefined paths. An agent uses AI to choose steps or tools and respond to intermediate results within its scope. Request representative execution traces, and test changed inputs; the product name and a successful tool call are insufficient evidence.

Does human oversight mean an AI agent is fake?

No. Human oversight can be a deliberate control in a genuine agent system. An agent may investigate a problem and propose an action while a person approves execution. Agent washing occurs when the claimed independence hides those requirements or materially overstates what the system can complete.

How can a business avoid agent washing?

Define the task, permitted actions, and acceptance criteria before evaluating products. Test normal cases and exceptions, inspect records of execution and human intervention, and measure quality and total operating costs. Choose the architecture that fits the workflow and require evidence for each important capability or performance claim.