Stop Tuning Your Models and Fix Your Data

Walk into any boardroom today, and the conversation is consumed by agentic AI. The promise: autonomous agents that let anyone—from an intern to the CEO—type a natural-language question into Slack and get an instant, data-backed answer. But according to a recent InfoWorld article, dropping a cutting-edge large language model into the average corporate data warehouse doesn’t create a brilliant data analyst. It creates a confident idiot.

The article, written by an engineer who built a conversational data agent at Runpod, makes a blunt case: an AI agent cannot fix bad data, missing joins, or undocumented columns. 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.

Refer & earn: 30% of a client’s first month, then 10% of every month after that, for up to 24 months per client. See the partner programme →

What changed: From model tuning to data foundations

For years, the dominant enterprise AI strategy has been to fine-tune better models or build complex custom prompting layers. The article argues this is solving the wrong problem. When the author’s team built their conversational agent, the biggest takeaway wasn’t about the model. Improving the model produced small, incremental gains. Improving the data foundation fundamentally changed the quality and usefulness of the agent’s responses.

The lesson: your data foundation is your AI strategy. Many enterprise leaders are blowing massive budgets on model improvements while neglecting the architecture underneath. Just like building a house, building an AI agent requires a solid foundation.

Three pillars of a reliable data foundation

The article outlines three key pillars: security, quality, and observability. Each comes with a concrete recommendation that business leaders can act on.

1. Security: Stop relying on prompt engineering

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.” The article calls this a massive security risk. Inevitably, a clever user will craft a malicious prompt injection that bypasses those instructions.

The actionable fix is simple: 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.

For a business reader, this means checking whether your AI agent has write access to production data. If it does, that’s a risk you can eliminate today by changing database permissions, not by writing better prompts.

2. Quality: Make your data self-describing

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.

The article recommends enforcing strict, self-describing naming conventions across your entire schema. Use standardized prefixes (id_ 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.

Before acting, ask: how many of your critical data columns have ambiguous names? If your team can’t tell from the column name alone what unit or meaning is intended, your AI agent can’t either.

3. Observability: Build automated safety switches

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.

The article recommends building 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 a business leader, this means asking: does your AI agent know how fresh its data is? If not, it could be making decisions on stale information without warning.

What this means for your AI strategy

The article’s central claim is that 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.

This has a counterintuitive implication: AI agents make meticulous data modeling, dbt tests, and pipeline governance more vital than they have ever been before. Humans can navigate a messy data warehouse. Software cannot.

For years, a collective anxiety has rippled through the data engineering community that AI would make data modeling, schemas, and analytics engineering obsolete. The article argues the opposite. The skills that were supposedly at risk are now the foundation for making AI reliable.

What to check before you act

If you’re considering deploying an AI agent for analytics or operations, the article suggests starting with a data audit rather than a model evaluation. Here are practical questions to bring to your team:

• Access: Does the agent have read-only credentials, or can it write, delete, or drop? Is its access scoped to curated, tested tables?
• Naming: Are your column names self-describing? Do they include units and prefixes that make meaning unambiguous?
• Freshness: Do your pipelines expose metadata about when data was last refreshed? Can the agent read and surface that timestamp?
• Monitoring: Do you have automated checks for anomalies, missing data, and volume shifts that can act as a safety switch?

These are not model problems. They are data infrastructure problems. And unlike model tuning, they are within the control of your existing data engineering team.

The bottom line

The article’s message is clear: 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. The fix isn’t a better model. It’s a better data foundation.

For business leaders, this reframes the AI investment decision. Before allocating budget to fine-tuning or custom prompting, consider whether your data foundation is ready. The article suggests that improving the data foundation fundamentally changes the quality and usefulness of the agent’s responses, while improving the model produces only small, incremental gains.

That’s a testable proposition. Start with a small pilot: pick one high-value question your team wants to ask, like how many GPUs were run through maintenance today, and see if your current data foundation can answer it reliably. If it can’t, you’ve found your real bottleneck.

Disclosure: Faida Workforce provides consulting services related to AI and data strategy. This article is intended for informational purposes and does not constitute a sales pitch. We have no results to promise—only a framework to consider.

Sources

• Stop tuning your models and fix your data — InfoWorld

This article was produced with the assistance of AI tools. A human editor is accountable for its content. Byline: Faida Workforce Editorial.