Why Agentforce Pilots Fail: 9 Data, Testing, Governance Gaps

TLDR

• The model is rarely the problem. The org it was pointed at usually is.
• Nine gaps account for most stalled pilots: data quality, sharing model, testing, rollback and audit, approval ownership, automation collision, success metrics, consumption governance, and admin involvement.
• Every one of these is a pre-launch fix. Post-launch they cost more and burn credibility you only get once.
• Score yourself against the 20-point checklist near the end before you commit a budget.
• Agents that keep a human in the approval path ship faster, because the review conversation is shorter.

Related reading: the architecture question is covered separately in does Agentforce require Data Cloud, and the broader list of delivery obstacles is in 10 Agentforce implementation challenges. This post is specifically a pre-mortem for the pilot stage.

The Pattern

A pilot gets approved with genuine enthusiasm. A use case is chosen, an agent is built in a sandbox, and it demos well. Then it meets the production org.

The answers get inconsistent. Someone notices the agent surfaced a record that user should not have seen. A test action updates 40 records and nobody is quite sure how to put them back. The admin team, who first heard about the project three weeks ago, starts flagging that it collides with a Flow they maintain. Six weeks in, the pilot is quietly parked as "not ready", and the organisational conclusion becomes "the AI wasn't good enough".

The AI was fine. The pilot was pointed at an org that had never been assessed for whether it could be safely acted on by software.

What follows are the nine gaps we see repeatedly, what "good" looks like for each, and how a services partner closes it. The through-line: none of these are model problems, and none of them are solved by switching vendors.

Gap 1: Data Quality Nobody Measured

What goes wrong. Duplicate accounts mean the agent summarises one of three versions of a customer. Stale ownership means it shows the wrong pipeline to the wrong rep. Sparsely populated fields mean it reasons from absence and fills the space with plausible generalities. Free-text where a picklist belongs makes any aggregation unreliable.

The failure mode is not obviously wrong answers. It is subtly wrong answers, delivered confidently, which is far more corrosive to trust. Users cannot tell which answers to check, so they check none of them, or they stop using it.

What good looks like. You have measured duplicate rate on the objects the agent touches. Ownership reflects the current territory model. Fields the agent grounds on are populated above 90% on relevant records. Picklists are consolidated. Crucially, you fixed the intake process that created the mess, so it does not reappear next quarter.

How a partner closes it. An audit that quantifies rather than describes: duplicate rate per object, field population rates, ownership accuracy against the current model, and a specific remediation list. Then the remediation itself, done with the admin team rather than around it. This is where an AI agent genuinely adds capacity, because the repetitive find-and-fix passes across tens of thousands of records are exactly the work that never gets prioritised when one admin is also handling a ticket queue. A person still approves the changes before they land.

Gap 2: A Sharing Model Nobody Reviewed

What goes wrong. This is the one that turns a stalled pilot into an incident. Agents operate in a permission context, and if that context is broader than the requesting user's, the agent becomes a data exfiltration path with a friendly interface. A rep asks a general question, and the agent helpfully includes figures from an account they have no rights to.

Most mature Salesforce orgs carry years of accumulated sharing rules, role hierarchy exceptions, and permission set assignments that nobody has fully mapped. Adding an agent on top of an unmapped model is how organisations discover their model was broken all along.

What good looks like. The agent's running context is explicitly documented. Field-level security is reviewed for every object in scope. You have tested with real user personas, including a deliberately low-privilege one, and confirmed the agent respects the boundary. Sensitive fields are excluded from grounding by design, not by hoping the prompt says no.

How a partner closes it. A permissions audit that maps effective access rather than intended access, then persona-based testing against the agent before launch. If your org still runs on profiles rather than permission sets, that migration usually belongs in scope too, and we wrote up the approach in the profiles to permission sets migration guide.

Gap 3: No Testing Before Actions Go Live

What goes wrong. Teams test whether the agent responds well. They do not test whether it acts correctly. Those are different problems. Conversation quality is a language question; action correctness is a systems question, with side effects.

An agent that answers 95% of questions well and takes the wrong action 5% of the time is not a 95% success. If it writes to records, that 5% is a data integrity problem accumulating quietly in production.

What good looks like. A test set of real scenarios with known-correct outcomes, covering the ordinary path, the ambiguous path, and the adversarial path. Every action tested for what it does when inputs are missing or malformed. Regression testing when prompts or topics change, because a prompt edit is a code change with no compiler to catch you.

How a partner closes it. Building the scenario library with your team, since only they know the genuinely ambiguous cases. Salesforce's Testing Center is a useful part of this but not the whole of it, a distinction worth understanding before you rely on it: see Agentforce Testing Center vs real testing.

Gap 4: No Rollback Path or Audit Trail

What goes wrong. The agent updated 200 records overnight. Some of those updates were wrong. Which ones? Made when? Based on what reasoning? If the answer involves reconstructing intent from field history on a record-by-record basis, you do not have a rollback path, you have an archaeology project.

This gap is what makes risk committees say no, and they are right to. Standard field history tracking was designed for human-paced change, not for an automated actor working at volume.

What good looks like. Every agent-initiated change is attributable: which agent, which conversation, which reasoning, which approval. Bulk changes can be reversed as a set. There is a documented kill switch that a named person can trigger without a deployment. Audit records survive long enough to satisfy whoever asks.

How a partner closes it. Designing the audit and reversal layer as part of the build rather than after the first incident, including snapshot-before-write for bulk operations and a tested rollback procedure. Tested, not documented. A rollback plan nobody has executed is a hypothesis.

Gap 5: Nobody Owns the Approval

What goes wrong. "The agent will suggest changes and someone will approve them" survives the design review because it sounds reasonable. Then the agent produces 60 suggestions a day. Sales ops assumes the admin reviews them. The admin assumes sales ops does. Within two weeks, approvals are rubber-stamped in bulk, which is functionally the same as having no approval step, except now it is documented as governed.

What good looks like. A named human owner per action type, not a team. A volume estimate that a real person can absorb, checked against their actual workload. A tiered model: low-risk changes flow through with logging, higher-risk changes need explicit sign-off, and the tiers are defined by blast radius rather than by convenience. An escalation path when the owner is unavailable.

How a partner closes it. Running the approval design as an operations question rather than a technical one, sizing the review load before launch and tuning agent scope so the queue stays humane. If the only way to make approvals workable is to approve nothing, the agent's scope is wrong.

Gap 6: Collision With Existing Automation

What goes wrong. The agent updates a field. That fires a Flow. The Flow updates a related record. That fires a process that reassigns ownership. Now the agent, asked to make a small change, has triggered a cascade nobody modelled. In orgs with years of layered automation, this is the norm rather than the exception.

Worse, the interaction can be non-deterministic. Order of operations between overlapping automations produces intermittent results, which are the hardest kind to diagnose and the fastest way to lose confidence in a pilot.

What good looks like. An inventory of existing automation on every object in scope, with trigger conditions mapped. Known collision points either resolved or explicitly excluded from agent scope. Testing that exercises the full downstream cascade, not just the immediate write.

How a partner closes it. An automation inventory as a standard pre-flight step. This is usually the moment a technical debt audit earns its cost, because most orgs discover overlapping or dormant automation they had forgotten. Race conditions between Flows deserve particular attention: we covered detection in how to detect Salesforce Flow race conditions.

Gap 7: No Agreed Definition of Success

What goes wrong. The pilot launches with a goal like "improve admin efficiency". At review time, nobody can say whether it worked. In the absence of evidence, opinion fills the gap, and the loudest opinion is usually from whoever had the worst individual experience.

Pilots without a metric do not fail. They fail to conclude, which is worse, because the budget is spent and the organisation learned nothing transferable.

What good looks like. One or two primary metrics with a measured baseline captured before launch. A defined measurement window. A pre-agreed threshold for continue, adjust, or stop. Someone accountable for reporting the number.

How a partner closes it. Insisting on baseline capture during scoping, when it is cheap. A partner who does not ask what you will measure is planning to be judged on vibes, which suits them better than it suits you.

Gap 8: Ungoverned Consumption

What goes wrong. Agentforce consumption is metered. A badly scoped agent that retrieves more context than it needs, or retries on failure, or gets embedded in a high-traffic surface, can generate spend that nobody notices until the invoice. The pilot then gets cancelled on cost grounds even though the use case was sound.

What good looks like. A forecast built from expected conversation volume and actions per conversation, with a stated margin of error. Alerting at defined thresholds. A hard limit for the pilot period. Someone who checks the number weekly.

How a partner closes it. Forecasting during scoping and instrumenting monitoring before launch, not after. The unit economics and rate structure are broken down in the Agentforce pricing guide, and the surrounding project cost in Agentforce implementation cost in 2026.

Gap 9: The Admin Team Was Told, Not Involved

What goes wrong. The pilot is scoped by leadership with a vendor. The admin team, who know where the bodies are buried in the org, are briefed once and asked to support it. They are the people who will get the tickets when it misbehaves and who were given no say in scope.

Sometimes this surfaces as passive resistance. More often it surfaces as something simpler and more damaging: the people who could have told you about the three known data problems and the fragile Flow were never asked.

There is also a legitimate fear to address directly. If the project is framed, even implicitly, as reducing the need for admin headcount, you have given the most knowledgeable people in the room a reason to want it to fail. That framing is also just wrong on the merits. Agents extend the capacity of an admin team into work that never gets done, the audit passes, the cleanup backlogs, the documentation. They do not absorb the judgment calls, the stakeholder negotiation, or the architecture decisions, and those are most of the job.

What good looks like. Admins in the scoping conversation from the start, with real influence over which use case goes first. The agent's remit described in terms of capacity added. Admins own the agent's configuration after handover, with the documentation and training to do it.

How a partner closes it. Structuring delivery so the admin team is a participant, and building the handover into the plan rather than the invoice. The framing question is worth confronting directly, and we did: will AI replace Salesforce admins.

The 20-Point Readiness Scorecard

Score one point per yes. Be strict: "we intend to" is a no.

Data (1 point each)

1. Duplicate rate is measured on every object the agent will touch.
2. Ownership data matches the current territory or assignment model.
3. Grounding fields are populated on more than 90% of relevant records.
4. Picklists in scope are consolidated, with no free-text equivalents in active use.
5. The intake process that caused known data issues has been fixed.

Permissions (1 point each)

6. The agent's running permission context is documented.
7. Field-level security is reviewed for all in-scope objects.
8. The agent has been tested against a deliberately low-privilege persona.
9. Sensitive fields are excluded from grounding by configuration.

Testing (1 point each)

10. A scenario library exists with known-correct outcomes.
11. Ambiguous and adversarial inputs are covered, not just the happy path.
12. Every action is tested for missing or malformed input.
13. Prompt and topic changes trigger regression testing.

Governance (1 point each)

14. Every agent-initiated change is attributable to agent, conversation, and approval.
15. Bulk changes can be reversed as a set, and the procedure has been executed in a sandbox.
16. A named person can trigger a kill switch without a deployment.
17. Each action type has a named human approver with a realistic review volume.

Operations (1 point each)

18. Existing automation on in-scope objects is inventoried and collisions resolved.
19. A baseline for the success metric was captured before launch.
20. Consumption is forecast, alerted, and capped for the pilot period.

Reading your score

• 17 to 20. Ready. Proceed and keep the scorecard as your launch gate.
• 12 to 16. Close. Identify the gaps, fix them, then launch. Two to four weeks of work, typically.
• 7 to 11. Not ready. Launching here produces the pattern described at the top of this post. Remediate first.
• 6 or below. The org is the project, not the agent. Fix the foundation and the agent build gets faster and cheaper as a side effect.

Sequencing That Works

Weeks 1 to 2, assess. Data quality, permissions, automation inventory across the objects in scope. Output is a scored gap list, not a slide deck.

Weeks 3 to 6, remediate. Fix what the assessment found. Capture the success baseline while you are in there.

Weeks 5 to 8, build with governance. Agent build, with audit, rollback, and approvals designed in from the first sprint rather than retrofitted.

Weeks 7 to 9, test. Scenario library, persona testing, action testing, cascade testing.

Weeks 9 to 12, controlled launch. One team, capped consumption, weekly review against the baseline, kill switch tested and owned.

The build is not the long pole. Assessment and remediation are, and skipping them is precisely what produces the stalled pilots this post is about.

Where We Fit

Clientell runs Salesforce services with an AI agent option, which means we spend most of our time inside orgs that were built by other people over several years. That is the vantage point behind this list. The nine gaps are not hypothetical risks, they are the things that come up in assessments.

Concretely, what we do: audit the org against the scorecard above and give you the score with evidence, remediate the data and permission issues found, build the agent with audit trail and rollback as first-class requirements, construct the test library with your team, and hand it over with documentation your admins can maintain. The agent capability adds throughput to your existing team on the repetitive work, with a human approving anything that writes. We are not proposing you need fewer admins, and if a vendor is proposing that, ask them who owns the rollback.

If you want the score before you commit budget, start with the Agentforce readiness audit. If the data block is where you already know you are weak, the Salesforce data quality audit is the narrower starting point. Either produces a written findings document that is useful in any vendor conversation. To talk it through, book a demo.

Frequently Asked Questions

What percentage of Agentforce pilots fail? There is no reliable published figure, and be sceptical of vendors quoting one. What is consistent in practice is the failure pattern: pilots stall on data quality, permissions, testing, and governance rather than on model capability.

Should we pilot in production or a sandbox? Build and test in a sandbox with representative data, then run a controlled production pilot with one team, capped consumption, and a tested kill switch. Sandbox-only testing misses the data quality and automation collision problems that cause most failures.

How long should an Agentforce pilot run? Long enough to measure against a baseline, which usually means six to eight weeks of real usage. Shorter than that and you are measuring novelty.

Can we skip remediation and fix data as we go? You can, but the pilot then measures your data quality rather than the agent's usefulness, and the organisation will draw a conclusion about AI from a test that was never about AI.

Does keeping a human approver defeat the point? No. It changes the unit of work from doing to reviewing, which is where the throughput gain lives. It also shortens security review substantially, which usually gets the agent live faster than a fully unattended design would.

What is the single highest-value thing to fix first? Duplicate resolution and ownership accuracy on the objects in scope. They are the most common root cause of subtly wrong answers, and subtly wrong answers are what destroy user trust.