Salesforce Data 360: The Context Problem in Enterprise AI

About a year ago, I wrote about whether Salesforce Data Cloud was worth it.

At the time, the conversation tended to get stuck in a fairly predictable place. Was Data Cloud another CDP? Was it a data lake? Was Salesforce trying to take on Snowflake or Databricks? And if a company had already spent a fortune building a modern data platform, why would it want another place for its data?

My argument was that those comparisons were missing something. Data Cloud didn’t need to replace Snowflake or Databricks to be useful. Salesforce was trying to bring data together so it could be used in customer interactions, marketing, service and AI.

I still think that was broadly right.

What I didn’t properly appreciate was where the product direction might take that idea.

Data Cloud becoming Data 360 is the obvious change, although I’m not sure the name itself matters that much. Salesforce renames things all the time. We’ve all made our peace with that by now.

The more interesting development is that Salesforce increasingly seems to be building for a world where Salesforce is no longer just somewhere people log in and do their work.

I’ve written separately about Salesforce Headless 360, because I think that shift deserves a closer look. Salesforce capabilities are increasingly being exposed so that applications and agents can use them without someone sitting in front of a Salesforce screen.

That changes the context around Data 360 for me.

We’ve spent years connecting systems. AI creates a different problem.

I’ve spent a fair bit of my career around integration and enterprise platforms. Much of the conversation has been about getting systems to talk to each other.

That is still a real problem, by the way. Anyone who thinks MCP suddenly makes enterprise integration easy probably hasn’t spent enough time looking at a large organisation’s technology estate.

MCP can make capabilities easier for an agent to discover and invoke. I’m loving being able to update my Salesforce opportunities through Claude. That’s genuinely useful.

But it doesn’t clean up twenty years of acquisitions, inconsistent data models or systems that all have slightly different ideas about what a customer is.

And that is the bit I think is becoming more interesting.

As agents get access to more systems, the problem starts to move beyond whether they can reach the information.

What do they do with everything they can see?

Imagine an agent dealing with a customer. It may be able to access Salesforce, Snowflake, a policy administration system, ServiceNow and several internal applications.

From a technology perspective, that’s increasingly achievable.

The awkward bit comes afterwards.

A person working in Salesforce has an advantage here that we don’t always notice. When someone opens an account or a case, they are already bringing their own understanding to the interaction. They recognise the customer, remember previous conversations and can usually spot when something doesn’t look quite right. If the information in front of them is incomplete, they know where else to look or who to ask.

An agent needs much more of that context to be made available deliberately.

And context isn’t just data.

The customer record is rarely the whole story

Take an insurer as an example.

An AI agent might see that a customer has contacted the business several times recently and has a renewal coming up. It might identify a risk that the customer is likely to leave.

So far, so good.

Then the real-world complications start appearing.

There could be an open complaint that changes how the interaction should be handled. The customer may have been identified as needing additional care. The renewal might already be with a specialist team. The agent might be able to explain the customer’s options but have absolutely no authority to change the premium.

And because this is enterprise technology, there is every chance the customer appears twice somewhere because they changed their name three years ago and one system never quite caught up.

Giving the agent access to all of those systems is only part of the problem. It needs to understand which pieces of information matter to this interaction and what should happen as a result.

It also raises a slightly uncomfortable question.

How much context is enough before you’re comfortable letting an agent act?

That’s not purely an architecture decision. A technology team can tell you what information is available. It can’t decide the organisation’s appetite for risk.

Once an agent starts acting autonomously, somebody has to decide what happens when systems disagree. And somebody has to decide when the agent should stop and hand the decision to a person.

That involves architecture, certainly. It also involves the business, risk and governance teams.

I don’t think the future architecture has a single centre

There is a natural instinct in enterprise architecture to try to create a centre.

Put the important data in one place. Create a common model. Establish a single source of truth. Give the AI one governed layer to work from.

There are good reasons for doing that.

The problem is that most large organisations aren’t starting from a blank sheet of paper.

Many of the customers I work with already have substantial investments in Snowflake or Databricks. Those platforms aren’t going anywhere. Neither are the industry platforms, core systems and operational applications that hold information Salesforce doesn’t own and probably shouldn’t own.

I ask customers what their single source of truth is and it’s sometimes a surprisingly difficult question to answer.

That’s not because they’re badly run. It’s because a large enterprise is messy.

The customer relationship might be in Salesforce. The financial history might sit somewhere else. Product information could live in another platform. Identity may have its own system. Compliance rules may exist in systems that have nothing to do with the CRM.

Trying to move everything into Salesforce would be a strange response to that reality.

And, to Salesforce’s credit, I don’t think that’s where the direction is heading.

The move towards zero-copy and federated approaches makes more sense. Some data can be brought together and prepared for use. Other information can remain where it already lives and be accessed when required.

That feels like a much more realistic direction for the customers I speak to.

The context an agent needs will probably remain distributed. The question is how much of it needs to be assembled for a particular interaction, who does that work and where the boundaries sit.

That is a much harder problem than simply choosing a data platform.

Centralise everything or retrieve what you need?

This is the trade-off I think will become increasingly important.

One approach is to bring relevant information together ahead of time. Resolve identity. Harmonise the data. Establish common definitions and make a governed set of information available to applications and agents.

There are obvious advantages. An agent doesn’t have to work out which of five systems contains the right answer every time it is asked a question.

But nothing comes for free.

You have another platform to manage and pay for. You have to decide what belongs there. There can still be duplication, even if federation reduces the need to physically copy data. And somebody needs to maintain the logic that turns the messy reality of an enterprise into something coherent.

The other approach is to leave more information where it already lives and retrieve it when needed.

That preserves existing investments and, in many cases, keeps the information closer to its source. It can also avoid another enormous data migration programme, which I’m sure will disappoint absolutely nobody.

But now the complexity appears at runtime.

An agent may need to call several systems, deal with latency and understand which response takes precedence. Security becomes more complicated. So does reliability.

There is also a risk that every new agent becomes its own bespoke integration project, because each one is effectively being asked to work out part of the business for itself.

That is not a small problem.

Neither approach is obviously right.

I suspect most large organisations will end up somewhere in the middle. Some context will be centralised because it needs to be resolved consistently. Other information will stay in the system that owns it and be retrieved when needed.

Which brings me back to Data 360.

The opportunity isn’t to own all the context

This is where I would be careful not to become a Salesforce fan boy.

I don’t think Data 360 is going to become the context layer for the enterprise.

Snowflake, Databricks, Microsoft and others are all building their own capabilities around metadata, governance, semantics and AI. In a large organisation, the idea that one vendor will own every definition and every piece of context feels unlikely.

I’m increasingly less interested in whether Data 360 becomes the place where enterprise context lives.

I don’t think that’s realistic.

What interests me more is whether it becomes good at bringing together enough of that context when Salesforce is involved in the interaction.

That’s a different proposition.

Salesforce already sits close to a lot of customer interactions. It knows about accounts, opportunities, cases, service processes, workflows and permissions. Data 360 can bring identity resolution and information from other systems into that picture.

If an agent is trying to help a customer, that combination could be valuable.

The agent doesn’t need the entire enterprise data estate.

It needs enough trusted information to deal with the situation in front of it.

That sounds straightforward until you start trying to build it.

MCP makes the context problem more visible

I also think MCP is relevant here, although not for the reasons some people suggest.

It provides a more consistent way for agents to discover and use capabilities. That is useful.

But exposing more capabilities doesn’t remove the mess underneath them.

Two systems can still disagree about a customer. Finance and sales can still have different definitions of revenue. A business rule sitting in one platform may conflict with a process built somewhere else.

I’ve seen enough integration projects to know that getting two systems connected is sometimes the point at which the interesting arguments begin rather than end.

AI doesn’t remove those arguments.

It may force us to deal with them more honestly.

When a human is looking at five different screens, they can make a judgement call. They can ask someone. They can recognise that the information is incomplete.

Once an agent starts acting autonomously, we have to be much more deliberate about what it knows, what it is allowed to do and what happens when it doesn’t have enough confidence.

That feels like the more interesting challenge to me.

Where Salesforce actually fits

I think Salesforce has an interesting position because it isn’t just somewhere data is stored.

For many organisations, it sits in the middle of actual customer interactions and the work that follows from them. A customer contacts the business, a case is created, an opportunity changes, a workflow starts or someone needs approval.

That gives Salesforce a useful view of operational state.

But it doesn’t mean Salesforce automatically understands the whole organisation.

The authority to make a decision may sit in a core system. Identity might be managed elsewhere. The data needed to understand a customer could be in Snowflake or Databricks. A compliance rule may sit outside Salesforce entirely.

This is why I think the architecture matters more than the product pitch.

There will be customers where Data 360 is the right place to bring together important context around a customer interaction.

There will be others where the centre of gravity remains firmly with Snowflake or Databricks.

And there will be plenty where the answer is deliberately split.

As a Salesforce partner, I think that last answer is probably going to be the most common one.

It is also the least convenient answer to put on a slide.

Where I land on this now

The question I’m more interested in now is how Salesforce participates in an increasingly distributed architecture where AI agents need to understand and act across multiple systems.

Data 360 has a credible role in that architecture, particularly when the interaction itself is happening through Salesforce or needs to draw on Salesforce’s understanding of the customer.

But it also comes with trade-offs.

Cost matters. Architecture matters. Governance matters.

There is a risk of creating another layer that promises to simplify everything while adding more complexity if the use case isn’t clear.

I would start with the interaction, not the product.

What is the agent actually trying to do? What information does it need to do that safely? Which systems should remain authoritative? What needs to be available in real time, and what can be prepared in advance?

The answers won’t be the same for every customer.

A year ago, I was arguing that Data Cloud didn’t have to replace Snowflake to matter.

A year later, I’m more interested in what happens when neither Salesforce nor Snowflake is the whole answer.

The enterprise AI architectures I see emerging are likely to be messier than the vendor diagrams suggest. Different systems will continue to own different parts of the truth, and I doubt there will be a single context layer that neatly sits above all of them.

The challenge is working out what an agent needs to know for the decision in front of it, where that information comes from and who is comfortable letting it act.

I think that’s why Data 360 has become much more interesting to me.