Every team I talk to that's building agentic AI starts with the same assumption: We have the data. We're ready.
They point to their data lake. Their warehouse. Their BI dashboards. Their indexed document repositories. For traditional reporting and analytics, that's enough. But the moment an agent touches that data, something breaks. The agent reads the numbers, then makes a decision that's subtly—or catastrophically—wrong.
Not because the model is bad. Because the data wasn't packaged in a way the agent could safely understand.
I've seen this pattern repeat across industries. A finance team wants an agent to help with month-end close, but the trial balance mixes preliminary and final figures. A procurement team wants an agent to process purchase requests, but "approved vendor" means different things in their sourcing system versus their ERP. A customer operations team wants an agent to handle complaints, but "active customer" has no consistent definition across departments.
The data is available. The agent can't use it correctly.
This is the gap that most organizations overlook. And it's the difference between an impressive demo and a production system you can trust.
What Agents Actually Need (Hint: Not Raw Data)
The shift from data availability to agent usability is the single most important architectural decision you'll make.
Human analysts can tolerate ambiguity. They can open three dashboards, cross-reference definitions, and use institutional knowledge to fill in the gaps. Agents cannot. They need explicit input: what does this field represent? How fresh is it? When is it safe to use? For what purpose? Who is responsible if the definition changes?
This is where the concept of an agent-ready data product becomes essential. A dataset becomes a data product when it carries more than just data—it carries an operational contract. For agents, that contract needs to be especially tight.
At minimum, an agent-ready data product needs:
- A clear, stable schema
- Documented semantics (what each field means in business terms)
- A business owner and a technical owner
- Freshness expectations and quality thresholds
- Basic lineage
- Access policies that can be evaluated at runtime
- Allowed actions or usage rules
Without these elements, an agent isn't looking at data. It's looking at a pile of fields with no context.
The shift from raw data to agent-ready products requires a control gate, semantic contracts, and permission-aware retrieval—not just better indexing.
The Semantic Contract: Meaning, Not Just Format
Many organizations already have schema registries or API documentation. That's important, but it's not enough.
An agent doesn't just need to know there's a field called revenue. It needs to know whether that means booked revenue, billed revenue, recognized revenue, or net revenue. It needs to know that margin might mean gross margin, contribution margin, or margin after specific allocations. It needs to know that active customer could mean "transacted in the last 90 days," "has an active contract," or "hasn't formally churned."
This is the semantic contract—a layer that explains the business meaning behind every field, the rules that govern it, when it should and shouldn't be used, and what assumptions are baked in.
Without this contract, agents fill the gaps with inference. And their inferences often look reasonable but are operationally wrong.
In an enterprise, the semantic contract should be part of a broader semantic layer that unifies language across BI, operational applications, AI agents, and business users. Because many data conflicts aren't technical quality problems—they're definition problems. Your controllership team, FP&A team, and close assistant agent could all use "material variance" to mean different things if the semantic layer isn't standardized.
The semantic contract needs to be strictest for data products that cross functions, touch transactions or approvals, execute actions, or live in regulated domains like HR, finance, legal, and customer data.
Permission-Aware Retrieval: Access Must Follow Context
An agent should never retrieve data just because it exists in the index, lake, or vector store. Access must follow who the user is, their role, the workflow in progress, the purpose of use, and the sensitivity of the data.
This is the core of permission-aware retrieval.
Many RAG implementations start with a simple pattern: index everything, retrieve what's semantically most relevant. In an enterprise, this is dangerous. The most relevant document isn't always the most permissible one. An HR onboarding agent might find a compensation document that's relevant to "benefits" but shouldn't be visible. A legal contract assistant might find a contract that's relevant in content but belongs to a different jurisdiction or business unit.
A common mistake is applying access controls only at indexing time. But permissions change based on who's calling the agent, what channel they're using, what stage of the workflow they're in, and what they're trying to accomplish. Permission-aware retrieval must be evaluated at runtime.
For agentic systems, role-based access alone is often too coarse. Two people with the same role shouldn't necessarily use the same data for different purposes. A manager can see team data for performance review but not for compensation investigation. A finance agent can read invoice details for exception handling but not compile cross-entity vendor summaries without proper mandate.
This adds complexity. Metadata needs to be richer. IAM and policy engine integration needs to be tighter. Latency may increase. Index design becomes more complicated. But for HR, finance, legal, customer data, and regulated operations, this isn't optional. It's the minimum requirement to prevent your agent from becoming a new data leak path.
Quality and Freshness: The Agent Must Know When to Stop
One of the most practical risks in agentic AI isn't hallucination. It's an agent confidently acting on stale, incomplete, or transitional data.
I've seen procurement agents recommend vendors based on approval status that hadn't synced from due diligence. Finance close agents draft commentary from preliminary numbers when final figures had already changed. Customer service agents promise refunds based on order status that hadn't updated. IT incident agents route remediation to the wrong system because the CMDB was outdated.
In every case, the problem wasn't the model. It was that the data product didn't carry sufficient quality and freshness signals.
An agent-ready data product needs at least four mechanisms:
- Quality checks—basic validation that fields are populated, schemas match, referential integrity holds
- Freshness indicators—when was the data last updated, what's the expected refresh cycle, is it still within the usable window
- Anomaly detection—if there's a spike or unusual pattern, the agent shouldn't assume the data is valid
- Fallback behavior—if quality or freshness doesn't meet thresholds, the agent needs to know what to do: stop, ask for more data, use an alternative source, or escalate to a human
The most overlooked capability is the agent's ability to say "I don't have enough data." Many teams are too focused on making the agent always answer. But in an enterprise, the correct behavior is often to stop. An AP exception agent shouldn't classify a mismatch if goods receipt hasn't been entered. An HR agent shouldn't answer benefit questions if eligibility data isn't final. A supply chain agent shouldn't recommend rerouting if shipment feeds haven't updated.
Governance-wise, an agent that knows when to stop is more valuable than an agent that always sounds confident.
The Architecture Implication
Treating data and knowledge as products for agents changes how you build.
First, ownership must be explicit. Every data product needs a business owner for definition and allowed usage, a technical owner for delivery and quality, and potentially a risk or compliance owner for sensitive domains. Without owners, agents will use whatever data is available, but no one is responsible when definitions change or quality drops.
Second, the catalog becomes a control plane. You need a catalog that tracks not just where data products exist, but their semantic contracts, freshness expectations, quality status, access policies, and risk tiers. This lets the agent platform treat data products as governable dependencies, not ad-hoc connections.
Third, agent evaluation must test the data product too. When an agent fails, don't always blame the model. Often the root cause is semantic ambiguity, missing metadata, poor freshness, or permissions that didn't follow at runtime. Your evaluation should ask: was the data product appropriate? Was the semantic contract clear enough? Did the fallback work when quality dropped? Did retrieval respect policy?
What This Means in Practice
Start small. Pick one domain—finance close, customer support, or procurement—and audit your existing data products against the three requirements: semantic contract, permission-aware retrieval, and quality/freshness signals.
You'll likely find gaps. That's fine. The goal is to make one data product agent-ready, test it with a real agent workflow, and then expand. The pattern scales better than trying to retrofit your entire data lake at once.
Also, invest in your metadata layer. A catalog that tracks semantics, freshness, ownership, and access policies isn't a nice-to-have—it's the infrastructure your agent platform will depend on. Without it, every new agent becomes a bespoke integration project.
The Question That Matters Most
Building an agentic enterprise isn't just about models, orchestration, or tool calling. It's about packaging enterprise data into products that agents can use with the same discipline you apply to APIs, workflows, and security controls.
The organizations that understand this will move faster from impressive demos to operations that can actually be trusted.
So here's the question to take back to your team: Does your agent know when to stop because the data isn't reliable enough?
If the answer isn't yes, you're not ready for production.
This article was originally published on ariefwara.github.io.
Top comments (0)