Implementing Agentforce: the sequence, and the gate between each step

There is a version of this article that lists six phases and a duration for each. It would be easier to write and useless to deliver against, because the durations are set by the state of your org, not by the phases.

So this is the sequence with the gates instead. Each phase has one thing you have to be able to demonstrate before the next phase starts. If you cannot demonstrate it, the answer is not to proceed carefully. It is to stay in the phase.

We covered the judgement that sits underneath this in what separates an Agentforce rollout that is still running in six months. This is the procedure.

#The six phases

#Phase 1, qualify: pick the narrow thing

The output of this phase is not a business case. It is a list of intents the agent will handle, a list it must refuse, and an honest readiness score.

The gate that catches most projects is the out-of-scope list. Teams find it easy to say what the agent should do and genuinely difficult to agree what it must decline, because that conversation involves legal, operations and someone who owns the policy. Getting it signed off in phase one is the point. Getting it signed off in phase five is a delay.

#Phase 2, ground: the phase everyone underestimates

If your knowledge base has three articles describing the same refund policy and two are stale, an agent will produce a confident blend of all three. This is not a model failure. It is your content, retrieved accurately.

Grounding work is unglamorous: identify the authoritative source per intent, retire or merge the contradictions, name an owner, and set a review cadence. Where the answers depend on unified customer data rather than documents, the work sits in Data 360 and it is a project with its own schedule.

The full pre-launch version of this is the grounding checklist we run before an agent talks to a customer.

#Phase 3, build: configure the refusals too

Building in Agent Builder is the phase teams expect to be hard and usually is not. Two things are worth flagging.

First, the running user is an architecture decision made here and regretted later. What that user can see, the agent can surface. If you have not read your own sharing model recently, this is where that debt arrives, and it looks a lot like permission set debt.

Second, test the refusals as deliberately as the answers. An agent that handles its eleven intents beautifully and then confidently answers a twelfth it should have declined has failed the gate, even though every planned test passed.

#Phase 4, evaluate: build the ruler before you need it

Fifty real questions with known-good answers. Not questions you invented, questions from actual transcripts or tickets. Score the agent against them, record the score, and set the bar that a release has to clear.

This exists so that in three months, when someone edits a knowledge article and answer quality drops, you find out from the regression run instead of from a customer. Without it you have no way to distinguish "the agent got worse" from "people are complaining more this week".

#Phase 5, pilot: read the transcripts

Bounded audience, one or two intents, and a rollback you can execute in minutes. The instinct is to watch dashboards. The value is in reading conversations, because the failure modes that matter early are ones no metric names: the agent answered correctly but in a tone that will generate a complaint, or it resolved the question and missed that the customer was telling it something important.

Two weeks of read transcripts will change your escalation triggers more than two months of deflection charts.

#Phase 6, operate: someone owns this

An agent is not a project that finishes. Prompts, knowledge, permissions and data all drift, and each can change answers. Operating means a named owner, the regression set run on a cadence and before every change, and consumption watched: Agentforce is metered per action and Salesforce publishes the models on its pricing page, so an agent that loops or over-retrieves is both worse and more expensive.

#Phase 2 in detail: how to remediate knowledge

Grounding is the phase that sets the schedule, so it is worth more than a paragraph.

Start by inverting the usual approach. Do not audit the knowledge base. Audit the questions, then trace each one back to the source that should answer it. A knowledge audit produces a report about four hundred articles, most of which the agent will never touch. A question audit produces a work list.

Pull the top questions from real contact data for the intents in scope. Twenty to fifty per intent is plenty. For each, record three things: is there a source, is there exactly one source, and would a new starter find it. That gives you the three failure types, and each has a different fix and a different cost.

Missing answers need content written, which needs the person who knows to be available, and that availability is usually the real constraint. Contradictions need an editorial decision about which version is authoritative, which needs someone empowered to make it. Unretrievable answers need restructuring and retitling, which is the cheapest of the three and the one most likely to be skipped because the content is technically correct already.

The ownership problem underneath

Every knowledge remediation exercise surfaces the same structural issue: nobody owns the content. Articles were written by people who have moved on, edited by whoever noticed a problem, and reviewed on no schedule at all.

Fixing the articles without fixing the ownership buys you about a quarter. Name an owner per source, give them a review cadence they have actually agreed to, and put agent-read sources behind a change gate so edits are reviewed rather than published silently. That last control is the one that keeps the remediation from decaying.

#Phase 3 in detail: designing actions

The build phase has one design decision that determines how operable the result is: how wide each action should be.

Wide actions are faster to configure. One action that can read an account, update a case, send an email and post a note gets the demo working sooner. It also makes the agent impossible to reason about, because when something goes wrong you cannot tell which capability was misused, and impossible to permission precisely, because the action carries every right its widest branch needs.

Narrow actions cost more up front and are the only version you can operate. One action, one job, its own permission surface, and a name that says what it does. When an agent misbehaves you can see which action it invoked and decide whether the agent chose wrongly or the action behaved wrongly, and those two failures have completely different fixes.

The other rule worth stating: irreversible steps get their own guardrails regardless of what invokes them. Whether a refund is triggered by an agent, a Flow or a person, the refund action itself should validate, log and be capable of being reversed. Designing that at the action layer rather than the agent layer means it holds no matter what calls it later.

#Phase 5 in detail: what to read for

Reading transcripts sounds like a soft activity, so it helps to know what you are looking for. Four things, in rough order of how often they matter.

Near misses. The agent answered correctly but only just, or answered a slightly different question than the one asked and happened to be useful anyway. These predict future failures better than actual failures do, because they show where retrieval is marginal.

Tone mismatches. Technically correct answers delivered in a register that will generate a complaint. Common with policy content, which is written to be precise rather than to be read by an upset customer.

Missed signals. The customer mentioned something that should have changed the path, and the agent answered the literal question instead. A mention of financial hardship, a regulator, or a bereavement should route differently regardless of what was actually asked.

Loops. The agent taking six actions to reach an answer that should have taken two. This is a cost problem and a quality problem at once, and it is invisible in a deflection metric.

#What each gate catches in practice

Gates are only worth having if they actually stop something. These are the failures each one has caught on real programmes, which is the argument for not waiving them when a date is under pressure.

Qualify catches the use case that has no owner. If nobody can say whose number improves when this works, the project has a sponsor but not a customer, and it will lose every prioritisation argument for the rest of its life.

Ground catches the org that believed its knowledge base was fine. The two-minute test is deliberately humiliating: sit a capable new starter down, give them only the sources the agent will have, and ask them the twenty most common questions. Teams routinely discover that a third are unanswerable and another third have two plausible answers.

Build catches over-scoped actions. An action that can update six objects is convenient during the build and impossible to reason about afterwards, because when something goes wrong you cannot tell which capability was misused. Narrow actions cost more to configure and are the only version you can safely operate.

Evaluate catches the release nobody would have questioned. A knowledge edit made for good reasons drops accuracy on four unrelated intents, and without the regression run that surfaces in production a fortnight later as a vague sense that the agent has got worse.

Pilot catches tone and sequence problems no metric names. The agent answered correctly and made the customer angrier, or resolved the question while missing that the customer had just told it something that should have triggered a different path entirely.

Operate catches drift. Prompts, knowledge, permissions and data all change, and each can move answers. Without an owner, the first person to notice is a customer.

#Phase 4 in detail: building the regression set

Fifty questions with known-good answers, and where those come from matters more than the number.

Take them from real transcripts or tickets, not from a workshop. Invented questions are phrased the way the people who built the agent think, which is precisely the phrasing the agent handles best, so an invented set scores high and predicts nothing.

Each entry needs the question as a customer actually wrote it, the correct answer, and the reason it is correct with a pointer to the authoritative source. That third field is what makes the set maintainable: when a policy changes, you can find every affected entry rather than rediscovering them through failures.

Include three categories deliberately. Straightforward questions the agent should get right, which establish the baseline. Edge cases you expect it to handle awkwardly, which show you the shape of degradation. And questions it must refuse, which are the ones teams forget and the ones that catch the most dangerous regressions, because a refusal quietly turning into an answer is invisible to every metric you have.

Score, record the baseline, and set the bar. The bar is a judgement about your risk appetite rather than a number anyone can give you, but it has to exist before the first release, because setting a bar after a failing run is not a bar.

#Phase 6 in detail: the first ninety days

Operating an agent is most demanding immediately after launch, and the cadence should reflect that rather than settling into a steady state on day one.

For the first fortnight, read transcripts daily and expect to change escalation triggers. The triggers written before launch are hypotheses about how people will behave, and they are usually wrong in specific, correctable ways.

For the first month, run the regression set weekly whether or not anything changed, because knowledge and data change without anyone telling you. After that, run it on change and monthly on schedule.

From month two, watch actions per conversation as a trend. A rise means retrieval is degrading, and it will show in the consumption bill before anyone complains about answer quality. That leading indicator is one of the few genuinely early warnings this technology offers, and it costs nothing to watch.

#Where programmes actually slip

Three patterns account for most of the overrun we see.

The first is running grounding and build in parallel to save time, which produces an evaluation set that cannot distinguish an agent regression from a content change. The second is discovering permission debt in phase three, when the remediation should have been scoped in phase one. The third is treating pilot as a countdown rather than a gate, so the two weeks elapse without anyone having read the transcripts, and the exit criterion is met on the calendar rather than on the evidence.

None of those are Agentforce problems. They are delivery problems that this particular technology is unusually good at exposing.

#Running the phases when the date is fixed

Sometimes the date is not negotiable, and refusing to work that way is not useful advice. Two things can compress honestly, and one cannot.

Scope compresses. Fewer intents means less grounding, a smaller regression set and a narrower permission surface, and it is the only lever that reduces every phase at once. A programme under date pressure should cut intents first and keep the gates.

Parallelism compresses, in one specific place: permission discovery can run alongside grounding, because they touch different people and different artefacts. Nothing else in the sequence parallelises safely.

Evaluation does not compress. It is the phase with no visible output, which is why it is the one teams drop, and it is the only phase that protects every month after launch. A deployment shipped without a baseline is not early, it is unmeasurable.

#What actually sets the schedule

Ask three questions and you can estimate this better than any phase-duration table: how many intents, how bad is the knowledge, and how well understood is the sharing model. The first is scope. The second and third are the ones that move a six-week build into a five-month programme, and neither of them is Agentforce work.