# What separates an Agentforce rollout that is still running in six months > Most agent projects do not fail loudly. They get quietly narrowed, then switched off, and nobody writes the post mortem. - Source: https://synconai.com/insights/agentforce-implementation-best-practices - Publisher: SynconAI (https://synconai.com) - Desk: AI & Agentforce - Author: SynconAI Architecture Team, Solution & technical architecture - Published: 5 January 2026 - Updated: 29 August 2026 - Reading time: 15 minutes - Topics: Agentforce, AI, Implementation, Grounding, Governance ## Key points - An agent is only as good as the narrowest of five things: scope, grounding, permissions, escalation and evaluation. The weakest one sets the ceiling. - Score readiness before you scope a budget. A dimension at level one will not be fixed by a better prompt. - Your sharing model is the AI security boundary. Nothing about agents changes that, and most teams discover it late. - If you cannot tell next month whether answers got worse, you do not have a deployment, you have a demo that stayed on. --- 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](https://www.salesforce.com/agentforce/agent-builder/), and the weakest of the five sets the ceiling for the whole deployment. ::: takeaways The five dimensions are scope, grounding, permissions, escalation and evaluation. Score each one honestly before you scope a budget. A dimension sitting at level one is not a prompt problem and will not be fixed by a better prompt. ::: ## 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. | Dimension | Level 1: not ready | Level 2: pilot ready | Level 3: production ready | | --- | --- | --- | --- | | **Scope** | "Answer customer questions" | Named intents, success defined per intent | Bounded intents with a written out-of-scope list the agent enforces | | **Grounding** | Answers live in people's heads and old email | Knowledge exists, quality is uneven, some contradictions | Single authoritative source per intent, ownership named, review cadence running | | **Permissions** | Nobody can state what the agent will see | Sharing model understood, agent runs as a defined user | Least privilege verified by test, and a documented blast radius | | **Escalation** | Handover is "it says sorry" | Escalation path exists, triggers are informal | Triggers defined, routed, and the handover carries context | | **Evaluation** | Judged by whether the demo worked | Sampled review after launch | A scored regression set run before every change, with a quality bar that blocks release | 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. ::: tip Score the org you have, not the one that will exist after the project. A dimension scored on planned remediation is a dimension scored at three that behaves like a one, and the whole point of the exercise is to surface the work rather than assume it. ::: ## 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. | Dimension | At level 1, do this first | At level 2, close this gap | | --- | --- | --- | | Scope | Write the intent list and the refusal list; get both signed | Define what success looks like per intent, in words an operator would accept | | Grounding | Identify one authoritative source per intent; retire the contradictions | Name an owner per source and set a review cadence that actually runs | | Permissions | Produce a current statement of who can see what | Decide the running user deliberately, then test its reach against real records | | Escalation | Define the triggers, including the non-confidence business rules | Route the escalation and make it carry context, then test the handover | | Evaluation | Collect fifty real questions with known-good answers | Score them, record the baseline, and set the bar that blocks a release | 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](https://www.salesforce.com/data/) 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](/insights/agentforce-grounding-checklist). ## 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. ::: warn If you cannot currently produce a list of who can see what in your org, you cannot answer what an agent will expose. Agent projects routinely surface permission debt that has been accumulating for years, and the clean-up lands on the critical path. ::: 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](https://www.salesforce.com/platform/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](/insights/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. ::: note Evaluation is also the dimension that makes the cost model legible. Agentforce consumption is metered per action, and Salesforce publishes the rate card and buying models on its [pricing page](https://www.salesforce.com/agentforce/pricing/). An agent that retries, loops or over-retrieves is both worse and more expensive, and you will only see that if you are measuring. Figures change, so check the current rate card rather than any third-party summary. ::: ## 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. | Salesforce provides | You still own | | --- | --- | | The reasoning layer and the agent runtime | Which questions the agent is allowed to answer | | Retrieval over the sources you connect | Whether those sources are correct, current and singular | | Enforcement of the permission model | The permission model itself, and whether it says what you think | | The mechanism to invoke actions | What each action does, and whether it is reversible | | Consumption metering and reporting | Whether the answers are good, and whether they got worse | 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. ::: warn Knowledge changes are the governance gap we find most often. Content teams edit articles for entirely good reasons, unaware that an agent now reads them, and answers change with no review and no record. Whatever else you govern, put agent-read sources behind the change gate. ::: ## 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. | Dimension | Score | Why | | --- | --- | --- | | Scope | 2 | Intents named and sensible, but no refusal list existed | | Grounding | 1 | Four hundred knowledge articles, no ownership, visible contradictions on refunds | | Permissions | 2 | Sharing model understood by two people, never documented, never tested | | Escalation | 2 | A path existed for the phone channel, nothing defined for chat | | Evaluation | 1 | No baseline, no regression set, success defined as "the demo worked" | 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](/insights/how-to-implement-agentforce). If you are still choosing what to point an agent at, the scoring for that is [Agentforce use cases that survive a business case](/insights/agentforce-use-cases), 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](/insights/agentforce-vs-salesforce-automation) 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](/insights/agentforce-pricing-and-implementation-cost) 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](/insights/agentforce-grounding-checklist), and if permissions came out low, the pattern behind that is set out in [permission set debt](/insights/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.