How Enterprises Should Evaluate AI Vendors

Every AI demo works. That is precisely the problem, and it is why the questions that matter almost never get asked in the room where the buying decision is made.

The demo is going beautifully, which is the first thing that should worry you. A vendor's solutions engineer is driving a polished interface through a scenario that has clearly been run a hundred times, and the software is handling it with an ease that feels like proof. A request comes in, the agent reads it, pulls the right record, drafts the right response, and closes the loop, all narrated in the confident present tense of a product that has already solved your problem. The room nods. Someone from procurement asks about pricing tiers, someone from IT asks about SSO, and the meeting moves toward a conclusion everyone in it was gently steered toward before it began. What almost no one asks is the only question that predicts whether this will survive contact with your actual business: what happens when the request is one the vendor did not rehearse, and how would you ever know what the system did about it after the fact.

This is the structural weakness in how most enterprises evaluate AI vendors right now. The evaluation is built around the demo, and the demo is built around the cases that work, so the entire process is optimized to confirm a decision rather than to stress it. Meanwhile the failure rate of these projects is not a rumor. Gartner has predicted that over forty percent of agentic AI projects will be canceled by the end of 2027, citing escalating costs, unclear business value, and inadequate risk controls, and warning specifically about "agent washing" — older chatbots, rule engines, and robotic process automation dressed up in the language of autonomy without any change in what they can actually do on their own. A better evaluation is not a longer checklist or a stricter procurement gate. It is a small set of questions designed to find the seams the demo was arranged to hide, and to distinguish a system that genuinely acts from one that merely performs acting under controlled conditions.

Ask when, not whether, on everything that touches security and error

The first move that separates a serious buyer from a hopeful one is a change in the grammar of the security conversation. Most evaluations ask whether a vendor is secure, whether it is compliant, whether it can be trusted with sensitive data, and every vendor has learned to answer yes to all of it, with a certification logo and a confident paragraph. The question phrased that way has no discriminating power, because the honest answer and the marketing answer are indistinguishable. The productive reframing is to ask not whether but when: not "is this secure" but "when this system takes an action it should not have, what specifically stops it, who is notified, and how fast." You are not looking for reassurance that failure won't happen. You are looking for evidence that the vendor has thought seriously about the fact that it will, because a system that acts on your behalf in the real world will eventually act wrongly, and the maturity of a vendor is measured entirely by what they have built for that moment rather than by how strenuously they deny it can arrive.

The same reframing applies to permissions and blast radius, and it tends to expose the difference between a product designed for the enterprise and one retrofitted to sell to it. Ask when the agent needs to touch a system it has never touched before, what governs that; when it moves money or changes a customer record or sends something to the outside world, where the boundary sits that requires a human to sign off. A vendor with real answers will describe a permission model, a gateway that mediates what the system can reach, an audit surface, and a set of decisions that are deliberately kept on the human side of the line. A vendor without them will redirect you to the certifications, and that redirection is itself the answer. Enterprise deployment is not a feature you can bolt on after the pilot; it is an architecture the vendor either built from the start or did not, and asking "when, not whether" is the fastest way to tell which.

Demand a replayable trace, and test the case the vendor never rehearsed

If there is a single technical demand that cuts through agent washing more cleanly than any other, it is this: ask to see the trace. When the agent handled that flawless demo scenario, something happened between the input and the output — the system observed some things, retrieved some context, reasoned toward a decision, and took an action — and you should be able to replay that entire chain after the fact, step by step, and understand exactly why it did what it did. A system built on genuine reasoning can show you its work, because the work is a real sequence of observations and decisions that leaves a record. A repackaged rule engine cannot, because there is no reasoning to replay, only a branch that fired, and the moment you ask a relabeled chatbot to justify a non-obvious decision it made three steps deep, the explanation dissolves into a shrug. The replayable trace is not a nice-to-have for the compliance team. It is the load-bearing evidence that there is something real underneath the interface, and its absence should end the evaluation.

The trace only matters, though, if you feed the system something it has never seen, which is why the most important part of any evaluation is the case the vendor did not get to prepare. Bring your own scenario, and make it an ugly one — the request that is really three requests tangled together, the record with the contradictory field, the situation that sits in the gap between two of your policies where even your own people have to stop and think. The demo scenarios are chosen precisely because they are clean, and a workflow with a fixed path will handle every clean case and fail the first genuinely unfamiliar one, because it can only do what its designer anticipated in advance. What you are testing is not whether the system is impressive on the happy path but whether it can reason about a situation nobody wired a branch for, degrade gracefully when it is uncertain, and know the difference between a decision it can make and one it must escalate. A vendor confident in their system will welcome your worst case. A vendor selling agent washing will find a reason to take it offline and follow up later.

Separate the thing that assists from the thing that executes

Underneath the security questions and the trace and the unfamiliar case sits one distinction that organizes all of them, and it is the distinction the word "agent" has been deliberately blurred to obscure. There is an enormous difference between a system that assists a person and a system that executes on its own, and almost the entire market has an incentive to make the second sound available while shipping the first. An assistant drafts and waits for you to accept; it proposes and you decide and act; it makes your people faster at work they are still fundamentally the ones doing. That is a real and useful category, and if that is what you need, buy it with clear eyes. But it is not autonomy, and if you are evaluating a vendor on the promise that it will absorb a class of work rather than accelerate your team through it, you have to establish which of the two you are actually being sold — because a copilot priced and staffed as if it were an autonomous worker is the exact shape of the projects Gartner expects to be canceled.

The test for this is concrete and it is unforgiving: ask what the system does when no one is watching. An assistant, by construction, needs a human in the loop continuously, because its output is suggestions that a person converts into action, and if you take the person away the value stops at the draft. A system that genuinely executes carries the work through to completion on its own, pulling context across the systems that hold it, taking the action, and stopping to bring a human in only at the decisions that warrant one, rather than at every mechanical step. This is the design philosophy behind the platforms built for what a growing number of operators now call the autonomous enterprise, and it is the line StudioX draws between an Assistant and an Autonomous AI Worker — the former sits beside your people, the latter runs a mission end to end under human-in-the-loop gates, with a reasoning core you can inspect and observations you can replay. Whether or not that particular vocabulary is the one you adopt, the underlying question is the one your evaluation has to force into the open, because everything about the cost, the staffing, and the return depends on which category you actually bought.

The mental model to carry into the next vendor meeting, then, is that you are not there to be convinced. You are there to run the experiments the vendor would prefer you didn't: to ask when their system fails rather than whether, to demand the replay of a decision they cannot pre-script, to hand them the case they never rehearsed, and to make them say plainly whether the thing acts or merely assists. A vendor with real autonomy underneath will find these questions easy, almost welcome, because their answers are the product. A vendor selling a relabeled workflow will experience them as friction and route around them — and that reaction, more reliably than any demo, is the signal you came to find.