This continues a thread from The Human Premium—on what happens when AI amplifies capability versus dependency.

Consider what can happen when an enterprise deploys an agentic sales assistant that does exactly what it's designed to do. The agent connects to the CRM, pulls the account history and contact records, retrieves competitive intelligence from the knowledge base, cross-references recent support tickets for sentiment signals, and generates a polished briefing document for the rep to review before her 2pm call. The orchestration is elegant. The retrieval is fast. The output looks like something a junior analyst would have spent half a day producing.

And yet that briefing might be grounded in CRM data that hasn't been touched since the last quarterly business review six months ago—opportunity stages frozen in time, contact roles that no longer reflect who actually makes decisions, notes from a sales engineer who left the company in March. The competitive intelligence might describe a positioning the competitor abandoned after their Series D pivot. The sentiment analysis might be anchored to a billing dispute that was resolved in January but never marked closed in the ticketing system. The agent did its job perfectly. The information it was working with didn't reflect what's actually happening with the customer.

This is the failure mode that's starting to show up as companies move from pilot deployments to production scale. The technology works. The information doesn't.

The Grounding Problem

A recent Contentstack survey of enterprise leaders surfaced a number that's been sitting with me: 88% said they wish they had invested more in their data and content foundations before deploying AI agents. Not during the rollout, not after the first incidents, but before any of it started. That's a remarkably specific regret—the kind you only express when you've lived through the consequences of getting it wrong.

What those leaders are describing is something we might call the grounding problem, though the term risks sounding more technical than the reality it describes. Agents are being deployed into information environments that can't support them—not because the models aren't capable or the orchestration isn't sophisticated, but because the data those agents retrieve and synthesize doesn't reflect what's actually true about customers, products, competitors, or the market. The agents aren't hallucinating in the usual sense of fabricating information from nothing. They're faithfully retrieving and synthesizing what's in the systems they're connected to. It's just that what's in those systems is stale, incomplete, or wrong.

The distinction matters. When we talk about LLMs hallucinating, we typically mean the model generating plausible-sounding content that isn't grounded in any source—making things up out of statistical pattern-matching. The grounding problem is different. The agent is retrieving real data from real systems, following real retrieval pipelines, producing outputs that are internally consistent and well-sourced. The problem is upstream: the sources themselves don't reflect reality. The agent isn't hallucinating. It's working with organizational fiction and presenting it as fact.

"The agent isn't hallucinating. It's working with organizational fiction and presenting it as fact."

Three Layers, One Missing

It helps to think about agentic deployments in terms of three distinct layers, each with its own technical challenges and organizational ownership.

The first is orchestration—the coordination layer that determines how agents hand off tasks, manage multi-step workflows, maintain state across interactions, and integrate with enterprise systems. This is where most of the vendor energy goes, and for good reason: orchestration is genuinely hard engineering, it's where product differentiation happens, and it's highly visible in demos and proofs of concept. When executives evaluate agentic platforms, orchestration is what they see.

The second is grounding—what agents actually know and how they access it. This is the retrieval layer: RAG architectures, vector databases, knowledge graphs, the technical infrastructure that connects language models to enterprise information. The grounding layer has finally started getting serious investment now that the limitations of pure prompt engineering have become obvious. Companies understand, at least in principle, that agents need to be connected to real data to be useful.

The third layer is strategic oversight—the ongoing function of ensuring that what agents know actually reflects what's true. Not as a one-time data quality initiative or a quarterly cleanup project, but as a continuous responsibility that someone owns. This is the layer almost nobody has built, and it's the one that determines whether the other two actually work.

We have sophisticated orchestration. We have increasingly capable grounding infrastructure. What we don't have is anyone accountable for the quality of the information flowing through that infrastructure—anyone whose job it is to ensure that agents are grounded in customer truth rather than organizational inertia.

The Ownership Gap

The reason this function doesn't exist in most organizations is that it falls awkwardly between existing roles, and no one has a clear mandate to pick it up.

The data organization owns infrastructure—pipelines, governance frameworks, data catalogs, the technical plumbing that moves information between systems. But their focus is typically inward: compliance, lineage, access controls, schema management. They're not usually embedded with customers or customer-facing teams, and they're not positioned to validate whether what's in the CRM reflects the actual state of an account relationship. That's not their expertise, and it's not where they spend their time.

Sales owns the customer relationship, but salespeople are optimizing for quota attainment and pipeline velocity—as they should be. They update the CRM to the extent required to move opportunities through stages, capture enough context for handoffs, and satisfy their manager's reporting requirements. The idea that their CRM entries might be synthesized by an agent six months later and presented to another rep as authoritative context isn't on their radar. It's too many steps removed from what they're measured on.

Marketing owns messaging, positioning, competitive narratives—the official story of who the company is and what it does. But marketing thinks in terms of campaigns, content calendars, and brand consistency. The question of how their positioning documents get consumed by AI systems that will synthesize them, combine them with other data sources, and present them to customers in contexts marketing never anticipated—that's not something most marketing organizations are structured to consider.

Product owns the roadmap, the documentation, the technical truth of what the product actually does. But product teams think in terms of features, releases, and user workflows—not about how product information propagates through agent architectures and ends up being presented to customers by systems that might not understand the nuances, the caveats, the "yes, but only if you configure it this way" qualifications that product managers know instinctively but rarely document.

The pattern is consistent across functions. Everyone owns a piece of the information that agents depend on. Nobody owns the question of whether it's true, whether it's current, or whether it accurately represents what's actually happening with customers. The function falls between chairs, and what falls between chairs doesn't get done.

What the Work Looks Like

If this function existed—and there's reason to think it will have to exist eventually—what would the person doing it actually spend their time on?

Part of it would be translation work: spending time with customers and with the people who serve them, building a real understanding of what's actually happening in those relationships, and then encoding that understanding in ways that AI systems can use. Every organization has an enormous reservoir of tacit knowledge—what the senior account exec knows about a client's internal politics, what the support engineer knows about the workarounds customers actually use, what the solutions architect knows about how the product behaves in edge cases nobody documented. Most of this knowledge never makes it into systems. It lives in people's heads, gets shared in hallway conversations and Slack threads, and evaporates when people change roles or leave the company. Someone has to be the bridge, translating human understanding into structured information that agents can retrieve and synthesize correctly.

Part of it would be auditing: systematically comparing what agents produce to what's actually true, and when there's a gap—which there always is—tracing that gap back to its source. When an agent gives a rep a misleading briefing, the problem is almost never the model. It's upstream somewhere: a field that wasn't updated, a document that should have been retired, a competitive assessment that aged past its usefulness without anyone noticing. The work is diagnostic—figuring out not just that something went wrong, but why, and fixing the root cause rather than just correcting the individual output.

Part of it would be ongoing architecture maintenance. As the business evolves—new products launch, customer segments shift, competitors pivot, the market conversation changes—the information structures that ground agents have to evolve alongside. This isn't something you can configure once and hand off to IT. The gap between what agents know and what's true will widen continuously, silently, unless someone is actively managing it.

And part of it would be boundary-setting: deciding where agents should operate autonomously and where they need human oversight, which questions they should answer directly and which they should escalate, how much confidence is enough to act and how much uncertainty should trigger a handoff. These are design decisions that require someone who understands both the customer relationship and the agent capabilities deeply enough to draw reasonable lines—and who can revisit those decisions as both the technology and the context evolve.

The CDP Parallel

When Martin Kihn and I wrote about customer data platforms several years ago, the core argument was that enterprises needed a unified view of customer data to deliver coherent experiences across channels. The problem wasn't that companies lacked data—if anything, they had too much—but that it was fragmented across systems that couldn't talk to each other. Sales had one version of the customer, marketing had another, support had a third, and none of them matched. The promise of the CDP was to create a single source of truth, a golden record that everyone could work from.

That argument hasn't gone away, but the stakes have changed. In the CDP era, fragmented data meant inconsistent customer experiences—the left hand not knowing what the right hand was doing, offers that didn't match context, personalization that felt random. Frustrating, but recoverable. In the agentic era, the same fragmentation means something different: AI systems that confidently synthesize conflicting information, present outdated facts as current truth, and make recommendations based on organizational assumptions that no one has validated in years. The failure mode isn't just inconsistency. It's confident wrongness at scale.

Unifying the data was the challenge of the CDP era. Ensuring the data is actually true—that it reflects what's really happening with customers, not just what made it into systems of record—is the challenge of the agentic era. And it requires a different kind of function than anything most organizations have built.

In The Human Premium, I argued that AI amplifies whatever capability you bring to it: strong foundations become stronger, weak foundations get exposed. The same logic applies at the organizational level. Agents will faithfully retrieve, synthesize, and act on whatever information you give them access to. If that information reflects customer reality, you get agents that genuinely understand your customers and can serve them well. If it reflects organizational inertia—the accumulated sediment of CRM fields nobody updates, documents nobody retires, assumptions nobody questions—you get agents that produce plausible outputs with no particular connection to truth. The difference isn't in the sophistication of your orchestration or the quality of your embeddings. It's in whether anyone owns the information layer.

Where This Points

I don't know yet what this function will be called when companies start creating it. It sits at the intersection of data architecture, customer strategy, AI governance, and organizational design—and it requires someone who can move fluidly between technical systems and customer relationships, who understands both what the data says and what's actually happening, and who can tell the difference. That's an unusual combination of skills. Most people are strong on one side or the other: the infrastructure side or the customer side, the technical plumbing or the relationship intuition. Finding people who can operate credibly in both worlds will be the challenge.

What I do know is that the 88% regret number points toward something real that companies are feeling but haven't quite named yet. The deployment curve for agentic AI is steep—orchestration platforms are maturing rapidly, grounding infrastructure is becoming commoditized, and the pressure to ship agents is intense. But the information foundations those agents depend on aren't improving at the same rate. The gap is widening. And the companies that recognize this early, that invest in the human layer their agentic architecture actually requires, will build an advantage that compounds over time. Their agents will know their customers. Everyone else's will just think they do.