Most orgs aren’t. That’s not an insult; it’s just what happens after a decade of accumulated configuration, three admins who’ve since left, and a data model that got extended every time someone needed a field on a Tuesday.
None of that mattered much when only humans were clicking around. Humans compensate. A rep sees two Acme Corp accounts and knows which one is real. An agent sees two records and picks one.
So before you scope an Agentforce project, it’s worth working out honestly where you actually stand. This checklist is what I’d walk through. It’s deliberately blunt, and a few of the questions will be uncomfortable.
Score yourself as you go. I’ll tell you what the total means at the end.
Section 1: Data
Can you state your duplicate rate?
Not “we have duplicate rules enabled.” The actual percentage. If nobody knows, that’s a no.
Are your contacts alive?
Pull the percentage of contacts with no activity in 24 months. In most orgs, it’s north of 40%. An agent preparing a meeting brief from those records will produce a confidently wrong brief, and the rep who gets burned by it once will never open another.
Is there one definition of “active customer”?
Ask three people in three departments. If you get three answers, the agent will inherit all of them.
Is your knowledge base current?
Agents ground responses in knowledge articles. If half of yours describe a returns policy you changed in 2023, the agent will cite the old one with total confidence.
Does the data the agent needs actually live somewhere reachable?
Order status in the ERP, usage in the product database, and entitlements in a spreadsheet on someone’s desktop. Be honest about that last category; every org has one.
Score 1 point per yes.
Section 2: Permissions
This section is the one people skim. Don’t.
Was your permission model designed, or did it accumulate?
Profiles cloned from profiles. Permission sets granted for a 2021 project that ended. Sharing rules nobody has opened since the person who wrote them left. If that description stings, you know the answer.
Do you know what your integration users can see?
Agents run with an inherited access scope. If that scope is “everything,” so is the agent’s blast radius.
Could you explain, in one sentence, what an agent should never be allowed to change?
If you can’t articulate the boundary, you can’t configure it.
Do you have an audit trail plan?
When an agent does something wrong and it will, can you reconstruct why early?
This is the least glamorous work in an Agentforce rollout and the most consequential. It’s also the work a serious Salesforce Consulting company will insist on completing before any agent gets configured. If a partner is happy to start building topics without asking about your sharing model, that’s a useful signal about the partner.
Score 1 point per yes.
Section 3: Process
Are your rules written down anywhere?
Not in a director’s head. Written. If your lead qualification criteria are “we know a good lead when we see it,” there is nothing to give an agent.
Do you have thresholds, or just judgment?
“Issue a refund if it seems reasonable” is not an instruction. “Full refund under 30 days if unopened, store credit 31-60 days, escalate otherwise” is.
Do you know your escalation paths?
Every agent needs a defined exit to a human. If your current escalation process is informal, formalise it before you automate around it.
Have you picked a process narrow enough to fail safely?
The right first project is high-volume, low-consequence, and boring. Order status. Password resets. Meeting prep. If your first project is quote approvals for enterprise accounts, you’ve picked wrong.
Score 1 point per yes.
Section 4: Technical debt
How many Flows do you have, and how many are still running?
Large orgs routinely have hundreds, with a meaningful share orphaned. Agents call the Flow’s actions. Orphaned automation is now an attack surface.
Do you have custom objects the standard actions can’t reach?
Most orgs do. A bespoke pricing engine, a homegrown territory model, a legacy system with a SOAP API written before anyone cared about REST.
Is anything critical undocumented?
The Apex class nobody wants to touch. Everyone has one.
Those three questions are really one question: how much integration work is hiding under this project? Because exposing custom objects and legacy systems as callable actions means writing Apex, wiring MuleSoft, and doing plumbing that never appears in a demo. That’s where Salesforce Development Services support usually gets pulled in, and it’s the cost line most first estimates simply omit.
Teams at DianApps have made the same observation publicly that agent configuration is a small share of the effort, while the integration layer underneath consumes the schedule. It lines up with what I keep seeing.
Score 1 point per yes on the first two; the third is a bonus point if you can say no.
Section 5: The organisation
The section nobody puts in a technical readiness checklist, and the one that sinks the most projects.
Do you have a success metric with a baseline? “Improved efficiency” is not a metric. Deflection rate, time-to-resolution, admin hours removed per rep per week pick one and know today’s number.
Does your service team think this is coming for their jobs? If yes, the project will fail quietly. They won’t sabotage it; they’ll just stop correcting it and stop reporting its errors, and it will never improve.
Is someone accountable for reviewing agent decisions? Not “we’ll spot check.” A named person with time allocated, for at least the first few months.
Has anyone modelled the consumption cost at peak? Agentforce is priced per action, not per seat. The average is fine. The seasonal spike is where finance gets surprised.
Score 1 point per yes.
What your score means
14-17: You’re ready, and you probably already knew that. Pick a narrow first process and go.
9-13: Typical. You can start, but the first project should be small, and the real work is remediation running in parallel. Don’t announce a launch date yet.
Under 9: You have a data and governance project, not an AI project. Building an agent now would mean automating a mess at speed. The good news is that the remediation work has value regardless of whether you ever deploy an agent; cleaner data and a sane permission model pay for themselves.
The thing I keep noticing
Almost nothing on this list is about AI.
It’s data quality, access control, written-down processes, integration debt, and change management. The same five things that have been quietly sinking enterprise software projects since long before anyone said “agent.”
Agents didn’t create new problems. They just made the existing ones act faster and complain less. And there’s something almost useful in that an Agentforce assessment is the first time a lot of organisations have been forced to look honestly at an org they’ve been avoiding for years.
Whether you deploy an agent afterwards is almost secondary.
FAQ
What’s the single biggest predictor of failure?
Data quality, closely followed by an undesigned permission model. Both are boring, both get skipped, and both are what people are actually complaining about six months later when they say the agent “doesn’t work.”
How long does remediation take?
Depends entirely on the org’s age and size. A five-year-old mid-market org might need weeks. A twenty-year-old enterprise org with four acquisitions in it should think in quarters, not sprints.
Can we start building while we remediate?
Yes, if the first use case is narrow and touches only clean data. That’s actually the smart play; a small win builds the political capital you’ll need to fund the unglamorous cleanup.
Do we need Data Cloud?
Not strictly, but without unified data, an agent works from a partial picture. If the data it needs lives outside Salesforce and there’s no pipe to it, the agent will guess, and it will do so confidently.