What separates an Agentforce rollout that is still running in six months

The demo always works. Somebody asks the agent a question, it answers correctly, and the room agrees the technology is ready. Six weeks later the same agent is answering a narrower set of questions than it started with, because every time it got one wrong the team removed a topic rather than fixed the cause.

That is what failure usually looks like. Not an outage, a slow retreat, until the agent is handling three intents and nobody can remember why the business case said eleven.

The difference between the rollouts that hold and the ones that shrink is almost never the model. It is five things that get decided before anyone opens Agent Builder, and the weakest of the five sets the ceiling for the whole deployment.

#The readiness framework

This is the scoring we run before quoting an Agentforce build. It takes about half a day with the right four people in the room, and it has killed more projects at the right time than any other thing we do.

Score each dimension one to three. The total is not the point. The minimum is the point, because that is the level the whole deployment actually operates at.

An org scoring 3 on scope, grounding and permissions but 1 on evaluation does not have a mature deployment. It has a well-built agent that nobody will notice degrading.

#How to run the scoring session

The framework is only useful if the scoring is honest, and honest scoring is a function of who is in the room rather than how carefully the table is worded.

Four roles have to be present. Someone who owns the process the agent will touch, because they are the only person who can say what the correct answer actually is. Someone who owns the knowledge or data, because they know which sources are current. An administrator or architect who can speak to the sharing model without guessing. And someone from the operational team who will live with the result, because they will name the failure modes the others have never seen.

Missing any one of those produces a predictable distortion. Without the process owner you score grounding on whether documents exist rather than whether they are right. Without the admin you score permissions on intent rather than on configuration. Without the operational voice you score escalation on the happy path.

Run it as a scoring exercise, not a workshop. Each dimension gets read aloud, each person scores privately, then the scores are compared. Where two people differ by more than one level you have found the actual conversation, and that disagreement is usually more valuable than the eventual number.

#What to do at each score

A score is only useful if it implies an action. This is the remediation we recommend at each level, and the sequencing matters: dimensions do not improve independently.

The row that most often gets skipped is permissions at level one. Producing a current statement of who can see what sounds like documentation and is actually discovery, and in most orgs it is the single task most likely to change the project plan.

#Scope: the out-of-scope list matters more than the scope

Most teams write down what the agent should do. Far fewer write down what it must refuse, and that second list is the one that keeps you out of trouble.

An agent asked to "help with billing questions" will eventually be asked whether a customer can get a refund on a contract they signed eighteen months ago. The interesting design question is not whether it can find the contract. It is whether answering that at all is a decision your business wants automated.

Write the refusal list first. It is shorter, it is more contentious, and it forces the conversation with legal and operations early rather than after a customer screenshots something.

#Grounding: the answer has to exist before it can be retrieved

This is where most projects actually fail, and it is consistently misdiagnosed.

When an agent gives a wrong answer, the instinct is to treat it as a model problem. Occasionally it is. Far more often the answer it produced was a reasonable synthesis of the contradictory material it was given, because three knowledge articles describe the same policy differently and two of them are out of date.

Retrieval quality is a content and data problem. If you are unifying customer data to ground answers, that work sits in Data 360 and it is a project in its own right, not a configuration step inside the agent build.

The test we use is deliberately blunt: for each intent, can a competent new employee find the correct answer using only the sources the agent can reach, in under two minutes? If they cannot, the agent will not either, and no prompt will change that.

We wrote up the full pre-launch version of this in the grounding checklist we run before an agent talks to a customer.

#Permissions: your sharing model is the security boundary

An agent acts within a permission context. What that context can see, the agent can surface. This is the single most under-examined part of most implementations, and it is not an AI problem, it is the org's existing access model finally being asked a hard question.

Two practical consequences. First, the agent's running user is an architecture decision, not an admin detail. Second, an agent grounded on unified data can compose facts a human would have had to visit four records to assemble, which is a genuine change in effective exposure even when no individual permission changed. Salesforce's own guidance on cloud data security is the right starting point, but the work is specific to your sharing model.

If permission debt is the thing slowing you down, the pattern is a familiar one: we covered how it accumulates in permission set debt.

The three grounding failures, and how to tell them apart

Wrong answers look identical from the outside and have different fixes, so the first diagnostic job is telling them apart.

Missing is when the answer does not exist in any source the agent can reach. The agent either refuses, which is correct but unhelpful, or improvises, which is worse. The fix is content creation and it is the slowest of the three.

Contradictory is when two or more sources answer the same question differently. The agent produces a confident blend, and it will do so consistently, which is why this failure survives repeated prompt rewrites. The fix is editorial: pick the authoritative version, retire or redirect the others, and give it an owner.

Unretrievable is when the answer exists and is correct but the agent cannot find it, usually because it is phrased in internal language nobody outside the team would use, or it is buried in a document that answers eleven other questions first. The fix is structural: split, retitle, and add the phrasing real customers use.

The two-minute test separates these cheaply. Give a new starter only the agent's sources and ask them the question. If they cannot find it, it is missing. If they find two answers, it is contradictory. If they find it slowly or by asking a colleague which document to open, it is unretrievable.

What changes between internal and customer-facing

The five dimensions apply to both, but the bar moves, and moving it in the right place is what makes the internal-first sequence worth doing.

Scope is more forgiving internally, because a colleague who gets an odd answer asks a follow-up question rather than filing a complaint. Grounding is roughly as demanding either way. Permissions get harder internally in one specific respect, because employee agents often touch HR, finance and personnel data that customer-facing agents never see.

Escalation and evaluation are where the difference is largest. Internally, escalation can be informal and it still works, because people know who to ask. Externally, an undefined escalation is a lost customer. And internal evaluation can lean on the fact that users report problems, which external users mostly do not; they simply stop trusting it and go back to the phone.

That asymmetry is the argument for the internal-first sequence. You get to build the operating muscles on the dimensions that are forgiving, before you meet the audience that is not.

#Escalation: design the handover, not the apology

Deflection is easy to improve badly. An agent that never hands over will show an excellent deflection rate and a rising volume of repeat contacts a week later.

A designed escalation has three parts: a trigger, a route, and carried context. The trigger should include the obvious cases (explicit request, detected frustration, low retrieval confidence) and at least one business rule that has nothing to do with confidence, such as any conversation touching a complaint, a vulnerable customer, or a regulated product.

Carried context is the part teams skip. If the customer has to repeat themselves to the human, the escalation has cost you more goodwill than the agent saved.

#Evaluation: can you tell if it got worse?

Every change to a prompt, a knowledge article, a permission or a data source can alter answers in ways nobody predicted. Without a regression set, you find out from a customer.

Build a scored set of real questions with known-good answers before launch, not after. Fifty is enough to start. Run it before every change, and set a bar that blocks release. This is unglamorous and it is the difference between a system you operate and one you hope about.

#What the platform gives you, and what stays yours

A recurring source of underestimation is assuming the boundary sits further out than it does. Salesforce ships a great deal of the machinery; almost everything that determines whether the answers are right remains yours.

Read down the right-hand column and the shape of an Agentforce programme becomes obvious. Four of the five items are things a well-run Salesforce practice should already have, which is why agent projects so often turn into platform remediation, and why organisations with disciplined data and access models get to a working agent so much faster than their peers.

#The team, and the role most orgs are missing

The staffing conversation usually centres on who will build the agent, which is the least scarce skill involved.

You need someone who owns the process, someone who owns the content, an administrator or architect for the access model, and a builder. Most organisations can field all four. The role that is almost always absent is an evaluator: somebody whose actual job is to decide whether the answers are good enough, maintain the regression set, and hold the bar when a release is under time pressure.

Without that role, evaluation becomes a task that everyone agrees is important and nobody is measured on, and it is the first thing to go when a date slips. Naming a person, even part-time, is the single cheapest intervention we know of for keeping a deployment alive past its first quarter.

#Governance: who decides what the agent may say

This is a decision-rights question that gets discovered rather than designed, usually during an incident.

Four decisions need an owner before launch. Who approves adding an intent. Who approves a change to a knowledge source the agent reads. Who can widen the agent's permissions. And who can switch it off, without needing to convene anybody.

The last one matters more than it looks. In most orgs the person who first notices an agent behaving badly is a front-line supervisor, and the person authorised to disable it is three levels up and in a different time zone. Deciding in advance that the supervisor can pull it, and rehearsing that once, converts a potential incident into a shrug.

#The operating model after launch

Most implementation advice stops at go-live, which is roughly where the interesting part begins. An agent is a system that drifts, and drift has four independent sources: the prompt, the knowledge, the permissions and the underlying data. Any of them can change answers without anybody intending to.

The operating model that works has four elements and none of them are exotic.

A named owner, singular. Shared ownership of an agent produces the same outcome as shared ownership of anything else, which is that degradation is everyone's problem and nobody's job.

A change gate, which means the regression set runs before any change to prompt, knowledge or permissions reaches production. This is the element teams skip and then rebuild after their first silent regression.

A sampling cadence, because the regression set only tests what you thought to ask. Read a sample of real transcripts weekly at first, monthly once stable. The questions you did not anticipate arrive here, and they should be feeding back into the regression set.

A consumption watch, because actions per conversation is both a cost signal and a quality signal. A rise usually means retrieval got worse before anybody complained.

A worked scoring

To make the framework concrete, this is roughly how a mid-sized service organisation scored on first pass, and it is a common shape.

Minimum of one, so the deployment would have operated at level one regardless of how well the agent was built.

The useful part is what that implied. The project did not start with a build. It started with eight weeks of knowledge remediation and a fortnight of permission discovery, both of which had value independent of the agent, and both of which had been invisible on a plan that counted only configuration effort. The agent that eventually launched was narrower than the original proposal and is still running.

#Reading the rest of this cluster

This article is the judgement layer. The specifics live in their own pieces, and the order below is the order they usually become relevant.

If you have scored readiness and want the delivery sequence with its gates, that is implementing Agentforce: the sequence, and the gate between each step. If you are still choosing what to point an agent at, the scoring for that is Agentforce use cases that survive a business case, which is the piece to read before a budget conversation rather than after one.

If the argument in your organisation is whether an agent is the right mechanism at all, Agentforce or Flow? Where deterministic automation still wins is the honest version of that comparison, and it concludes that most of your automation should stay where it is. When the conversation turns to money, what an Agentforce rollout costs beyond the licence covers the three published buying models and the remediation costs that usually exceed them in year one.

The grounding dimension has its own pre-launch checklist in the grounding checklist we run before an agent talks to a customer, and if permissions came out low, the pattern behind that is set out in permission set debt.

#Three things that are not best practice, despite being common

Starting with the highest-volume intent. It is where the business case is and where variance is highest, and variance is exactly what an early deployment handles worst. The business case survives a narrower start; the deployment often does not survive a wide one.

Treating the pilot as a duration. Two weeks is not an exit criterion. Two weeks of read transcripts with no unresolved severity-one answer is. The distinction sounds pedantic until you meet a programme that completed its pilot on the calendar without anybody having read a conversation.

Fixing wrong answers with prompt changes. It works often enough to be a trap. Prompt work masks grounding failures rather than resolving them, and the masked version fails later, in a case you did not anticipate, in front of somebody who matters. Diagnose which of the three grounding failures you have before touching the prompt.

#What we would tell you to do first

Score the five dimensions. Then pick your first agent by the narrowest useful job you can find where all five score at least 2, and deliberately accept a smaller win.

The temptation is always to start with the highest-volume intent, because that is where the business case is. But high volume usually means high variance, and variance is exactly what an early deployment handles worst. A narrow internal agent that works, and that your team learns to evaluate and operate, is worth more than an ambitious customer-facing one that spends its first quarter being narrowed.

The organisations still running their agents a year later almost all did the boring version first.