From AI-Ready Data to Agent-Ready Data

For years, many data architecture conversations started with the same question: How do we bring data together so the business can report on it?

With AI agents, I think we need to add another question:

What does an agent need to understand before we allow it to recommend — or take — an action?

A dashboard may tell us that overdue receivables have increased. An agent could go much further. It might be asked to identify the customers behind the increase, check disputed invoices, recommend the next step, and even create a follow-up task.

That is a very different demand on the data foundation. Every one of those steps requires more than a clean table.

What changes for the data foundation?

An agent needs to understand the agreed meaning of a measure such as DSO. It needs to know the relationships between customers, invoices, and disputes. It needs to understand where each figure came from, how fresh it is, and which permissions apply to both the user and the agent.

Just as importantly, there needs to be a clear boundary between explaining a situation and changing it.

An AI response can sound completely convincing even when one of these foundations is missing.

Gartner describes the move toward agent-ready data in terms of whether data is suitable for agentic use and whether the agent is using it in a valid way. McKinsey also emphasizes semantics, reusable data products, relationships, governance, and observability.

I find both perspectives useful because they move the discussion away from a broad statement such as “our data is clean” and toward something much more specific:

Is this data ready for this agent, this user, this decision, and this action?

How I would approach this in an SAP landscape

SAP Business Data Cloud and its data products can provide a governed starting point.

SAP Datasphere can help model business meaning and make data easier to discover and consume.

SAP Knowledge Graph also appears in SAP’s longer-term architecture vision as a semantic grounding layer for agents. I would treat that as architectural direction rather than assuming that every capability is already available in every customer landscape today.

If I were starting a customer workshop, I would begin with five questions:

1. What decision should the agent support?
2. Which facts would an experienced employee check before making that decision?
3. Who owns the definitions and quality checks behind those facts?
4. What is the agent allowed to see and do?
5. How will we trace its answer back to the supporting evidence?

The answers to those questions tell us what data products, semantics, documents, and controls are actually required.

For a first release, I would often start with an agent that explains a situation and cites the supporting records.

If users can validate the answer consistently, we can then assess whether a controlled action makes sense.

This is where I see the role of the data architect evolving. Our job is no longer only to deliver the right number. We also need to establish its meaning, reliability, context, and permitted use inside a business process.

A practical way to make this real is to start small: one question, one user role, and one proposed action.

That makes the architecture testable.

If the answer changes when the role or proposed action changes, the underlying data product may still be valuable, but the agent design probably needs a more precise boundary.

This also gives the architect an important role in adoption conversations.

We can bring finance, process, security, and data teams around one concrete scenario and make their assumptions visible. If they disagree, that disagreement is useful evidence. It tells us where the design is still unclear.

It is much cheaper to resolve those questions in a workshop than after an automated action has already been taken.

What to read next

 For years, many data architecture conversations started with the same question: How do we bring data together so the business can report on it?With AI agents, I think we need to add another question:What does an agent need to understand before we allow it to recommend — or take — an action?A dashboard may tell us that overdue receivables have increased. An agent could go much further. It might be asked to identify the customers behind the increase, check disputed invoices, recommend the next step, and even create a follow-up task.That is a very different demand on the data foundation. Every one of those steps requires more than a clean table.What changes for the data foundation?An agent needs to understand the agreed meaning of a measure such as DSO. It needs to know the relationships between customers, invoices, and disputes. It needs to understand where each figure came from, how fresh it is, and which permissions apply to both the user and the agent.Just as importantly, there needs to be a clear boundary between explaining a situation and changing it.An AI response can sound completely convincing even when one of these foundations is missing.Gartner describes the move toward agent-ready data in terms of whether data is suitable for agentic use and whether the agent is using it in a valid way. McKinsey also emphasizes semantics, reusable data products, relationships, governance, and observability.I find both perspectives useful because they move the discussion away from a broad statement such as “our data is clean” and toward something much more specific:Is this data ready for this agent, this user, this decision, and this action?How I would approach this in an SAP landscapeSAP Business Data Cloud and its data products can provide a governed starting point.SAP Datasphere can help model business meaning and make data easier to discover and consume.SAP Knowledge Graph also appears in SAP’s longer-term architecture vision as a semantic grounding layer for agents. I would treat that as architectural direction rather than assuming that every capability is already available in every customer landscape today.If I were starting a customer workshop, I would begin with five questions:What decision should the agent support?Which facts would an experienced employee check before making that decision?Who owns the definitions and quality checks behind those facts?What is the agent allowed to see and do?How will we trace its answer back to the supporting evidence?The answers to those questions tell us what data products, semantics, documents, and controls are actually required.For a first release, I would often start with an agent that explains a situation and cites the supporting records.If users can validate the answer consistently, we can then assess whether a controlled action makes sense.This is where I see the role of the data architect evolving. Our job is no longer only to deliver the right number. We also need to establish its meaning, reliability, context, and permitted use inside a business process.A practical way to make this real is to start small: one question, one user role, and one proposed action.That makes the architecture testable.If the answer changes when the role or proposed action changes, the underlying data product may still be valuable, but the agent design probably needs a more precise boundary.This also gives the architect an important role in adoption conversations.We can bring finance, process, security, and data teams around one concrete scenario and make their assumptions visible. If they disagree, that disagreement is useful evidence. It tells us where the design is still unclear.It is much cheaper to resolve those questions in a workshop than after an automated action has already been taken. What to read nextTopicWhy read itLink to readAgent readinessUnderstand why suitability and valid data use matter for agents.Open resourceArchitecture foundationsConnect semantics, data products, permissions, governance, and observability.Open resourceBusiness context for agentsExplore how SAP positions data products and semantic grounding for AI agents.Open resource  Read More Technology Blog Posts by SAP articles 

#SAPCHANNEL