Most Agentforce pilots stall in the same place. Not the agent builder, not the topics and actions configuration, but the data sitting underneath it. An agent is only as good as what it can see, and most Salesforce orgs I’ve worked in weren’t built with an AI reasoning over every field in mind. They were built for humans who knew which picklist value actually meant what, which custom field was deprecated three years ago but never deleted, and which record type nobody uses anymore.
Agentforce doesn’t have that institutional memory. It reads the data model as it exists today, and if that model is inconsistent, duplicated, or poorly labelled, the agent gives confident, wrong answers instead of admitting it doesn’t know.
Start with what the agent can actually see
Every topic and action you configure in Agentforce ultimately resolves to data: a record, a field, a related list, a flow that queries something. Before touching the builder, I ask a blunt question on every engagement: if a new hire read this object’s field list with no tribal knowledge, would they understand what each field means and when it’s current?
On a typical enterprise Service Cloud org, the answer is usually no. There’s a Status field with twelve values, four of which haven’t been used since a process changed two reorgs ago. There’s a Priority field and a separate Priority_Legacy__c field that nobody migrated off. An agent asked to summarise case urgency will happily average across both, because nothing in the schema tells it one is dead.
The fix isn’t glamorous
Field audits. Deprecating unused fields, or at minimum marking them clearly in help text. Collapsing duplicate meaning into a single source of truth. It’s the kind of work that never makes it onto a roadmap on its own merits, but it’s the actual prerequisite for an agent that doesn’t hallucinate case status to a customer.
Record-level security is the agent’s permission boundary
Agentforce runs under a user context, which means sharing rules, permission sets, and field-level security all apply to what the agent can retrieve and act on. I’ve seen teams assume the agent gets broader access than a normal user by default. It doesn’t, and it shouldn’t. If your sharing model is already a tangle of manual sharing rules bolted onto a role hierarchy that outgrew its original design, the agent hits the same gaps your human users do: able to see a case but not the account, able to read a contact but not update it.
Before any Agentforce rollout, map which persona the agent runs as, then actually test what that persona can and can’t reach. Don’t assume it. I’ve watched a pilot fail in its first week because the agent was configured under a service account with read access to Opportunities but no access to the custom object holding renewal terms, so every renewal-related question came back empty.
Data Cloud makes this worse before it makes it better
If you’re layering Data Cloud underneath Agentforce to unify Service Cloud and Marketing Cloud data, the harmonisation step matters more than the AI step does. Identity resolution rules decide which records represent the same person. Get those rules wrong and you get an agent confidently merging two different customers’ order histories, or splitting one customer into three partial profiles depending on which system last touched their record.
A typical enterprise org I’ve supported had three separate systems feeding contact records, each with its own idea of what counts as a unique customer. Before connecting Agentforce to that, the right move is weeks of validating match rules on a sample set, checking false merges and false splits by hand. That validation work is slower than the Data Cloud setup itself, and skipping it is the single most common reason agent answers come back wrong with total confidence.
What good looks like
- A documented identity resolution strategy, tested against real duplicate and near-duplicate records, not just the clean demo set
- Calculated insights and segments that are actually maintained after go-live, not abandoned once the initial Data Cloud project closed
- A named owner for data quality who isn’t the same person racing to ship the next Agentforce use case
Actions and flows are the agent’s real API surface
Topics get the attention in Agentforce demos, but actions are where the technical risk lives. Every action you expose is effectively an API endpoint the agent can call on its own, built on a flow or an Apex invocable method that was probably written for a human-triggered process. Those flows often have assumptions baked in: a specific picklist value gets set earlier in the user’s manual sequence, a validation rule gets bypassed because the UI never lets a person reach that state in the first place.
An agent doesn’t share those assumptions. It calls the action with whatever inputs the conversation produced, and if the flow wasn’t built to handle unexpected or missing inputs gracefully, you get a DML error surfaced straight to a customer, or worse, a half-completed transaction sitting in the database. Every action exposed to Agentforce needs the same defensive design you’d put around a public API: input validation, bulkification, and a failure mode that doesn’t leave records in an inconsistent state.
Sequencing the work
The orgs that get real value from Agentforce did the data work first, usually in this order: field and object audit, sharing model validation, Data Cloud identity resolution where it applies, then action hardening. The ones that struggle configured the agent first and are now retrofitting data quality under pressure, often because a demo to leadership is already booked on the calendar.
If you’re scoping an Agentforce rollout, weight the estimate toward data model readiness, not the agent configuration itself. I’d rather spend three weeks cleaning up a Case object and one week configuring topics than the other way round. The configuration is fast once the data underneath it can be trusted. Reversing that order just means doing the same data work later, under worse conditions, with an agent already live in front of real users.