Why AI agents fail with confidence: it's not the model or the context, it's data engineering

The VentureBeat article, written by Junaid Effendi, raises an underlying problem that many enterprise AI teams are experiencing without knowing how to name it: a chatbot or agent that worked well at launch begins, months later, to give wrong answers with complete confidence, even though no one has touched the model or the prompts. The cause, according to the author, does not lie in the AI itself, but in the fact that the world changed (prices, policies, product versions) and the knowledge store that feeds the system did not update at the same pace.

The core of the argument is that this type of failure is invisible by design. Whether an agent retrieves information from a vector database, a document index or an API call, the retrieval mechanism evaluates relevance or availability, not correctness. An outdated pricing document is retrieved with the same confidence as a current one, and a record with a silently empty field passes the same checks as a complete one. The result is that dashboards stay green, the pipeline appears to work, and yet the system is delivering false information. The author illustrates this dynamic with a case outside the AI domain: at a fintech company, an upstream system changed a field without notifying the systems that depended on it, and the pipeline did not technically fail—it simply propagated incorrect values to the dashboards, because it only verified that the job completed, not that the data remained correct. The problem was only detected when a customer noticed an inconsistency, and by then the erroneous data had already spread.

According to the article, organizations that run into this failure tend to misdiagnose it—and do so twice over. The first instinct is to blame the model and try another LLM or adjust the prompt. Once that is ruled out, the second instinct is to blame the retrieval layer and look for a better tool. The author connects this second instinct to recent market moves: AWS has reportedly entered the "context layer" race with a knowledge graph that learns from how agents are used, and Snowflake has reportedly launched Horizon Context and Cortex Sense aimed precisely at the symptom described at the start of the article—agents that answer wrong with confidence because nothing governs the underlying business logic. The author acknowledges that both are real responses to a real problem, but argues that they sit one layer above the root: a knowledge graph still depends on what feeds it. The real problem lies further up, in data engineering, where teams check whether a job ran, not whether the data it moved is still true—a habit that predates AI and that current monitoring carries over: it is designed to watch the pipeline, not the data.

What is missing, the author argues, is data observability understood rigorously. The relevant metric is not an isolated percentage but coverage: what fraction of critical datasets has a genuinely queryable lineage, rather than living only in someone's head. As examples predating the arrival of LLMs, the article cites Uber, which built a dedicated data quality and observability platform (Unified Data Quality) that covers more than 2,000 critical datasets and detects around 90% of quality incidents before they reach downstream consumers. Netflix, for its part, reportedly solved a different piece of the same problem by building a company-wide data lineage system that lets anyone trace where a dataset comes from and what touched it along the way, mapping dependencies among Kafka topics, machine learning models and experiments, not just data warehouse tables. The author notes that both systems were originally designed for humans and that their importance has grown with the rise of AI/LLM applications.

Between Uber and Netflix, the article contends that only two of four dimensions are covered—dimensions that, according to the author, must be measured separately: first, correctness, that is, whether each record meets the expected shape and rules, correct field types, no unexpected nulls, values within range; for this, tools such as Great Expectations and Soda are mentioned, which enable automated validation at the row and column level instead of manual checks after a failure, measuring the percentage of records that pass validation on each run. Second, freshness, or whether the data remains current relative to its source and not just relative to the last time it was checked; the proposal is to measure the time since the last successful update per source, with a specific SLA per dataset rather than a single threshold, since some sources need hourly refresh and others do not. Third, consistency, that is, whether the same fact reads the same across all systems where it is stored or indexed; this failure is silent and only appears when two systems fed by the same source begin to diverge, so a periodic cross-check across downstream destinations that flags when the discrepancy rate exceeds a threshold is enough. Fourth, lineage, the ability to trace any output back to its origin and every transformation it passed through, the same question Netflix solved with its system.

The author adds his own experience at Socure, where customer data arrived in whatever format each customer chose to send it, and occasionally in a silently incorrect way. The challenge was to build a system capable of identifying incorrect data before it propagated downstream, applying the same principles: validate what arrives, understand where it comes from, and prevent bad data from becoming someone else's problem. Great Expectations was part of that foundation, along with schema and range validation at ingestion, freshness SLAs per source, cross-checks for consistency and file-level lineage, all underpinned by a "write-audit-publish" pattern, in which data first lands in a staging area, is validated, and only moves downstream if it passes the required checks. According to the author, the result showed up in accuracy improvements both in reporting and in machine learning models and in the AI data retrieval built on that same foundation.

The article closes with a list of four diagnostic questions for those operating retrieval-based AI systems in production, arguing that the relevant question is not which model to try next or which retrieval architecture to migrate to: is the underlying data validated according to the standards its consumers require?; what is the oldest piece of content currently being served with high confidence?; could two fragments from the same source end up contradicting each other within a single retrieval result?; and could the origin of a data point be traced if it turned out to be wrong? If these questions cannot be answered, the author concludes, the problem lies in the pipeline between the source systems and what the agent reads, and the solution runs through data engineering, not through changing the model or the provider. He closes with the idea that, whether it is reporting pipelines, machine learning systems or AI agents, correctness, freshness, consistency and lineage are what make data trustworthy, and that AI is simply exposing weaknesses that already existed in data engineering long before.