The demo is not the question
Agentforce demos well. That is not a criticism — it is a genuinely capable product, and the demo is an honest representation of what it does on clean data with a well-defined process. The problem is that the demo answers a question nobody was asking. Whether the agent can handle a case was never in doubt. Whether your org can support one is the actual question, and the demo is silent on it.
Six tests answer it. They are evidence tests, not opinion tests: each one has a fact you can go and check this afternoon.
Test 1 — Data quality
The check: export your accounts and contacts. Count duplicates, and count records with no activity in twelve months. That percentage is the best single predictor of whether an agent programme reaches production.
Why it decides everything: an agent does not hedge. Given two conflicting records it picks one and states the answer with the same confidence it would use if the data were perfect. A human rep would notice something was off; the agent will not, and neither will the customer receiving the answer.
Cost of failing: this is the most common reason an Agentforce pilot stalls short of production, and remediation is measured in months rather than weeks.
Test 2 — Process definition
The check: ask two leaders to independently write the entry and exit criteria for each stage of the process you want to automate. Compare the lists.
Why it decides everything: automation encodes a process. If the process exists only as convention, what gets encoded is one person's version of it, and the disagreement surfaces after go-live as 'the agent is wrong'.
Cost of failing: the divergence between those two lists is the work. It is a leadership exercise, it costs nothing but calendar time, and skipping it is why so many automations get switched off.
Test 3 — Governance
The check: name the person accountable for what the agent is permitted to do, and the person accountable for consumption spend. If either is 'the team', you fail this test.
Why it matters commercially: Agentforce bills on consumption. Unlike seat licences, cost scales with usage and has no natural ceiling. An agent pointed at a poorly-scoped workflow generates spend without generating value, and finance typically discovers the number at quarter end.
Cost of failing: a consumption surprise, and the credibility damage that follows it.
| Seat licences | Cost is predictable; you know it at purchase |
|---|---|
| Consumption | Cost scales with usage; no natural ceiling |
| The control | One named owner, monthly review, modelled at 3x expected volume |
Test 4 — Integration depth
The check: list the systems the agent must read from or write to, and mark which are inside Salesforce and which are not.
Why it decides scope: the Data Cloud question is genuinely a technical one and it depends entirely on this list. An agent working within Salesforce data may not need it. An agent needing data that lives elsewhere probably does. Being told you need it before anyone has looked at your data model is a sales answer, not a technical one.
Cost of failing: either an unnecessary Data Cloud purchase, or a pilot that cannot see the data it needs.
Test 5 — Adoption capacity
The check: what proportion of your team uses the existing Salesforce org daily, without workarounds?
Why it predicts the outcome: agents are layered on top of a system people already do or do not trust. If reps keep shadow spreadsheets today, an agent operating on the official data inherits the gap between the two. Adoption problems do not get better when you add automation; they get faster.
Cost of failing: the agent works correctly and nobody believes it.
Test 6 — Measurement
The check: write down the number the agent is supposed to move, and its value today. If you cannot state the baseline, you fail.
Why it is not optional: without a before number, 'the agent helped' is unfalsifiable — which means it cannot be defended in a budget review, and the programme quietly loses funding at the first cost pressure.
Cost of failing: a working agent that gets cancelled anyway, because nobody could prove it worked.
What Salesforce's own market shift tells you
The Salesforce services market has moved. The dominant work is no longer first-time deployment — it is optimisation, modernisation and expansion of orgs that have been running for years. That shift matters for agent readiness, because it means most companies considering Agentforce are bringing years of accumulated configuration debt with them: overlapping automations, fields nobody owns, validation rules that fight each other.
That debt is what agents trip over. It is also nobody's favourite project after an exciting demo, which is precisely why it separates the programmes that reach production from the ones that quietly stop being mentioned.
Where we would tell you not to hire us
If you fail tests one and two badly, do not buy agent work — from us or anyone. The right next engagement is a data and process diagnostic, and if you would rather run that internally we will tell you what to look for and step back.
If you pass all six comfortably, you may not need an implementation partner at all. A capable admin and a clear owner can take a well-scoped first agent to production. We would rather tell you that than sell you a programme you can run yourselves.