Your AI Agent Vendor Is Probably Lying to You. Five Questions That Prove It.

A client of ours sat in a vendor demo last quarter watching an “autonomous agent” process invoices. The agent pulled data from SAP, matched line items, flagged discrepancies, routed approvals. The whole room was nodding.

We asked one question: what happens when the vendor changes the PO format?

The demo froze. Not metaphorically. That “autonomous agent” was a rules engine with a language model answering questions about its own output. It could not adapt to a field it had not been mapped to. It was not an agent. It was automation wearing a new label.

This is happening everywhere. And as of this week, it is no longer just a procurement problem. It is a legal one.

A Securities Law Firm Just Put Every AI Agent Claim on Notice

On March 25, Debevoise & Plimpton published a formal advisory warning that “agent washing” now carries the same disclosure risk as the AI washing cases the SEC has already prosecuted. If you say “fully autonomous” and your system requires a human to approve every action, you are exposed. If you say “enterprise wide” and your agent handles one narrow workflow, you are exposed.

Industry estimates suggest that out of the thousands of vendors now selling “AI agents,” roughly 130 are building genuinely agentic systems. The rest are relabeling what they already had. Your procurement team probably cannot tell the difference. That is the whole point of the label.

The Demo Works. Your Data Breaks It.

We build and deploy these systems for clients in financial services, healthcare, government, media, and enterprise tech. We also get called in after someone else’s “agent” project stalls. The pattern is consistent.

The vendor demo looks clean because the demo environment is clean. A curated database. A well documented API. No exceptions. The moment that system meets your actual ERP, your actual approval chains, your actual data, the agent reveals itself as a script with a fixed path. It cannot reason about what to do when the path breaks. It stops. Or worse, it quietly does the wrong thing.

There is a term for this that we like: “agentic workslop.” Agent applications that actually add work to a process. You now have the original workflow, plus a new system to babysit, plus the incidents it creates. We had a client in healthcare whose vendor sold them an “intelligent document processing agent” for claims intake. Six weeks in, the operations team had built a parallel manual process to catch the 30% of cases the agent could not handle. It was not reducing headcount. It was creating a shadow team.

Five Questions That Expose a Fake Agent in Ten Minutes

Before you sign anything, run these in the demo. They cost nothing and they will save you six figures.

1. During the demo, change a column name in the input file. Or move a field to a different position. Then ask the system to run again.

If it handles the change and still produces the right output, it is reading the structure and adapting. If it breaks or returns garbage, it was hard coded to expect a specific format. That is a script, not an agent. You will hit this on day one in production when a vendor updates their invoice template or a client sends a report in a new layout.

2. Point to a specific output and ask: why did the system do this and not something else? Ask to see the log.

A real agent keeps a record of every decision it made: which tools it called, what data it pulled, why it chose path A over path B. If the vendor cannot show you this log, the system has no decision making. It runs the same steps every time in the same order. That is fine for simple tasks. It is not what you are paying for.

3. Give it a request that is slightly outside what the demo covers. A document type it was not shown, a field with unexpected values, a rule that conflicts with another rule.

Watch what happens. A real agent will flag the problem, ask for guidance, or try a new approach and tell you what it did. A fake one will freeze, skip the item silently, or make something up. This matters because your production data is full of edge cases the demo will never show you.

4. Ask: what exactly can this agent access in our systems, who decides that, and what happens if it tries to do something it should not?

Two weeks ago, an internal AI agent at Meta went rogue, gave wrong advice on an internal forum without approval, and an employee followed that advice, exposing sensitive data for two hours. The agent had valid credentials the entire time. Every security check said it was authorized. If the vendor cannot tell you exactly what the agent is allowed to touch, who set those limits, and how often those permissions are reviewed, you do not have a security model. You have a liability.

5. Say: we want to run this on a sample of our actual data before we commit. Not your demo data. Ours.

This is the question vendors push back on hardest. They will say it requires setup, integration work, a separate scoping phase. Insist. The gap between their clean demo data and your messy production data is where every failed AI project lives. If they will not do it, ask yourself why.

Four Things No Rebranded Workflow Can Fake

We are not saying the technology does not work. It works extremely well when it is built for a specific problem with clean integration, proper governance, and human oversight at the right decision points. A real one does a few things no relabeled workflow can fake:

• It adapts when something changes. A new document format, a schema update, an unexpected exception. It figures out a path instead of stopping.
• It explains itself. Every action has a trace. Every decision has a rationale. Your compliance team can audit it on Monday morning.
• It knows its own limits. When confidence drops below a threshold, it escalates instead of guessing. The best ones fail gracefully. The worst fail invisibly.
• It operates with scoped, time bound permissions. Not a shared API key from six months ago. Least privilege, every time.

The difference is simple. One follows instructions. The other follows objectives. If you cannot see that distinction in the demo, it does not exist in the product.

Off the Rack Does Not Fit. You Need a Tailor.

Here is the tension nobody in the room wants to say out loud. Your technical team does not want to learn the business context required to make these tools produce ROI. They want to build. Your business team is using AI like a search engine, typing a question, getting a paragraph back, and calling it productivity. Neither group is wrong. Both are stuck.

An off the rack AI agent does not know your approval chains, your compliance rules, your data structure, or your customer logic. It never will. That is not a product limitation. That is the nature of the problem. Building an agent that actually works inside your business is tailoring, not shopping. Someone has to cut the fabric to fit your operations, your people, your constraints.

That is what we do. We build agents that fit. And when the engagement ends, we leave your team with the skills to do their own tailoring, because the business will change and the agent will need to change with it. We are not here to create a dependency. We are here to close the gap between what you bought and what you need it to do.

Ask the five questions. Insist on the proof of concept. And if you realize you need a tailor, not another vendor, that is a different conversation.