I’ve spent my entire career inside the messy, unglamorous world of enterprise software—building ERP systems, wrestling with CRM implementations, and pushing data through pipelines that refuse to cooperate. I’ve seen the full arc of technological hype, from the promise of cloud computing to the rise of big data. And in recent years, I’ve watched the term “AI” get stretched, bent, and twisted into a marketing buzzword that has almost lost its meaning. I remember sitting in a conference room, watching a vendor deliver a demo of their new “autonomous” software. The room was impressed; there were nods and murmurs of approval. The tool could handle a simple customer query with impressive speed. But a few weeks later, during the pilot, the whole thing collapsed over a single obscure edge case. The “AI” was just a set of hardcoded rules, a chatbot with three pre-scripted branches. The vendor had called it autonomous, but it was essentially a glorified decision tree. This wasn’t just a case of over-enthusiasm; it was a fundamental disconnect between the language of marketing and the reality of engineering, and it’s a disconnect that costs companies billions.
This frustration isn’t just anecdotal. A recent study from MIT Nanda found that a staggering 95% of enterprise generative AI pilots fail to deliver any measurable profit or impact. We’re not talking about small sums; this represents a burn rate of $30 to $40 billion. The money went into tools and platforms that were sold as “adaptive” and “intelligent” but were often static, brittle systems that couldn’t handle the complexity of the real world. The core problem is that “AI-powered” has no agreed-upon definition. It covers everything from a sophisticated machine-learning model that can predict customer churn to a simple script that automatically sorts emails into folders. When a salesperson says “AI,” they might mean a genuinely intelligent system. When an engineer hears “AI,” they might think of a massive neural network. This ambiguity creates a dangerous gap where dashboards get padded with “AI features” that are actually just a series of “if-then” statements. We are drowning in a sea of AI theater, where the appearance of intelligence is more important than the substance.
To cut through this noise, I’ve developed a personal “detox” process. It’s a simple litmus test I run on any feature or product that claims to be an intelligent agent, a framework to force a conversation back to reality. The first and most important question is: What decision does it make without a human? A true agent must be able to take an autonomous action and accept the consequence. For example, it might automatically approve a standard discount for a long-standing customer or directly route a support ticket to the appropriate engineering team. If the system only suggests an action and waits for a person to click “approve,” then it is not an agent; it is a recommendation engine. You can dress it up with charts and confidence scores, but the moment you need a human in the loop for the critical step, you’ve built a glorified suggestion box. This is a crucial distinction because it changes the entire architecture of the system you are building. Suggestion boxes are generally safe and straightforward. True agents require robust guardrails, error handling, and a clear audit trail.
The second question is a killer in disguise: What happens on an input it has never seen? This is where the demos stop and the real world begins. A demo is a performance; it’s a carefully curated path designed to show the system at its best. A pilot is a test; it introduces the chaotic, unpredictable data that exists in every real business. A deterministic system—one built on rigid rules—will fail loudly when it encounters an unexpected scenario. It will throw an error, crash, or return a nonsensical result. It “hits the else branch and stops.” A true AI agent, built on a probabilistic model, should degrade gracefully. It might offer a best-guess response with a note of uncertainty, or it will ask for clarification. I can’t tell you how many times I’ve asked a vendor for a live test with a simple, unscripted input—a random date format, a misspelled city name—only to watch their “AI” power a spectacular, and often silent, failure.
Next, I ask: Can it explain why, or only what? This probes the very nature of the intelligence being employed. A rule-based system can restate its logic. If you ask “why did you deny this customer’s credit?,” it will say, “Because their credit score is below 600,” following the rule you programmed. But it cannot tell you the why behind that rule’s efficacy or qualify its response based on the nuances of the situation. A robust model, on the other hand, can offer a degree of confidence and highlight the factors that most influenced its decision. For example, a true agent might say, “I denied the credit request because the customer’s payment history has declined by 30% in the last quarter, which is my primary driving factor with 80% confidence.” If the system cannot articulate its own reasoning beyond a hardcoded “because I said so,” then the “intelligence” resides in the flowchart, not in the model.
Closely related to this is the question of Does it change behavior as data changes? A core promise of machine learning is adaptation. The system should learn and improve from new data. If you feed a system a month of new, relevant data and its behavior remains completely static, then it is not learning; it is just a configuration. This is a common trick. Teams will invest in a sophisticated model, train it on historical data, and then deploy it without the infrastructure to continue learning. The system is frozen in time, a static snapshot pretending to be a living intelligence. A true agent will fine-tune its decisions, adjusting its recommendations based on the latest feedback. The difference between a configuration and a learning system is the difference between a printed map and a GPS that recalculates your route in real-time.
Then comes the architectural question: Where does the model actually sit in the call path? This is where you expose the most AI-washing. I always trace the request from the user’s click all the way to the database query. Too often, you find the “AI” is a small cosmetic add-on. The core logic is a standard, hardcoded process. The model is only used to reword a confirmation email or to change the tone of a notification. It’s decoration. It’s like putting a Formula 1 wing on a golf cart. The model isn’t making any significant decision; it’s just polishing the output. For the system to be a true agent, the model must be in the critical path. The model’s output should determine the next action, not just the phrasing of the result.
And if the model is in the critical path, then we need to talk about money. I always ask, What is the token cost per action? Many people are blinded by the magic of AI and forget that it has a real, measurable operational cost. Every prompt you send to a large language model is money. If a “simple” agent is consuming $10 in API credits for a task that a $0.01 database query could solve in milliseconds, you have a serious financial problem. When I ask a team about their cost per transaction, I often get a blank stare. They haven’t even looked. They are so enamored with the technology that they’ve ignored the economics. A team building a real agent knows this number intimately because it directly impacts their budget and their unit economics. This question forces the conversation from “cool technology” to “viable business.”
This naturally leads to the question of Can it run a multi-step task and recover mid-way? This is about robustness. A true agent is a conductor of an orchestra. It can perform a series of actions in sequence to achieve a goal: it might look up an order, check inventory, contact a supplier, and update a shipping schedule. If the third step fails—if the supplier’s API is down—what happens? A brittle, scripted flow will crash. A true agent will adapt. It will note the failure, try an alternative supplier, or pause and wait for instructions. This resilience is a hallmark of intelligence. If your system is just a linear chain of process steps, it’s not an agent; it’s a workflow, and there are excellent, non-AI tools for building those.
Finally, I ask about the foundation: What did it cost to build in data? This is the tell I trust the most. Anyone can buy a model, but the real asset is the data used to train and ground it. My experience building a machine-learning model for Amazon taught me this. The model architecture was only half the battle. The real work was in the data: the labeling, the cleaning, the validation. We spent months making sure our training data was accurate because a model is only as good as the information it’s given. So, when a team claims to have a powerful agent, I ask about their data pipeline. Who cleaned the data? How was it labeled? How often is it updated? If they hesitate or say “we just used a pre-trained model,” they’re building on a house of cards. The model is a Ferrari, but without a road of quality data, it’s not going anywhere.
The final, and most brutal test, is to let an architect read the code. Marketing slides can lie, but code is the truth. The answer to all my previous questions is written in the source code. I want an engineer to open the repository and see if the system is a network of if-else statements, or a pipeline with a real learning loop. I want to see the actual prompts being used and the logic for when the system calls an external model versus a database. If the people who wrote the marketing deck refuse to let an engineer walk the steering committee through the code, you have your answer. The label is doing work the product cannot. The architecture will betray the AI-washing in an instant.
So, this is my process. I take every “AI” feature on the roadmap and put it through this crucible. I classify each one into one of three buckets: Agent, Model-assisted, and Rules. A true Agent makes an autonomous decision, adapts to data, and has a model in the critical path of core actions. A Model-assisted feature uses AI to enhance a step, but a human makes the final call. It’s honest, valuable, and should be labeled as such. The third bucket is Rules: deterministic logic. This is often the right tool for the job, and there’s no shame in it. The shame is in calling it an AI.
When I run this process, I often have to move features out of the “Agent” bucket and into the others. It’s not a downgrade; it’s an act of clarity. A clean rules engine that doesn’t pretend to be something it’s not is far more valuable than a fragile agent that will fail an audit. The goal isn’t to have a roadmap full of “AIs.” The goal is to build reliable, maintainable, and effective systems. The teams that cross the divide between hype and reality are the ones that embrace this. They use honest labels because honest labels are the only ones that architects can build upon, CFOs can fund, and customers can trust. It might not be as flashy, but it’s the only way to build something that actually works. Don’t fall for the AI theater. Ask the hard questions.