Agentforce · before the deployment, not after
An agent does not break anything.
It stops compensating for what was already broken.
Reports let people work around bad data, because a person looks at a number and knows it is wrong. An agent is the first thing in the org that consumes the data model rather than displaying it, so it converts quiet problems into confident answers. Seven of them, and the check for each.
Reviewed 30 August 2026.
A note on the numbers you will find elsewhere
The widely quoted failure rate has no source anybody can check.
It appears in a great many articles about this subject, including an earlier version of this one, always without a study behind it. It is not repeated here, and no percentage on this page has been invented to replace it.
What can be defended is the mechanism rather than a rate, and the mechanism is more useful anyway, because it tells you what to check rather than how worried to feel.
Reveal 01
Duplicates stop being a reporting problem and become a wrong answer
A duplicate account has always been a nuisance in a report: the total is off and somebody notices. An agent reading the same data does not produce a slightly wrong total, it produces a confident sentence about the wrong record. The failure mode moves from visible and boring to invisible and plausible, which is the more expensive of the two.
How to check it before you deploy
Count accounts and contacts that match on the fields your matching rules use, then read ten of the pairs. If a person cannot tell which is authoritative in ten seconds, neither can an agent.
Reveal 02
The agent has to be somebody, and now that matters
Agents act in the org under a defined user and permission context. Automation has always run as somebody too, and nobody had to think about it, because a flow that reads too much simply reads too much quietly. An agent that can read too much will say it out loud, to whoever asked. Least privilege stops being a policy document and becomes an operational setting.
How to check it before you deploy
Write down, in one sentence, what the agent is allowed to read and what it is allowed to change. If that sentence cannot be written before the build, the build is premature.
Reveal 03
Whatever never reached Salesforce is invisible to the agent
Half of most customer relationships lives in inboxes, calls and messages that were never captured. A person compensates from memory. An agent cannot, and it does not know it is missing anything, so it answers from the fraction that was recorded with no signal that the fraction is partial.
How to check it before you deploy
Take twenty closed opportunities and count the logged activities on each. If the median is low enough that you already know the number is wrong, the agent will be working from that number.
Reveal 04
Somebody has to decide what the agent is for
The most common reason a deployment stalls is not technical. It is that no one narrowed the scope, so the agent is asked to be generally helpful, which is not a specification. Narrow agents that do one job well are the ones that survive review, and the narrowing is a business decision that cannot be delegated to whoever configures it.
How to check it before you deploy
Name the one task, the one audience and the one measure of whether it worked. Three sentences. If any of the three is contested, that argument is the actual first phase.
Reveal 05
An agent action is an action, and somebody owns it
When an agent updates a record, sends a message or closes a case, that happened. Who reviewed it, what is logged, what the customer sees and who answers when it was wrong are governance questions that most orgs have never had to write down, because until now every action had a person attached to it by default.
How to check it before you deploy
Pick the three actions the agent will take most often and, for each, name the person who answers for it when it goes wrong. If the answer is the vendor, or nobody, that action is not ready to be automated.
Reveal 06
The bill behaves like usage, not like seats
Agent work is billed on consumption rather than per user. Salesforce publishes a Flex Credits rate card and dates it, currently 21 April 2026, in which each action consumes credits according to complexity. Several billing models coexist. This is the first Salesforce cost that grows when the system is used more, which is a different conversation with finance than any previous licence.
How to check it before you deploy
Estimate the number of actions per day at the volume you actually have, not at the volume in the demonstration, and check which billing model is on your agreement before deployment.
Reveal 07
Deflection is only measurable if the process was written down
The point of most agents is to remove work that people were doing. Whether that worked can only be measured against how much work there was and how long it took, and that baseline is missing in most support and sales operations. Without it, deflection is a feeling, and the renewal conversation is an argument about feelings.
How to check it before you deploy
Measure the baseline before the agent goes anywhere near production: volume by type, handling time, and what proportion was already answered by a template.
What the seven have in common
Every one of them existed before the agent, and none of them raised an error.
Duplicates, over broad permissions, uncaptured activity, unwritten scope, ungoverned automation and unmeasured processes are all survivable while a human sits between the data and the decision. The human is doing repair work continuously and nobody counts it, because it looks like ordinary competence.
Remove the human from that position and the repair stops. That is the whole of it, and it is why the readiness conversation is a data conversation rather than an artificial intelligence one.
Where to start
Measure four things, then decide.
Duplicate rate, how complete the account identity is, whether activity capture reflects what actually happened, and whether source attribution survives to the opportunity. Those four decide whether an agent will be useful or confidently wrong, and all four can be measured against exports you already have without anybody touching the org.
Asked often enough to answer here
Questions
Does Agentforce fail more often than other Salesforce projects?
The honest answer is that the widely quoted failure rates for it do not have a source anybody can check, so this page does not repeat one. What is defensible is the mechanism: an agent is the first thing to consume the data model rather than to display it, so it surfaces problems that reports let people work around. The project does not fail because of the agent. It fails at the point where the agent stops compensating.
Should we fix the data first or deploy and learn?
Deploy and learn is reasonable for a narrow, read only agent on a single well understood process, and it is how you find out what you did not know. It is not reasonable for an agent that writes to records or talks to customers, because there the learning happens in front of somebody who is paying you.
What is the smallest useful first agent?
One task, one audience, read only, with a person reviewing what it produced for the first few weeks. That is unglamorous and it is the version that reaches month six. Agents that were scoped as generally helpful are the ones quietly switched off, and the reason is almost never the model.
How do we know whether our org is ready?
Four measures against your own exports: duplicate rate, how complete the account identity is, whether activity capture reflects reality, and whether source attribution survives. There is a free version of that check in the browser and a full one for 500 euro, read only, delivered within three working days, with a verdict and a costed order of work.
Is any of this an argument against Agentforce?
No. It is an argument against deploying it as a way of avoiding a data conversation. The capability is real and the orgs that get value from it are the ones where somebody did the boring work first. That was also true of reporting, and of automation, and the pattern has not changed.
Serhii Skrypnyk · Senior Salesforce Administrator and developer · 7 Salesforce certifications · on the platform since 2018. Reviewed 30 August 2026.