# Stop tuning your models and fix your data > Source: > Published: 2026-09-17 09:00:00+00:00 Walk into any boardroom or technology conference today, and the conversation is entirely consumed by the [promise of agentic AI](https://www.infoworld.com/article/3611465/how-ai-agents-will-transform-the-future-of-work.html). We are told that autonomous AI agents will soon handle our corporate analytics, democratizing data so that anyone, from an intern to the CEO, can type a natural-language question into Slack and get an instant, data-backed answer. Sounds great, right? Not so fast. If you simply drop a cutting-edge [large language model](https://www.infoworld.com/article/2335213/large-language-models-the-foundations-of-generative-ai.html) (LLM) into the average corporate data warehouse, it doesn’t become a brilliant data analyst. It becomes a confident idiot. The reality is that an AI agent cannot fix bad data, missing joins, or undocumented columns. So if your underlying data infrastructure is a chaotic web of isolated silos and ambiguous schemas, your agent will simply deliver wrong answers faster to everyone in your organization, and probably way too confidently (which is by design). When we built a conversational data agent at Runpod to let our teams query infrastructure metrics directly in Slack, our biggest takeaway wasn’t about the model. It was about the architecture underneath it. Improving the model produced small, incremental gains. Improving the data foundation fundamentally changed the quality and usefulness of the agent’s responses. If we wanted anyone at the company to be able to ask questions like “How many GPUs were run through maintenance today?” or even “How many GPUs were taken offline in the last hour?” and get an accurate, actionable answer, the lesson was clear: Our data foundation is our AI strategy. Many enterprise leaders are blowing massive budgets trying to fine-tune better models or build complex custom prompting layers. But they’re solving the wrong problem. Just like building a house, building an AI agent requires a solid foundation. To make an agent reliable, you must start with the data foundation. To safely move from experimental AI to reliable enterprise execution, technology leaders must focus on three key pillars of the data foundation: security, quality, and observability. Here I offer three recommendations. Many teams try to protect their data systems by giving the AI agent strict prompting instructions, such as “Do not delete tables, and do not look at employee PII.” This is a massive security risk. Inevitably, a clever user will craft a malicious prompt injection that bypasses those instructions. The actionable fix is simple. Stop relying on prompt engineering for security. Treat your AI agent exactly like a human junior analyst. Grant it read-only database credentials and strictly scope its role-based access to your “gold layer” — the curated, fully tested tables meant for business consumption. If the database role itself is structurally incapable of running a `DELETE` or `DROP` command, the agent’s blast radius shrinks to near zero, no matter what an adversarial user tells it to do. To a human analyst, an ambiguous column named “latency” or “revenue” can be deciphered with a bit of institutional context. But to an AI agent, it’s a hallucination trap. Without rigid guardrails, the agent is forced to guess. Sometimes it gets it right; sometimes it mistakes milliseconds for seconds, or gross revenue for net revenue. To solve this, enforce strict, self-describing naming conventions across your entire schema. Use standardized prefixes (i`d_` for joins, `is_` for booleans, `amt_` for currency) and explicit unit suffixes (`_ms`, `_usd`, `_gb`). When a vague column is transformed into `dur_latency_ms` or `amt_gross_revenue_usd`, the data becomes entirely self-documenting. The agent reads the name, instantly knows the data type and unit, and no longer has to guess. Data pipelines fail quietly. If an ingestion job silently stalls, a database table might look completely normal but contain data that is six hours out of date. While a human might catch the discrepancy, an AI agent will blindly query the stale table and confidently deliver an outdated number to an executive making a real-time decision. You must build automated observability monitors that act as an agentic safety switch. Set up automated checks for anomalies, missing data, and volume shifts. Furthermore, ensure your pipelines expose data freshness metadata directly to the database. This allows the agent to read exactly when the table was last refreshed and surface that timestamp to the user, or withhold the answer entirely if a pipeline error is detected. For the past several years, a collective anxiety has rippled through the data engineering community that AI would make data modeling, schemas, and analytics engineering obsolete. The truth is the exact opposite. AI agents make meticulous data modeling, [dbt](https://github.com/dbt-labs/dbt) tests, and pipeline governance more vital than they have ever been before. Humans can navigate a messy data warehouse. Software cannot. The bottleneck to widespread AI adoption at the enterprise level isn’t compute power, and it isn’t model capability. It’s the state of our data. If you want to unlock the true competitive advantage of agentic AI, stop searching for the next breakthrough model. Go fix your data tables. *—* *New Tech Forum* **provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all** **inquiries to** *doug_dineley@foundryco.com***.**