Every enterprise software company on the planet is racing to ship AI-powered analytics agents. The pitch is seductive: ask a question in plain English, get an answer from your data, no SQL required. But there’s a growing and uncomfortable realization among the people actually building these systems that bigger models and fancier architectures aren’t solving the real problem. The real problem is trust.
And trust, it turns out, is an engineering challenge — not a model-size challenge.
Taras Savytskyi, a senior data analyst at Edenred and a contributor to The Next Web, made this case with unusual clarity in a recent analysis that cuts against the grain of the industry’s current obsession with ever-larger foundation models. His argument: the bottleneck in deploying AI analytics agents isn’t intelligence. It’s reliability. Companies don’t need agents that are smarter. They need agents that fail gracefully, explain their reasoning, and know when to stop.
This matters enormously right now. The market for AI-driven business intelligence is expanding rapidly, with organizations from mid-market firms to Fortune 100 companies integrating conversational analytics into their workflows. Microsoft’s Copilot is embedded across the Office suite. Salesforce has Einstein. Google has Gemini woven through its Cloud offerings. Startups like ThoughtSpot and Databricks are building natural-language query layers atop massive data platforms. The technology works — sometimes spectacularly well, sometimes catastrophically wrong.
That inconsistency is the whole ballgame.
Savytskyi’s core observation, as reported by The Next Web, is that most failures in AI analytics agents don’t stem from the model misunderstanding a question. They stem from the absence of structural guardrails — the kind of constraints that would prevent the agent from generating a plausible-sounding but fundamentally incorrect answer. A model might produce syntactically valid SQL that runs without error but joins the wrong tables, applies the wrong filters, or misinterprets a business term like “active customer” in a way that doesn’t match the company’s actual definition.
This is a familiar failure mode to anyone who has worked in data engineering. The difference is that when a human analyst writes bad SQL, there’s usually a review process. Someone catches it. When an AI agent writes bad SQL and auto-generates a dashboard or a summary, it can propagate through an organization before anyone realizes the numbers are off. The speed that makes these agents valuable is the same speed that makes them dangerous.
So what does a guardrail look like in practice? Savytskyi points to several architectural patterns. Semantic layers that map business terminology to precise database definitions. Validation steps that check query outputs against known baselines or historical ranges. Confidence scoring that flags when the agent isn’t sure about its interpretation. And perhaps most importantly, transparency mechanisms that show the user exactly what query was generated and what assumptions were made, rather than presenting a polished answer with no visible working.
None of this is glamorous. None of it makes for a compelling keynote demo. But it’s the difference between a toy and a tool.
The broader industry context reinforces this point. Recent reporting from multiple outlets has highlighted the growing tension between the marketing promises of AI analytics and the operational reality. A June 2025 analysis from Gartner noted that while adoption of AI-augmented analytics tools has surged, fewer than 30% of enterprise deployments have moved past pilot stage — a number that has barely budged in two years. The primary barrier cited by IT leaders isn’t capability. It’s governance.
Governance, in this context, means something specific: the ability to control what the AI agent can access, what it can do with that access, and how its outputs are validated before reaching a decision-maker. These are table-stakes requirements for any system that touches financial data, customer data, or operational metrics. And yet the dominant development paradigm in AI right now — scale the model, add more parameters, fine-tune on more data — doesn’t directly address any of them.
There’s an instructive parallel in the history of enterprise software. In the early days of business intelligence, the industry went through a similar cycle. Vendors competed on the power of their query engines, the sophistication of their visualization layers, the speed of their OLAP cubes. But the companies that ultimately won — the Tableaus, the Lookers — were the ones that figured out governance, permissioning, and data modeling. The flashy stuff got attention. The boring stuff got adoption.
AI analytics agents are at a similar inflection point. The models are good enough. GPT-4, Claude, Gemini — they can all generate competent SQL, interpret charts, and summarize data with reasonable accuracy on well-structured datasets. The gap isn’t in what they can do on a good day. It’s in what happens on a bad day. And in enterprise settings, bad days aren’t exceptions. They’re Tuesday.
Savytskyi’s prescription, per his Next Web piece, is essentially a call for engineering discipline. Treat the AI model as one component in a larger system, not as the system itself. Wrap it in validation logic. Give it access to metadata that constrains its interpretation. Build feedback loops so that when it gets something wrong, the correction improves future performance. And critically, never let it present an answer without showing its work.
This last point — showing the work — is where the tension between user experience and trustworthiness becomes most acute. Product designers want clean, simple interfaces. A question box. An answer. Maybe a chart. But analysts and decision-makers who understand data know that a clean answer without context is often worse than no answer at all. The number says revenue is up 12%. Up 12% compared to what? Over what period? Including or excluding returns? Using which exchange rate? These aren’t pedantic questions. They’re the questions that determine whether the number means anything.
Some companies are starting to get this right. Databricks has invested heavily in its Unity Catalog as a governance layer that AI agents can reference. dbt Labs has been positioning its semantic layer as the connective tissue between raw data and AI-generated queries. Snowflake’s Cortex AI features include guardrail configurations that let administrators define what the agent can and can’t do. These are moves in the right direction, but they’re still early.
The startup world is catching on too. A crop of newer companies — including Rill Data, Lightdash, and Steep — are building analytics tools where the AI component is explicitly constrained by a well-defined metrics layer. The philosophy is the same one Savytskyi articulates: don’t make the model smarter, make the system around it more disciplined.
But the incentive structures in the industry still favor the opposite approach. Venture capital flows toward companies that can claim the most advanced AI capabilities. Enterprise buyers, influenced by years of marketing, often evaluate tools based on how impressive the demo looks rather than how reliable the output is in production. And the major cloud providers, locked in their own AI arms race, keep pushing model size and benchmark performance as the primary measure of progress.
This creates a dangerous gap. The tools that get the most attention and investment aren’t necessarily the ones that are safest to deploy. And the organizations that adopt them without building proper guardrails are setting themselves up for a reckoning — not a dramatic, headline-generating failure, but the slow erosion of trust in data-driven decision-making as people encounter one too many AI-generated numbers that don’t add up.
The fix isn’t complicated in concept. It’s complicated in execution. Building a reliable AI analytics agent requires deep integration with an organization’s data infrastructure — its schemas, its business logic, its access controls. It requires treating prompt engineering not as a hack but as a formal discipline with version control and testing. It requires investing in evaluation frameworks that measure not just whether the agent can answer a question, but whether it answers it correctly, consistently, and in a way that matches organizational definitions.
Savytskyi’s framing is useful precisely because it resets expectations. The question isn’t “how smart is your AI agent?” The question is “how wrong can it be before someone notices?” In analytics, where decisions flow from data, the cost of a confident wrong answer is almost always higher than the cost of no answer at all. An agent that says “I’m not sure — here’s what I found, but you should verify these assumptions” is more valuable than one that produces a crisp, authoritative, and incorrect result.
The industry will likely come around to this view. It always does, eventually. The hype cycle for enterprise AI is following a well-worn path: inflated expectations, followed by disillusionment, followed by the hard work of building things that actually work in production. The companies that skip ahead to the hard work — the guardrails, the governance, the validation — will be the ones that capture lasting value.
Everyone else will have very impressive demos.
WebProNews is an iEntry Publication