Every Agentforce rollout I’ve seen hits the same wall eventually, and it’s rarely the agent itself. The reasoning works. The topics are scoped sensibly. The actions call the right flows. Then someone asks the agent a simple question about a customer, and it gives an answer that’s wrong, or worse, confidently wrong. Nine times out of ten, the fault sits in the data underneath it, not in the agent.
That’s the part nobody wants to deal with first. Data Cloud is supposed to be the unified layer an agent reasons over: one customer, one view, every interaction in context. In practice, most orgs haven’t done the work to get there. They’ve connected sources, mapped some fields, and called it done. An agent built on top of that inherits every gap, every duplicate, every stale record, and amplifies it, because now something is acting on the data instead of just displaying it.
An agent can only act on what it can see
A dashboard with a duplicate customer record is an annoyance. A human spots it, mentally merges the two in their head, and moves on. An agent doesn’t do that. If Data Cloud hands it two unified profiles for the same person because identity resolution didn’t match them, the agent will quite happily treat them as two different customers. It’ll miss the open case under profile A when answering about profile B. It’ll recommend a product the customer already bought, because that purchase lives in a record it never saw.
This is the part that catches technical leads out. We’re used to building for correctness within a single transaction: get the right fields, write the right values, respect the governor limits. Agentforce changes the unit of correctness. Now it’s whatever Data Cloud assembles as “the customer,” and if that assembly is wrong, every downstream action is wrong too, even when every individual Apex action and flow behind it is written perfectly.
Where the mess actually lives
In the orgs I’ve worked in, the same handful of problems show up again and again:
- Duplicate identities across sources. The same person exists as a Contact in Service Cloud, a subscriber in Marketing Cloud, and a lead from a web form, with three slightly different email addresses and no reliable match key between them.
- Stale data masquerading as current. A nightly sync job looks fine right up until an agent starts answering questions in real time off data that’s eighteen hours old.
- Field drift. “Active” means something different in the billing system than it does in the CRM, and nobody ever documented which one Data Cloud should trust when they disagree.
- Siloed sources that were never meant to talk. Marketing Cloud journeys and Service Cloud cases evolved independently for years. Pulling them into one unified profile surfaces every inconsistency in how each team recorded the same kind of event.
None of this is exotic. It’s the ordinary debt that builds up in any org that’s been customised for a decade. Reporting and dashboards tolerate that debt. Agents don’t.
Identity resolution is the real foundation, not the agent config
Most teams spend their setup time on the agent itself: writing topics, tuning instructions, wiring up actions. That’s the visible, satisfying part of the build. Identity resolution in Data Cloud is the unglamorous part, and it’s also the part that determines whether anything downstream actually works.
Get the match rules wrong and you get one of two failure modes. Too loose, and the agent merges people who aren’t the same person, which is worse than a duplicate because now it’s confidently wrong about who it’s talking to. Too strict, and you’re back to fragmented profiles, with the agent missing context it should have had.
Getting this right means sitting down with the actual source systems and asking, record by record, what a reliable match key looks like. Email alone usually isn’t enough. Phone numbers get recycled. Sometimes the best signal is a composite: email plus a loyalty ID plus a fuzzy match on name and address, with a confidence threshold someone has actually tested against real records, not just the handful used in the demo.
What to check before an agent gets anywhere near write access
Before any Agentforce action touches live data, I want these settled:
- Run identity resolution against a real, messy sample of production data, not a clean subset picked to make the demo look good.
- Pick an owning source for every field that can conflict across systems, and document it somewhere a new team member will actually find.
- Set a freshness expectation per data stream, so you know which ones the agent can trust in real time and which ones lag.
- Test the agent against known duplicate and edge-case records on purpose, not by accident three weeks after go-live.
- Build a way to see exactly what the agent saw when it gets something wrong. If you can’t trace a bad answer back to the record it pulled, you can only fix the symptom, not the pattern.
That last point matters more than it sounds. When an agent gives a wrong answer, the instinct is to tweak the prompt or the topic instructions. Half the time the actual fix sits in Data Cloud, not in Agentforce at all. Chase it in the wrong layer and you’ll burn a sprint while the real problem keeps producing the next bad answer.
Agentforce makes data quality everyone’s problem again
For years, data quality in Salesforce orgs has been something you clean up before a big migration or a reporting push, then let drift again once the project’s done. Agentforce removes that luxury. An agent is live, answering questions and potentially taking actions, every day, against whatever state the data happens to be in at that exact moment.
If you’re scoping an Agentforce build right now, the honest first question isn’t which topics to configure. It’s whether Data Cloud can produce one trustworthy view of the customer, under load, on data nobody’s had time to clean up yet. Answer that first and the agent work gets a lot easier. Skip it, and you’ll spend months debugging an agent that was never the actual problem.