Over the past year, the conversation around AI agents in Salesforce has largely focused on capability. Can they resolve cases? Can they draft emails? Can they meaningfully reduce workload? Salesforce’s own ambitions have only accelerated that discussion, with bold targets around scaling agents across the enterprise and embedding them deeper into day-to-day operations.
But while much of the attention has centered on what a single agent can currently do, far less has been said about what happens when organizations move from experimenting with one or two agents to running dozens across teams, clouds, and business processes. We’ve already debated whether the previously claimed 93% accuracy is good enough in isolation for Salesforce, but scale changes the equation entirely.
A 7% margin of error may feel manageable in a contained pilot – once that multiplies across departments and high-volume workflows, it becomes something else entirely. So now the real question turns to what starts to shift operationally and organizationally when AI agents start to behave less like helpful assistants and more like enterprise infrastructure. And more importantly, whether customers are ready for that potential transition.
When Scale Stops Being a Technical Problem
At a small scale – let’s say, an SMB company with less than 200 employees – it’s fair to say that AI agents still feel like a feature. They sit inside a workflow, answer a narrow set of questions, and can be monitored by a team that deployed them. If something goes wrong, it’s quite visible and can be managed if accuracy starts to dip.
This all changes quite quickly, however, when agents begin spreading across an organization. Let’s say your sales team launches one to summarize calls, service deploys another to deflect cases, and marketing experiments with some campaign analysis.
Each case makes sense, per se, but collectively, they introduce interdependence. This is the moment when agents stop behaving like isolated tools – or, as mentioned, a feature – and start acting like infrastructure.
Snowflake recently released a blog post detailing how it scaled its internal GTM AI Assistant to roughly 6,000 users. The thing that stood out wasn’t its usage numbers, but the model behind it to build it. They started with a Minimum Viable Product (MVP), deliberately limited personas, and phased their rollout to protect trust. Quality was the priority, or, as they frame it, “P(-1)” – the non-negotiable baseline before any expansion takes place.
Source: Snowflake.
This is a great example that shows that while prototyping may be straightforward enough, launching a reliable one to thousands of users without eroding confidence is not – and that’s just in a controlled internal environment. Imagine what that would look like in a multi-team Salesforce org with shared objects and automations, where complexity builds up even faster.
This is also where the 93% debate becomes more relevant (if we’re to take Benioff’s words). In isolation, this number sounds great, but at scale, 7% error margins become more exposed, whether that’s through inconsistent records, misrouted cases, or customer-facing confusion.
None of those sounds catastrophic on their own, but problems emerge when they come together collectively.
Understanding Agent Sprawl
As more businesses scale agents, a new term has entered the conversation – “agent sprawl”.
It sounds a bit dramatic, but in reality, it’s quite a predictable outcome when we consider scale. If multiple teams are deploying agents independently – and let’s say they’re trained on different bits of data or prompted slightly differently – duplication, drift, and ultimately, sprawl, are almost guaranteed.
Agents obviously add a level of intelligence, but they don’t remove the need for governance – in fact, it raises the stakes.
We asked SF Ben Technical Content Writer Tim Combridge about who really ‘owns’ AI agents in a multi-team Salesforce org. Tim believes the responsibility has to be shared – comparing it to a new starter at a company.
“Think of an agent as another employee – I hate that analogy, but stick with me!
When someone onboards in your company, multiple people are responsible for different parts of their journey. HR is in charge of general company onboarding, IT is responsible for making sure they have access to devices and systems they’ll need to do their job, and the team leader has responsibility for making sure they have access to processes and information that is relevant to the team so they can do their job.
“This is kind of similar for agents. There will be an element of IT/Salesforce Admin that is responsible for setting them up with the right access and data, and the team will be responsible for making sure that information is up to date, complete, and accurate. There’s a bit of a split, like a human.”
In essence, there are likely different departments that own different defined responsibilities when “taking care” of an agent. Now, this may be something that works at a small scale, but at a larger scale, operational risks might start to sneak in. Not because an agent is inherently flawed in any way, but because this type of governance may not be best suited for proliferation.
A couple of new employees (agents) is manageable. But depending on how large you scale, that responsibility framework is something that can quickly break down, becoming too much to manage.
Agent sprawl, then, isn’t a core problem, but a likely visible outcome of scaling without the correct structure around it.
Where Agent Fabric Fits
All of the issues raised above have been acknowledged by Salesforce itself, which has introduced MuleSoft Agent Fabric in order to deal with the potential coordination challenge.
At a practical level, Agent Fabric is designed to provide a structured layer for how agents access data, share context, and interact with other systems. Rather than each agent operating as a standalone prompt connected to isolated data sources (which we implied may be happening earlier), Agent Fabric introduces:
- Shared contextual grounding
- Standardized access to enterprise data
- Defined orchestration pathways
- Centralized policy controls
The intent, of course, is to reduce fragmentation as agents scale. If multiple agents are operating within the same organization, it’s best that they reference the same data models, respect the same security model, and operate within defined guardrails – giving the structure that’s needed.
There is an argument, however, that it still doesn’t replace the governance we talked about. Agent Fabric can standardize how agents are built, connected, and controlled at a technical level, but it doesn’t decide who owns them, who monitors their performance, or who is accountable when something goes wrong.
It provides the structure needed, but the responsibility for defining roles, setting boundaries, and managing risk still sits with the business using it.
Final Thoughts
It’s quite clear that agents are quickly evolving and entering real workflows, touching real data, and influencing real decisions. But with this, they’re also exposing how mature a company’s governance, data hygiene, and multi-team coordination are when reaching a larger scale.
More responsibility is now shifting toward business planning to scale their agents to be structured and perfect their governance, as Snowflake seemingly has. Otherwise, agent sprawl could become a wide-scale problem for Salesforce orgs in the future.
