Zombie data: why AI agents trust stale records

An AI agent on your data platform answers with the same confidence whether the record it read is current, abandoned or duplicated. Nothing in a stale row tells the agent it is stale. Most agent failures in production start right there, in the data the agent reads, and the four most common causes are fixed in the data model.

The agent answered from the data it had

Picture an AI agent that tells a sales rep a customer has cancelled. The customer hasn't. The cancellation request is still pending, and the agent read a replica that only refreshes in batch jobs. The rep passes the news on, and a customer who wanted to stay hears that their service ends at the close of the month.

The agent did exactly what it was asked, with exactly the data it could reach. That pattern is common. Research on agent failures in production found that most incidents traced back to the data layer feeding the agent. They are hard to catch, because they arrive as confident answers.

Halloween is a good week to name the four problems that show up most. Each one looks alive, and each one fools an agent the same way.

The zombie: a stale copy that still answers

A zombie record died a while ago and kept walking. The source system has moved on, and the copy the agent reads still shows the old state because it last synced at 3:00 this morning.

A person looking at a dashboard notices the timestamp and shrugs. An agent doesn't look. Two decisions in the data model take the zombie away. Every row carries a load timestamp, stamped in UTC, so freshness is a fact the agent can read. And the data model records which system is the source of record for each attribute, so an agent answering a question about subscription status knows where the live answer sits and how old its copy is allowed to be.

The ghost: a column nobody owns

Every warehouse has a few. Take a column called churn_flag_v2, last changed in 2023 by someone who has since left. Nobody knows whether it is still maintained, and it still feeds a churn score and, now, an agent.

Ownership is metadata, and it belongs next to the data model. When every attribute has a named owner and a description that lives with its definition, an agent can check whether a column is governed before it uses it, and a person knows who to ask when it isn't. Unowned columns stop hiding. They become a list someone can work through.

The vampire: one customer under two keys

The vampire drains your totals. CUST_0042 in one system and cust-42 in another are the same company, so every count your agent makes includes it twice.

Business keys are the fix, and they are harder than they look. At NY Next in New York last week, Keith Belanger, Snowflake Data Superhero, used a coffee shop to show why. One till system reuses its order numbers every day. Another runs a single counter forever. Both have an order number 1. In the first system the business key is order number plus date, in the second it is order number alone, and side by side they collide.

His advice on letting an agent pick the key was blunt:

"AI can help in determining the business key, but I would not just say, find me the business key, and then trust it."

The best way to find a business key, he said, is to ask people how they identify the thing. An agent can test whether a candidate key is unique across systems. A person decides what the key is, and the data model keeps that decision so every agent uses the same one.

The mummy: views on views, source unknown

v_sales_final reads from v_sales_final_v2, which reads from v_sales_clean, which reads from v_sales_tmp_jan. Ask where a revenue number comes from and the room goes quiet. An agent has it worse. It can read the SQL, but it can't tell which layer holds a business rule and which one was a workaround for a month-end close.

Lineage an agent can read solves this. In VaultSpeed, the enterprise context store holds your data models, sources, lineage and transformation logic in one graph, and any agent can query it over MCP. An agent asked where a value comes from gets the derivation path from the store instead of reverse engineering it from view definitions. Because the lineage comes from the same data model the code is generated from, nobody has to reconstruct it after the fact.

Check your own warehouse

Pick one question an agent will be asked next quarter, such as how many active customers you have, and trace it by hand. Note the load time of every table it touches, the owner of every column, the key that joins the systems, and every view between the source and the answer. Each gap you find is a monster your agent will meet first.

Want a second pair of eyes on your own warehouse? Our solution engineers will trace one of your questions with you, from the source to the answer, and show where the monsters sit.

Book a working session