Skip to content
AurumGene
All insights

Data 3604 min read

Why your data strategy decides your agent strategy

An agent is only as good as the data it can reach and trust. Start from the use case, unify what it needs, and govern it properly.

AurumGene

There is a common belief that agents are an AI problem. In practice they are mostly a data problem. The reasoning ability of the underlying models is rarely what holds an agent back. What holds it back is that it cannot see the right information, or sees information that is wrong.

A human employee compensates for poor data. They know which system to distrust, which colleague to ask, and which customer record is a duplicate. An agent has none of that instinct. It works with what it is given and answers with the same confidence either way.

That is why we tell leadership teams that their agent strategy is already being decided, for better or worse, by the state of their data.

Reach and trust

Two properties matter.

The first is reach. Can the agent get to the information the task requires? Customer data is typically spread across sales, service, billing, marketing and operational systems, often with different identifiers for the same person. An agent that sees only one of those views will give partial answers.

The second is trust. Is the information accurate, current and permitted for this use? Reach without trust is worse than no reach at all, because the agent will act on what it finds.

A platform such as Data 360 exists to address the first property: bringing data from many sources into a connected view that the rest of Salesforce can use. It does not address the second on its own. Trust comes from ownership, quality standards and governance, and those are organisational decisions.

Start from the use case, not the data lake

The instinct in many organisations is to fix the data first: consolidate everything, clean everything, then decide what to do with it. This is how data programmes run for years without producing a result anyone outside the data team can name.

We recommend the opposite direction. Pick the agent use case. Then work backwards to the data it needs.

Take an agent that helps service teams handle renewal queries. It needs the customer's identity, their current contract, their recent cases, their billing status and the renewal terms on offer. That is five data sets, not five hundred. Each can be assessed, corrected and connected in weeks.

Over several use cases, a unified foundation takes shape, and each step has delivered something of value on the way.

Unify the data your next use case needs, not the data you happen to have.

What to prioritise when unifying

When resources are limited, and they always are, we suggest this order.

  1. Identity. Resolve who the customer is across systems. Almost every agent use case depends on it, and errors here spread everywhere.
  2. Current state. What the customer holds, owes and has open with you today. This is what most enquiries are about.
  3. Recent interactions. What has happened lately, across channels, so the agent does not ask what the customer has already said.
  4. Knowledge. The policies, product information and procedures the agent draws on to answer. This content needs an owner and a review date as much as any database does.
  5. History and enrichment. Longer-term behaviour and third-party data. Useful for personalisation, rarely essential for a first agent.

Knowledge is the item most often overlooked. Organisations spend heavily on structured data and then point an agent at a library of documents nobody has reviewed in years. The agent will quote them faithfully.

Governance as an enabler

Governance has a reputation for slowing things down. For agents, the reverse is true. Clear rules about what data may be used for what purpose are what allow an agent to be given wider scope.

Four questions need settled answers for each data set an agent uses:

  • Who owns it? A named person responsible for its quality.
  • What is it permitted for? Including any consent or contractual limits on its use.
  • Who and what may access it? Agents should have the access the task requires and no more.
  • How is quality monitored? With a route for errors found by the agent or its reviewers to be corrected at source.

That last point deserves attention. Agents surface data problems quickly, because they use data at volume and their mistakes are visible. Organisations that treat those mistakes as signals, and fix the underlying record, find their data improves as a by-product of running agents.

The executive question

The question for an executive team is not "do we have a data strategy?" Most do, on paper. The better question is: for the first three agent use cases we care about, do we know what data each needs, where it sits, who owns it and whether it can be trusted?

If the answer is yes, the agent work can move quickly. If it is no, that is where the first investment belongs. Our advice is to make that assessment early and honestly, before the agent design sets expectations the data cannot meet.

Related reading

We are glad to discuss how any of this applies to your organisation.