Why Most Agentforce Projects Stall — and the Pattern Behind the Agents That Actually Ship
Salesforce told everyone Agentforce would change their business. The headline numbers back the hype — but the gap between building an agent and shipping one that survives production is where most projects quietly stall. Here’s the full breakdown, from a team that builds these for a living.
The promise vs. the reality
The headline numbers are real: by the end of FY26, Salesforce had delivered 2.4 billion Agent Work Units, growing 57% in a single quarter, and within three days of Dreamforce attendees had built more than 10,000 AI agents. The demand is not in question.
What is in question is the gap between building an agent and shipping one that holds up in production. We’ve now delivered a number of these for enterprise clients, and the agents that fail almost never fail for the reason people expect. It’s rarely the model. It’s almost always the foundation underneath it.
Why agents stall: the three real failure modes
1. Bad data — the agent is only as smart as the records it reads
An AI agent grounded in your CRM inherits every flaw in that CRM. Duplicate accounts, half-filled fields, stale opportunity stages, inconsistent picklist values — the model doesn’t see “messy data,” it sees ground truth. So it answers confidently, and it answers wrong. The most common root cause of a failed pilot isn’t the agent’s reasoning; it’s that nobody cleaned the house before inviting the agent in.
Before you scope a single agent, audit the objects and fields it will actually touch. Deduplicate, enforce required fields, and standardize the values it will reason over. Grounding quality is the single biggest lever on output quality.
2. Over-permissioning — quiet, expensive, and hard to undo
It’s tempting to give an agent broad access so it can “handle anything.” That is exactly how a single agent ends up modifying thousands of records before anyone notices something is off. Agents act at machine speed; a permission mistake compounds faster than a human ever could.
Treat agent permissions the way you’d treat a new integration user: least privilege, scoped to the specific objects and actions the job requires, with guardrails on write operations. An agent that can read everything but only write to a narrow, reviewed surface is far safer than one with a generous profile and good intentions.
3. No baseline — you can’t prove a win you never measured
Teams run a “pilot,” skip capturing before-metrics, and then can’t demonstrate impact when the budget conversation comes around. So the project quietly dies — not because it didn’t work, but because nobody could prove it did. This is the most avoidable failure of the three.
Pick one measurable job and capture the baseline before you deploy: tier-1 ticket deflection rate, average handle time, hours spent on account research, lead response time. Whatever the agent is meant to improve, measure it the week before go-live so you have a number to compare against.
What winning agents have in common
The agents that succeed are, frankly, boring. They share four traits:
- Narrow scope. One job, clearly defined, not “handle customer service.”
- Clean grounding data. The records behind the agent are trustworthy before the agent goes live.
- One measurable outcome. Deflect tier-1 tickets, prep account summaries, qualify inbound leads — something you can put a number on.
- Tight permissions. Least-privilege access with reviewed write paths.
Start smaller than feels impressive. Ship one agent that does one thing well, measure it honestly, and expand from a position of proof rather than hope.
Where Claude and MCP fit in
One of the more useful recent shifts is the Model Context Protocol (MCP) becoming a first-class way to connect agents to tools and data. With Salesforce’s hosted MCP support, an Agentforce agent — or an external model like Claude — can call into governed Salesforce context and actions through a standard interface instead of bespoke, brittle integration code.
The practical benefit for builders is governance and speed at the same time: you expose a defined set of tools and data through MCP, and the agent works against that contract. It doesn’t remove the need for clean data or scoped permissions — if anything it makes those disciplines more important, because the agent can now reach more with less friction. Used well, it’s the difference between an agent that’s wired together by hand and one that’s built on a maintainable foundation.
A simple starting framework
If you’re standing up your first Agentforce agent this quarter, this is the sequence we use:
- Pick one narrow job with a clear, measurable outcome.
- Clean the data the agent will ground on — dedupe, fill required fields, standardize values.
- Scope permissions to least privilege, with guardrails on writes.
- Capture a baseline the week before launch.
- Ship, measure, and only then expand.
The companies winning with Agentforce aren’t the ones who built the most ambitious agent first. They’re the ones who shipped a small, reliable agent, proved the number, and earned the right to do more.
Shrine Software Services builds enterprise AI agents and Salesforce, Agentforce, Zoho, Java, and React solutions for clients across the US, UK, Australia, and India. If you’re scoping your first agent — or trying to rescue a stalled one — let’s talk.