Readiness is a property of the use case, not the platform
It is tempting to treat Agentforce readiness as an organisational milestone: we are ready, or we are not. In practice, readiness varies enormously by use case within the same organisation. A company may be entirely ready to deploy an agent for order status enquiries and nowhere near ready to deploy one for complex contract interpretation, because the underlying data and process maturity differ sharply between the two.
This is why a readiness assessment should be scoped to a specific candidate use case rather than conducted as an abstract exercise. The right question is never 'are we ready for AI agents' in general; it is 'is this particular workflow, with this particular data and this particular action set, ready to be delegated to an agent'.
Data grounding: the agent needs a single, trustworthy source
An agent's answers are only as reliable as the data it retrieves. Data grounding readiness means the records the agent will query — customer, account, case, order, entitlement, whatever is relevant — exist in a single authoritative location, are kept current by an owned process, and do not require the agent to reconcile conflicting versions of the truth itself.
Many organisations discover during readiness assessment that the data they assumed was clean is actually duplicated across systems, with no clear rule for which version wins. An agent placed on top of this ambiguity will produce inconsistent answers that erode trust quickly, often faster than a human process would, because the inconsistency is now visible at scale.
The remedy is not always a full data platform rebuild. Sometimes a narrower fix — resolving duplicate records for the specific entity the agent needs, or establishing a single field as the system of truth for one attribute — is enough to unblock a well-scoped use case.
- One authoritative record per entity the agent will query
- A clear, owned process keeping that record current
- No requirement for the agent itself to reconcile conflicting data
Permission and sharing model: the agent inherits, it does not override
An agent should never have broader visibility or authority than the most restricted human role it might be standing in for. Readiness here means the organisation's sharing model — who can see which records, who can take which actions — is well defined enough to be inherited cleanly by an agent, rather than needing to be invented for the agent from scratch.
Organisations with a loose or inconsistently enforced sharing model in Salesforce today will carry that same looseness into their agent deployment, at greater risk, because an agent operates at a speed and scale that makes an incorrectly broad permission far more consequential than the same gap in a manual process.
A useful readiness test is whether the organisation can articulate, in specific terms, exactly which records and fields the proposed agent will be able to see and touch, and whether that scope maps precisely to a defined business role. If the answer is vague, the use case is not ready.
Action inventory: name every action before you automate it
A readiness assessment should produce an explicit inventory of every action the agent will be permitted to take, described specifically enough that a reviewer could evaluate the risk of each one individually. 'Handle billing enquiries' is not an action inventory; 'issue a credit up to a defined value, update a billing address, generate an invoice copy' is.
This exercise routinely surfaces actions that sound reasonable in aggregate but are clearly too high-risk for autonomous execution once named individually. Separating the low-risk, high-volume actions from the high-risk, low-volume ones is what allows an organisation to grant the agent real autonomy on the former while keeping a human firmly in the loop on the latter.
Escalation paths need to exist before the agent goes live, not after
Escalation readiness means the organisation has already defined where an agent hands off to a human, what context transfers with that handoff, and which team receives it. This should never be an afterthought designed once real customers start hitting the agent's limits.
A well-designed escalation path preserves everything the agent has already established — the customer's identity, the issue as described, the data already retrieved — so the human is not starting the conversation over. A poorly designed one simply drops the customer into a general queue, which is often a worse experience than if no agent had been involved at all.
Testing: evaluate the agent like a new hire, not a feature release
Readiness for testing means the organisation has a representative set of real scenarios — including edge cases, ambiguous requests and adversarial inputs — against which the agent's responses can be evaluated before go-live, and on an ongoing basis after it. This is different from typical software testing, because the agent's behaviour is probabilistic rather than deterministic, so a single passing test run tells you less than it would for conventional code.
Organisations that are genuinely ready have already built or adapted an evaluation process for this: a way of sampling agent conversations, scoring them against defined criteria, and tracking whether quality drifts over time as the underlying data or model changes. Organisations that plan to test once before launch and then move on are not ready, regardless of how good that one test run looks.
- A representative scenario set including edge cases and ambiguous requests
- A scoring process usable both before go-live and on an ongoing basis
- A defined owner for monitoring quality drift over time
Change management: someone has to own how work changes
Deploying an agent changes what human agents and supervisors do, even when the agent only handles a subset of volume. Readiness on this dimension means the organisation has thought through how case queues are re-routed, how supervisors are trained to review agent-handled interactions, and how staff understand the agent's role rather than perceiving it as an unexplained replacement.
This is frequently the most underestimated readiness dimension, because it involves people and process rather than systems, and it is tempting to assume it will resolve itself once the technology is live. It rarely does. Organisations that invest deliberately in this before go-live see far smoother adoption than those that treat it as a communications afterthought.
What disqualifies a use case
Certain conditions should stop a use case from proceeding to deployment regardless of how much executive enthusiasm exists behind it. A use case where the underlying data has no single source of truth, where the required actions cannot be scoped precisely, where escalation has not been designed, or where the outcome of an error is severe and hard to reverse, is not ready, no matter how sophisticated the underlying model is.
The discipline required here is organisational, not technical: a willingness to say that a visible, executive-sponsored use case is the wrong one to launch first, in favour of a less exciting one where the foundations are actually solid. That discipline is the single strongest predictor of whether an Agentforce programme succeeds past its first quarter.