# When the Data Is Bad and Nobody Wants to Hear It By [ByteByByte](https://bytebybyte.tech) ยท 2026-05-08 agentic-ai, ai-slop, data-quality, enterprise-ai, human-in-the-loop, ai-governance --- A colleague forwarded me an email this week, fresh out of a client meeting. I'll anonymize it but I want to keep the texture intact: > Ok this is going to be "fun." Just met with \[the lead\]. Their data is bad, but \[the executive\] doesn't care and doesn't really want to hear it. Just wants to ship. If you've worked in data and analytics for any length of time, you've read this email. You've probably written this email. The names change, the industry changes, the budget changes. The shape doesn't. What's new in 2026 is that the executive on the other side of the table isn't asking for a dashboard anymore. They're asking for an agent. The prerequisite the marketing leaves out ----------------------------------------- Open any vendor blog from the last six weeks and you'll see the same arc. ML was the first wave, GenAI was the second, agentic AI is the third, and this time the agents will _act_ on your data, not just talk about it. Microsoft published a piece in April about agents transforming renewable energy operations. Bidgely is repositioning the entire company around it. NextEra is using Google's agents in field ops. Tata Power signed Salesforce in March for an "integrated autonomous clean energy ecosystem." Analysts are pricing the market in the tens of billions by the mid-2030s. What the announcements skip is the prerequisite. Your data has to be good enough for an agent to act on without doing harm. In my experience, in most enterprises, it isn't. I've written before that if your data is flawed, AI will just help you make bad decisions more efficiently. Agents pour fuel on that fire. A bad dashboard tells one person something wrong, and that person at least gets to look at the number sideways and say "that doesn't sound right." An agent doesn't get that benefit of the doubt. It tells the next system, which tells the next system over MCP or A2A, which writes the memo, which becomes the slide. By the fourth hop you can't trace the original error because three different agents have already paraphrased it. This is part of the AI slop problem, and I'd argue it's the bigger risk most teams aren't pricing in. It isn't just a content problem. It's an operational one. What slop actually looks like inside a company ---------------------------------------------- When most people say "AI slop," they mean the flood of generic AI-written articles polluting Google. That's the consumer version: annoying, but mostly someone else's problem. The enterprise version is quieter and worse. The output reads well. It uses the right vocabulary, cites the right tables, sounds like a senior analyst wrote it. It comes with a confidence score because the platform vendor knew you'd want one. The next system downstream consumes it as fact, because that's what the integration spec says to do. By the time it lands in a board pre-read, the underlying error has been laundered through enough hops that it carries the authority of a board pre-read. Let me paint you a picture, the kind I'd wager most data teams will recognize. A model is using a table with a known data quality issue: a meaningful chunk of rows mis-assigned after a migration a couple years back. Everyone on the data team knows about it. There's a Slack thread, an open Jira ticket, a caveat that gets read aloud at every weekly review. The agent doesn't know any of that, because the agent doesn't read Slack threads from two years ago. It generates a recommendation with a confident-looking number attached. The recommendation goes into a deck. The deck heads toward a customer-facing roadmap. Whether someone catches it in QA depends on whether anyone happens to look sideways at the number. Now scale that to a utility making real-time grid decisions, an underwriter pricing risk, or a healthcare system triaging patients. The blast radius is not the same. Why agents make this worse, not better -------------------------------------- Most enterprise AI roadmaps I've seen this year layer four capabilities on top of each other: ML models that predict signals, GenAI that turns data into language, agents that take action, and agentic workflows that orchestrate the agents. These aren't competing approaches. They're layered, with each tier sitting on the one below it. That's the part the slide deck gets right. The part the slide deck doesn't make obvious is what happens to a use case as it climbs the stack. I've been working through a use-case maturity exercise recently and the pattern is consistent. The traditional ML version of a workflow has zero agents and a couple of human checkpoints. The first agentic version of the same workflow, once you add anomaly detection, critique loops, and case routing, has eight agents. The fully orchestrated version, the one with end-to-end autonomy and a governance layer, has fourteen or fifteen. Each of those agents is a junction. Each junction is a place where bad data or output can enter, get paraphrased into something that looks legitimate, and propagate. A confidence score gets averaged with another confidence score. A "the data quality is questionable here" caveat gets dropped because the next agent didn't have a field for it. By the time you reach the governance layer, you have an autonomous system making decisions on a foundation no single human has end-to-end visibility into. This is the thing nobody puts on the value-prop slide. Three responses I keep hearing ------------------------------ When you tell a client their data isn't ready for what they want to build, you get one of three responses. Roughly even split, in my experience. The first is denial. "Our data is fine, we did a big modernization in 2022." Said in the same breath as a complaint about how nobody trusts the numbers in the weekly business review. The second is "later." We'll fix it after the pilot ships. Later never arrives. The pilot becomes the production system, the production system becomes the thing nobody wants to touch because too much depends on it, and the bad data goes from being a known issue to being load-bearing. The third is the most 2026 version of the question: can the AI fix it? Honestly, mostly yes. A competent team with the right tooling can clean up data quality issues an order of magnitude faster than the same team in 2020. But the AI can't decide what counts as fixed without you telling it what good looks like, and that's the conversation the executive doesn't want to have. The work the AI accelerates is downstream of the work the executive is avoiding. What I've seen work ------------------- I don't have a clean framework for this. Three moves have shifted the conversation when I've tried them. **Make the bad data show up _in_ the agent's output, not under it.** The instinct is to clean the data before the agent sees it, or to filter the agent's responses to hide the ugly parts. Wrong instinct. Better to have the agent surface its own ground: "Recommending X based on Y; note that Y has a known issue affecting ~4% of rows from this source." The exec who wants to ship will still ship. The exec who's about to commit $50M will pause. Both are acceptable. What isn't acceptable is shipping _and_ committing the $50M because the warning got buried in an appendix. You must have clear traceability for the end-to-end process that resulted in the output. **Architect skepticism in.** The most interesting pattern i've seen in implementation planning and architecture reviews is the critic agent: an agent whose only job is to verify another agent's grounding and flag gaps. Pair it with a refinement agent, plus human-in-the-loop checkpoints on anything below a confidence threshold, and you get a workflow that catches its own slop before it propagates. Sequential pattern, parallel pattern, review-and-critique, human-in-the-loop. These aren't just architecture diagrams. They're the difference between an agent that fails loudly and an agent that fails quietly. The catch: a critic agent is only as good as its grounding. If your data foundation is bad, the critic doesn't know what "correct" looks like either. The architectural fix loops back to the same prerequisite. **Pick one foundation problem and fix it in public.** Not a two-year program. The most-used table, the most painful field, fixed while everyone watches. Visible wins build the political capital you need for the unsexy work behind them. SAP sent an email this week with the subject line _"Most companies are on their second attempt at a real data foundation."_ Frankly, they're underselling it. Most clients I see are on their third or fourth. The teams that break the cycle do it by stopping the all-or-nothing reflex. Bottom Line ----------- I'm working on a few agentic AI projects right now and I'm bullish on what this technology is going to unlock. The trap I see teams falling into is thinking the choice is binary: wait for a perfect data foundation that never arrives, or ship the agent on shaky ground and hope the bad data doesn't bite. The third path, and the one I'd actually recommend, is to start the work. Your data does not need to be perfect to move forward. But two things have to be in place from day one. First, visibility into what's questionable. Every output an agent produces should surface what data it's grounded in, what's known to be flawed about that data, and what the confidence level actually is. Bad data isn't the problem on its own. Bad data hidden inside confident output is. Second, a human in the loop on anything an agent does. Not just the high-stakes calls. Everything. The cost of that review goes down as trust builds, but it can't start at zero. This is both an org problem and a technical problem, and the answer needs both halves. The org has to be willing to surface what's broken. The technical build has to make the broken parts visible by default. Either one without the other and you're shipping slop with a confidence interval on top. P.S Happy mothers day to all moms out there this weekend ![](https://storage.googleapis.com/papyrus_images/4d70b3824b8fdcfb25d4b057961595113bc810eb9592914265c204c9ff3aff2d.jpg) --- *Originally published on [ByteByByte](https://bytebybyte.tech/when-the-data-is-bad)*