S
Sunilkumar Reddy Eraganeni
Guest
A support agent once told a customer that their refund had been processed. It hadn't. The model was fine, the prompt was fine, and the tone was lovely. The problem was that the refunds table synced nightly, a batch job had failed the evening before, and the customer happened to ask at 2pm the next day. The agent reasoned beautifully over a world that no longer existed.
That story is a bit embarrassing to tell, mostly because it is so ordinary. Teams spend weeks comparing models and tweaking prompts, then wire everything to data that was never designed to be read by something that acts on it. Here is my argument, stated plainly: an agent's ceiling is set by its data pipeline, and the model mostly decides how close you get to that ceiling.
Think of an iceberg, though I'll admit the metaphor is overworked. The model and the chat window sit above the waterline. Below it sit ingestion jobs, schemas, permissions, chunking rules, caches and a few spreadsheets that someone in finance emails around on Fridays. When the agent fails, people stare at the tip because that is what they can see.
Dashboards are forgiving in a way agents are not. A human analyst looking at a revenue chart will squint at a weird spike and ask a colleague. An agent just uses the number. It also tends to sound confident while doing it, which is what makes bad data so costly here. The error doesn't look like an error. It looks like an answer.
Stale data. Freshness is the obvious one. If your inventory syncs hourly and your agent promises same-day delivery, you have a policy decision hiding inside a cron schedule.
Inconsistent definitions. Marketing counts an "active user" as someone who logged in this month. Product counts a user who completed an action. Ask an agent how many active users you have and it will cheerfully pick one, or, worse, blend them. Nobody lied. The definitions just never met.
Unstructured mess. PDFs with tables that extract as soup, wiki pages with three contradictory versions of the same process, Slack threads where the real answer is the fourth reply. Retrieval can surface these, but surfacing is not understanding.
No lineage. When the agent says something wrong, can you trace which source, which version and which transformation produced it? If the answer is no, you will end up debugging by vibes, and that scales badly.
None of this is exotic. It's mostly data engineering applied with an agent as the consumer. Figure 1 shows the flow I'd start from, and I'd stress "start from" because every organization will bend it.
Let me walk through the parts that people tend to skip.
Ingestion deserves a real decision about change data capture versus batch. Batch is simpler and cheaper, and for HR policies that change twice a year it is perfectly fine. For order status or account balances, I'd lean toward streaming changes. I don't think there's a universal answer, only a question worth asking per source: what is the cost of this being six hours old?
Validation is the highlighted box for a reason. Data contracts, meaning explicit agreements about fields, types, ranges and ownership, catch problems before the agent can repeat them. A null customer ID is annoying in a report. In an agent that can issue refunds, it's a liability.
Transformation and enrichment is where you attach the context a human would carry in their head. Which system is authoritative? Who is allowed to see this? When was it last verified? Metadata like that feels tedious until the day it saves you from an agent quoting a draft policy as if it were law.
The serving layer usually needs more than a vector database. Embeddings are great for fuzzy questions like "how do we handle chargebacks for subscriptions?" They're poor at exact ones like "what is order 88213's status?", which want plain SQL or an API call. Most good agent stacks I've seen combine both, and let the agent choose the tool.
It's tempting to treat retrieval as a model-side concern, something you fix with a better embedding or a cleverer reranker. Those help. Still, I've watched teams gain more from fixing chunk boundaries than from swapping models. A policy split mid-sentence across two chunks will confuse any reader, human or otherwise.
Two small habits help a lot. First, store a timestamp and a source on every chunk, then let the agent refuse to answer from anything older than a threshold you set per topic. Second, filter by permission before retrieval, not after generation. If a document shouldn't be seen, it shouldn't reach the prompt. Redacting afterwards is a bit like locking the door once the guest is already inside.
Most failure analysis I see ends at "the model hallucinated." Sometimes that's true. More often, when you read the full trace, the agent was given conflicting or missing context and did its best. Without traces you can't tell the difference.
A habit I'd recommend is tagging each failure in that diagnose step. After a month, the tally is revealing. In the teams I've talked with, the data-side bucket tends to be embarrassingly large, though I'd treat that as anecdote rather than a measured result, since my sample is small and self-selected.
I should be fair to the other side. Stronger models really do tolerate messier inputs. Long context windows let you dump more material in and hope. And a small team with one internal chatbot probably shouldn't build contracts, streaming and an eval harness before shipping anything. That would be its own kind of mistake.
However, tolerance is not the same as correctness. A model that gracefully shrugs off a typo will not know that your pricing table was updated yesterday. Better models raise the floor, but they can't invent facts your pipeline never delivered.
First, list the three sources your agent relies on most and write down how stale each can safely be. Second, add timestamps and source IDs to everything you index. Third, pick one metric definition that keeps getting argued about and settle it in one place. Fourth, log full traces from day one. Fifth, review twenty failures by hand and sort them into data or model. You'll learn more from that afternoon than from another round of prompt tweaking.
None of this is glamorous. Pipelines rarely get conference talks. But the next time your agent says something confidently wrong, I'd suggest looking one layer down before you blame the model. There's a decent chance the model did exactly what it was asked, with exactly what it was given.
That story is a bit embarrassing to tell, mostly because it is so ordinary. Teams spend weeks comparing models and tweaking prompts, then wire everything to data that was never designed to be read by something that acts on it. Here is my argument, stated plainly: an agent's ceiling is set by its data pipeline, and the model mostly decides how close you get to that ceiling.
The model is the visible tip
Think of an iceberg, though I'll admit the metaphor is overworked. The model and the chat window sit above the waterline. Below it sit ingestion jobs, schemas, permissions, chunking rules, caches and a few spreadsheets that someone in finance emails around on Fridays. When the agent fails, people stare at the tip because that is what they can see.
Dashboards are forgiving in a way agents are not. A human analyst looking at a revenue chart will squint at a weird spike and ask a colleague. An agent just uses the number. It also tends to sound confident while doing it, which is what makes bad data so costly here. The error doesn't look like an error. It looks like an answer.
Four ways pipelines quietly make agents look dumb
Stale data. Freshness is the obvious one. If your inventory syncs hourly and your agent promises same-day delivery, you have a policy decision hiding inside a cron schedule.
Inconsistent definitions. Marketing counts an "active user" as someone who logged in this month. Product counts a user who completed an action. Ask an agent how many active users you have and it will cheerfully pick one, or, worse, blend them. Nobody lied. The definitions just never met.
Unstructured mess. PDFs with tables that extract as soup, wiki pages with three contradictory versions of the same process, Slack threads where the real answer is the fourth reply. Retrieval can surface these, but surfacing is not understanding.
No lineage. When the agent says something wrong, can you trace which source, which version and which transformation produced it? If the answer is no, you will end up debugging by vibes, and that scales badly.
A reference architecture
None of this is exotic. It's mostly data engineering applied with an agent as the consumer. Figure 1 shows the flow I'd start from, and I'd stress "start from" because every organization will bend it.
Let me walk through the parts that people tend to skip.
Ingestion deserves a real decision about change data capture versus batch. Batch is simpler and cheaper, and for HR policies that change twice a year it is perfectly fine. For order status or account balances, I'd lean toward streaming changes. I don't think there's a universal answer, only a question worth asking per source: what is the cost of this being six hours old?
Validation is the highlighted box for a reason. Data contracts, meaning explicit agreements about fields, types, ranges and ownership, catch problems before the agent can repeat them. A null customer ID is annoying in a report. In an agent that can issue refunds, it's a liability.
Transformation and enrichment is where you attach the context a human would carry in their head. Which system is authoritative? Who is allowed to see this? When was it last verified? Metadata like that feels tedious until the day it saves you from an agent quoting a draft policy as if it were law.
The serving layer usually needs more than a vector database. Embeddings are great for fuzzy questions like "how do we handle chargebacks for subscriptions?" They're poor at exact ones like "what is order 88213's status?", which want plain SQL or an API call. Most good agent stacks I've seen combine both, and let the agent choose the tool.
Retrieval is a data problem wearing an AI costume
It's tempting to treat retrieval as a model-side concern, something you fix with a better embedding or a cleverer reranker. Those help. Still, I've watched teams gain more from fixing chunk boundaries than from swapping models. A policy split mid-sentence across two chunks will confuse any reader, human or otherwise.
Two small habits help a lot. First, store a timestamp and a source on every chunk, then let the agent refuse to answer from anything older than a threshold you set per topic. Second, filter by permission before retrieval, not after generation. If a document shouldn't be seen, it shouldn't reach the prompt. Redacting afterwards is a bit like locking the door once the guest is already inside.
Close the loop, or you're flying blind
Most failure analysis I see ends at "the model hallucinated." Sometimes that's true. More often, when you read the full trace, the agent was given conflicting or missing context and did its best. Without traces you can't tell the difference.
A habit I'd recommend is tagging each failure in that diagnose step. After a month, the tally is revealing. In the teams I've talked with, the data-side bucket tends to be embarrassingly large, though I'd treat that as anecdote rather than a measured result, since my sample is small and self-selected.
Where this argument runs out
I should be fair to the other side. Stronger models really do tolerate messier inputs. Long context windows let you dump more material in and hope. And a small team with one internal chatbot probably shouldn't build contracts, streaming and an eval harness before shipping anything. That would be its own kind of mistake.
However, tolerance is not the same as correctness. A model that gracefully shrugs off a typo will not know that your pricing table was updated yesterday. Better models raise the floor, but they can't invent facts your pipeline never delivered.
If you only do five things
First, list the three sources your agent relies on most and write down how stale each can safely be. Second, add timestamps and source IDs to everything you index. Third, pick one metric definition that keeps getting argued about and settle it in one place. Fourth, log full traces from day one. Fifth, review twenty failures by hand and sort them into data or model. You'll learn more from that afternoon than from another round of prompt tweaking.
None of this is glamorous. Pipelines rarely get conference talks. But the next time your agent says something confidently wrong, I'd suggest looking one layer down before you blame the model. There's a decent chance the model did exactly what it was asked, with exactly what it was given.