Skip to content
RiverCore
The Data Observability Bill Comes Due for AI Agents
data observabilityAI agentsRAG pipelinedata observability for AI agents costfixing wrong AI agent outputs

The Data Observability Bill Comes Due for AI Agents

24 Jul 20267 min readMarina Koval

The platform lead who greenlit a RAG-backed agent in Q1 is now looking at a Q3 board meeting with a support queue full of "the bot told me the wrong price" tickets. Nobody changed the model. Nobody touched the prompts. The knowledge store just quietly rotted, and the monitoring stack, built for pipelines rather than data, kept flashing green the whole time. That is the architecture decision every data org is about to relitigate, and the vendor pitches landing in inboxes this month are aimed squarely at the symptom rather than the disease.

What Happened

Two things collided in July. First, as VentureBeat reported in a piece by Junaid Effendi on July 22, enterprise AI teams are hitting a predictable failure mode: chatbot knowledge stores go stale within three months of deployment, and in the described scenario roughly a third of user queries start receiving confidently wrong answers. No model drift, no prompt regression. Just the world moving on while the retrieval layer doesn't.

Second, the hyperscalers noticed. AWS entered what the piece calls the "context layer" race with a knowledge graph that learns from agent usage. Snowflake shipped two new products, Horizon Context and Cortex Sense, aimed explicitly at agents giving confident wrong answers because nothing governs the business logic underneath them. Both vendors are pricing this as a net-new SKU, not a feature bundled into what customers already pay for.

Effendi's argument, drawing on his own tenure building observability at Socure and on public engineering from Uber and Netflix, is that the context layer sits one floor above the actual problem. Uber's Unified Data Quality platform, which predates retrieval-augmented generation entirely, supports more than 2,000 critical datasets and catches around 90% of data quality incidents before they hit downstream consumers. Netflix built a company-wide lineage system that maps dependencies across Kafka topics, ML models, and experimentation surfaces, not just warehouse tables. Both were built for humans and got more valuable once LLM applications showed up. The uncomfortable read: a knowledge graph is only as trustworthy as whatever feeds it, and most enterprises have not funded the layer that feeds it.

Technical Anatomy

The failure mode is elegant in the worst way. A standard retrieval pipeline scores relevance or availability. It does not score correctness. A stale pricing document, a schema where an upstream team silently renamed a field, a record with a missing attribute: all of these pass every check the pipeline was built to run. The model then answers with full confidence because the retrieved context looks authoritative. Dashboards stay green because dashboards are watching job completion, not truth.

Effendi recounts a pre-AI fintech incident that maps perfectly onto today's RAG failures: an upstream system changed a field without notifying downstream users, the pipeline ran clean, and the bad values propagated into dashboards until a customer noticed. Absence of an error is not the presence of correctness. That sentence should be printed on the wall of every data platform team shipping agent workflows this quarter.

The observability model he lays out has four dimensions worth budgeting against. Correctness: does each record conform to the shape and rules it should, with tools like Great Expectations and Soda handling row and column-level validation at ingestion. At Socure, where client data arrived in variable and occasionally incorrect formats, Great Expectations handled schema and range validation, and a write-audit-publish pattern staged data before it moved downstream. Freshness: time since last successful update per source, with an SLA per source rather than one blanket threshold, because a fraud signal and a marketing taxonomy do not need the same refresh cadence. Consistency: periodic cross-checks between downstream destinations, flagging mismatch rates above a threshold, because inconsistency fails silently until two systems fed by the same source start disagreeing. Lineage: the ability to trace any output back to its source and every transform along the way, which is what Netflix built for.

None of this is exotic. Most of it maps cleanly onto capabilities already sitting in a modern warehouse stack. A team on Snowflake can wire much of the correctness and freshness layer using primitives documented in the Snowflake docs, and dbt-native testing covers a real chunk of the validation surface via dbt tests. The gap is organizational, not technological.

Who Gets Burned

Three categories should be nervous. First, any regulated vertical shipping customer-facing agents on top of RAG: fintech onboarding assistants, iGaming responsible-gambling bots, health and insurance triage. In these verticals, a confidently wrong answer is not a support ticket, it is a regulatory finding. The GC who signed off on the agent's disclosure language did not sign off on a knowledge store that decays measurably within a quarter.

Second, series-B and series-C platform teams who bought a context layer SKU as a shortcut. Horizon Context, Cortex Sense, and the AWS knowledge graph are legitimate products, but they solve the governance-of-business-logic problem, not the is-the-underlying-data-still-true problem. Teams that skip the observability layer and buy the context layer will discover in month four that they are paying premium vendor pricing for a system whose inputs nobody validates. The unit economics get ugly fast: context layer consumption scales with agent usage, so a broken agent producing confident nonsense burns tokens at the same rate as a working one.

Third, and this is the least discussed piece, hiring managers. The market for engineers who can build Uber-style or Netflix-style internal observability platforms is thin, because for a decade those roles were treated as janitorial rather than strategic. Now every AI-forward org needs one, and they need one who can articulate lineage across Kafka, feature stores, and vector indexes rather than just warehouse tables. Expect comp for senior data platform engineers with observability experience to move meaningfully over the back half of 2026. Teams that try to solve this with a junior hire and a Great Expectations install will underdeliver.

The VP Engineering at a mid-market fintech should be asking her Head of Platform this week a very specific question: what fraction of the datasets feeding our production agents have queryable lineage, and what fraction only live in someone's head? If the honest answer is under half, the roadmap for Q4 needs to change before the next agent ships, not after.

Playbook for Data Teams

Start with coverage, not tooling. Enumerate the datasets that feed any production agent or LLM surface, and score each on the four dimensions. Correctness first, because it is the cheapest to instrument and the highest use: Great Expectations or Soda at ingestion, a write-audit-publish staging pattern before anything moves downstream, and validation percentages tracked per run rather than per incident.

Freshness next, and resist the temptation to set one blanket SLA. Per-source thresholds force the conversation about which data actually needs to be fresh, which surfaces the business logic that vendors are now trying to sell back as a context layer. Consistency checks should be scheduled cross-destination comparisons with a mismatch-rate alert, not a one-shot audit. Lineage is the longest build and the highest ROI once agent workflows multiply, so start scoping it now even if delivery is a two-quarter project.

On build-versus-buy: the context layer products are worth evaluating, but not as a substitute for the observability layer underneath. Treat them as governance on top of a data foundation you already trust, and if you don't trust the foundation yet, sequence the spend accordingly. The CFO conversation is simpler than it looks: observability spend is a fixed cost that prevents variable regulatory and reputational cost. Context layer spend is a variable cost that scales with usage of a system whose correctness you have not yet guaranteed.

Key Takeaways

  • AI agent knowledge stores decay within three months in the reported scenario, producing confidently wrong answers on roughly a third of queries with no model or prompt changes.
  • AWS's knowledge graph and Snowflake's Horizon Context and Cortex Sense address governance of business logic, but sit one layer above the actual data observability gap.
  • Uber's Unified Data Quality platform covers 2,000-plus critical datasets and catches around 90% of incidents before they hit consumers; it predates RAG entirely, which is the point.
  • Budget against four measurable dimensions: correctness, freshness with per-source SLAs, consistency via cross-destination cross-checks, and queryable lineage.
  • Teams evaluating context-layer SKUs this quarter should first ask what fraction of their agent-feeding datasets have observability coverage, and price the vendor decision against that number, not against the demo.

Frequently Asked Questions

Q: Why do AI agents give confidently wrong answers even when the model and prompts haven't changed?

Because retrieval pipelines score for relevance and availability, not correctness. A stale document or a record with a silently missing field still scores high and gets served to the model, which then answers confidently based on outdated context. The reported failure mode sees knowledge stores decay within three months of deployment.

Q: Do Snowflake's Horizon Context and Cortex Sense solve the data observability problem?

They address a related but different problem: governing the business logic that agents reason over. They still depend on the quality of the data feeding them, so teams that skip investment in correctness, freshness, consistency, and lineage will get limited value from context-layer products alone.

Q: What should a data platform team actually build first?

Start with correctness validation at ingestion using tools like Great Expectations or Soda, paired with a write-audit-publish staging pattern. Then add per-source freshness SLAs and cross-destination consistency checks. Lineage is the longest build but delivers the most use once multiple agent workflows depend on the same upstream sources.

MK
Marina Koval
RiverCore Analyst · Dublin, Ireland
SHARE
// RELATED ARTICLES
HomeSolutionsWorkAboutContact
News06
Dublin, Ireland · EUGMT+1
LinkedIn
🇬🇧EN▾