Agentic Transformations: What About Data?

1. The hidden cost of moving fast

Recently, I spoke with a team that made a deliberate choice to focus on quick “time to market” in their agentic transformation, and kept data concerns aside as a topic to be addressed later. They effectively (and consciously) traded reliability for speed.

At first, the strategy looked like a win: the team delivered several use cases in record time, generating strong momentum and enthusiasm from leadership. But as users began relying on these agents for daily operations, inaccurate results started popping up because the underlying data was incorrect, incomplete, or outdated.

This created several clear problems:

• Erosion of trust: Users lost confidence in the outputs and stopped trusting the agents
• Stalled adoption: rollout slowed down while the team paused to investigate root causes
• Higher overall cost: Fixing data pipelines with agents already live in production proved far harder than getting the data right first.

I understand where this team was coming from, but data readiness is part of the critical path of any successful agentic transformation.

2. What data do agents actually need?

Agents draw on different types of data to ground their responses and take decisions:

Structured data:

• Master data: the fundamental entities the business runs on — customers, products, suppliers, locations
• Transactional data: the record of what has happened — orders, invoices, interactions, events

Unstructured data — often underestimated, but essential for providing agents with contextual understanding:

• Documents: contracts, invoices, reports, policies
• Emails and communications
• Internal knowledge: wikis, SharePoint, Teams, content management systems
• Organisational data: org charts, roles, reporting lines

Both categories matter equally, an agent with clean transactional data but no enterprise context (e.g., access to the policy governing an exception) will confidently produce the wrong answer.

In practice, agents rarely access raw data sources directly. Enterprise data is typically surfaced through data products: curated, governed datasets with clear ownership, defined schemas, and quality guarantees. A data product might combine master and transactional data from multiple systems into a single, reliable view that agents can consume. Data products are how the principles in section 3 are operationalised in practice.

Knowledge graphs and enterprise taxonomies sit alongside data products to help agents understand not just what data means but also how concepts relate to each other, giving agents a structured map of the business to reason against, rather than leaving them to infer those relationships from raw data. In our agentic reference architecture, they are a required component, not an optional one. I will cover this in more depth in a future article.

3. Key data principles for agentic transformations

These principles determine whether agents can actually rely on the data they consume. Whether your organisation runs a centralised data lake or a federated data mesh is less important than whether these underlying principles are in place.

3.1. Agent outputs must be traceable to their data inputs

When an agent produces a wrong answer, the first question is always: was this a data problem or an agent problem? Without traceability, that question cannot be answered.

Traceability means being able to follow a chain from any agent output back to the specific data it relied on. In practice, this means:

• Input logging: which data sources, documents, or records were used for each request
• Decision audit trails: a record of the reasoning steps that produced each output
• Error attribution: when outputs are wrong, identifying whether the cause was bad data, missing data, or a reasoning failure

As agents take on more consequential decisions, traceability also becomes a compliance requirement. Regulators, business stakeholders, will ask why an agent decided what it did, and “we don’t know” is not an acceptable answer.

3.2. Data must be versioned and point-in-time reproducible

Data changes constantly. An agent that ran correctly last Tuesday may produce a different answer today because the underlying data changed. Agentic platforms need the ability to reconstruct what an agent was working with at a given moment.

Point-in-time reproducibility means:

• Version control for data: changes to datasets are tracked, not overwritten
• Snapshot access: the ability to query data as it existed at a specific point in time
• Change history: knowing what changed, when, and by whom or what

3.3. The provenance of every data input must be known

Provenance is about knowing where data came from. Was it sourced directly from a system of record, or aggregated from multiple upstream sources? Was it enriched or transformed along the way, and by whom?

This matters most for data products. A data product may combine data from S/4, SalesForce, and a PLM system. If any one of those upstream sources is unreliable, the whole product is compromised and without lineage, you will never know which one caused the problem.

Maintaining data lineage means:

• Source tracking: every field can be traced back to its origin system
• Transformation history: any enrichment, aggregation, or calculation applied to the data is recorded
• Dependency mapping: knowing which data products depend on which upstream sources, so a change in one can be assessed for its downstream impact

A single lineage gap can invalidate an entire data product for an agent relying on it.

3.4. Data must be exposed through defined contracts and a semantic layer

When “revenue” is defined differently across finance, sales, and operations systems, an agent ingesting raw values will produce answers that are technically correct but semantically wrong.

A semantic layer and data contracts address this by establishing shared, stable definitions that sit between the raw data and the agents consuming it:

• Semantic layer: a common vocabulary that maps business terms to their authoritative data sources — “revenue” always means this field, calculated this way
• Data contracts: formal agreements between data producers and consumers that define structure, meaning, quality expectations, and change management
• Schema standardisation: consistent API schemas so agents interpret fields the same way regardless of which system they come from

Without this layer, every agent team ends up building its own interpretation of the data — and those interpretations will diverge over time.

4. Data as a key enabler of the agentic transformation

The principles in section 3 are foundational. Enterprise architects and agentic technology transformation leads are responsible for ensuring they are consistently followed throughout the transformation.

4.1 Before the transformation: data readiness as a launch prerequisite

As part of the agentic governance framework, data readiness should be established before the first agent goes into production. This means putting in place the programme-level capabilities the four principles depend on:

• Data catalogue and ownership model: a central or federated inventory of data assets, with clear owners assigned for each domain
• Versioning and lineage infrastructure: tooling that tracks changes to datasets, records provenance, and supports point-in-time queries
• Semantic layer and data contracts: shared definitions agreed across domains, so agents consume data with consistent meaning regardless of source system
• Monitoring and observability: the ability to detect data quality issues continuously, not just at point of ingestion

Setting these up once, at the transformation program level, is what makes the problem manageable.

4.2 During the transformation: designing agents with data in mind

As each agent is designed and built, treat data as a first-class concern. For each agent:

• Map required data: which data products does this agent need, and are they available and governed? Where gaps exist, decide early whether to build a new data product or allow temporary direct system access — direct access bypasses governance and should be treated as a workaround, not a permanent solution.
• Verify governance and access: is the data governed? can the agent access it reliably?
• Confirm ownership: who is accountable for the data this agent depends on?

Agents that surface data gaps during design give the programme time to address them. Agents that surface them in production create incidents.

4.3 After the transformation: agents also produce data

Agents generate data. Every decision, recommendation, and action an agent takes becomes a record in the enterprise. Agent-generated data needs the same ownership and governance standards as any other enterprise data, otherwise future agents may treat ungoverned agent output as ground truth, making inaccurate data problems worse over time.

Autonomous agents have no way of knowing their inputs have degraded, and will keep making decisions regardless. Continuous monitoring of data quality identifies drift before it affects agents at scale.

5. Closing

The success of an agentic transformation depends on the data that is made available to agents. Agents running on the most advanced foundation model can be rendered useless if constrained by the quality, lineage, and governance of the data they consume and produce.

Treating data readiness as a prerequisite, rather than a post-launch afterthought, makes the difference between a stalled agentic transformation and a successful one.