For about twenty years, CRM has mostly been a very expensive filing cabinet.

That sounds harsh, but think about what the average sales or service org actually does with theirs. Reps log calls. Managers pull reports. Admins wire up validation rules so people log calls in a slightly more consistent way. The system records what happened. It rarely does anything.

Agentforce is interesting because it attacks that assumption directly. Instead of a workflow that fires when a checkbox flips, you get an agent that reads the situation, decides what to do, and does it, inside the same platform where your customer data already lives. That’s a different category of software, even though it ships under a familiar logo.

The difference between automation and agency

Traditional Salesforce automation is deterministic. Flow, Process Builder before it, Apex triggers, they all follow the same shape: when this condition is true, perform these steps. Someone had to imagine the condition in advance. If reality didn’t match the imagination, nothing happened, or the wrong thing happened.

Agentic automation flips the order. You give the agent a job, a set of instructions, and a toolbox of actions it’s allowed to take. It figures out the sequence at runtime.

A quick example. A customer emails about a delayed order. Under the old model, you’d need an email-to-case rule, a routing rule, an entitlement check, maybe an auto-response template, and a queue. Five configurations, all brittle. An Agentforce service agent reads the email, checks the order record, sees the shipment is late, checks the refund policy in your knowledge base, issues a partial credit if it’s within the threshold, and escalates if it isn’t. One job description instead of five rules.

The word people keep reaching for is “reasoning.” I’d be careful with that. What’s really happening is that the model is choosing among actions you defined, grounded in data you exposed to it. The intelligence is real, but the boundaries are yours. That distinction matters enormously once you start rolling it out, and it’s usually the thing that separates a working deployment from an expensive demo.

Why does this push past CRM

Here’s the part I think gets underplayed. Agentforce is being marketed as a CRM feature, but the moment an agent can call an external system through MuleSoft or an Apex action, it stops being a CRM feature.

Consider what an agent can reach:

• Data Cloud, which already unifies records from your ERP, your data warehouse, and your product telemetry
• Flows and Apex, meaning any business logic you’ve ever written, are now callable tools
• External APIs through MuleSoft, which is to say most of your stack
• Slack, where a lot of enterprise work actually gets decided

Once those four are in play, the agent isn’t managing customer relationships. It’s operating your business processes. Procurement, onboarding, inventory reconciliation, contract review, none of that is CRM work, and all of it is now reachable from the CRM.

That’s the shift. The system of record quietly became a system of action. Most organisations haven’t updated their mental model yet, and it shows up in how they scope projects: they staff Agentforce like a CRM upgrade when it’s closer to an integration and governance program.

The parts nobody puts in the demo

Demos are frictionless. Production is not. A few things reliably bite teams in the first ninety days.

Your data is worse than you think. Agents ground their answers in what you give them. Duplicate accounts, stale contacts, three competing definitions of “active customer,” the agent will confidently act on all of it. Deterministic automation fails loudly when data is bad. Agents fail quietly, which is worse. Data cleanup isn’t a nice-to-have here; it’s the entry fee.

Permissions become a security boundary, not an inconvenience. An agent inherits a running user’s access. If that user can see everything, the agent can act on everything. This is where a lot of organisations quietly discover that their permission model was never really designed; it just accumulated. Working through this properly is where an experienced Salesforce Consulting company usually earns its fee, not by writing agent instructions, but by sorting out the profiles, permission sets, and sharing rules that determine what the agent is even allowed to touch.

Instructions are a skill. Writing a topic and its instructions feels like writing a Jira ticket, but it behaves more like writing a policy. Vague instructions produce vague behaviour. “Help the customer with their refund” is not an instruction. “Check the order date; if it’s within 30 days and the item is unopened, issue a full refund; if it’s 31-60 days, offer store credit; otherwise, escalate to a human” is an instruction.

Testing is genuinely hard. You can’t unit-test a non-deterministic system the way you test an Apex class. You need evaluation sets, sampling, and a human review loop for at least the first few months. Teams that skip this find out about their failures from customers.

What good implementation actually looks like

The pattern I keep seeing is that work is boring, which is usually a good sign.

Start with one narrow, high-volume, low-risk process. Order status. Password resets. Appointment rescheduling. Something where the worst-case failure is a mild annoyance rather than a compliance incident. Instrument it heavily. Let humans review a meaningful sample of the agent’s decisions for a few weeks. Fix the instructions. Then expand.

The teams that struggle tend to do the opposite: they pick the flashiest process, wire the agent to eight systems, and launch to a segment that includes their largest accounts.

There’s also a build-versus-buy question hiding in here. Standard actions and prebuilt topics will cover more ground than you’d expect. But the moment your process touches a bespoke object model or a legacy system with an ugly API, you’re back to writing Apex, and that’s where partners offering Salesforce Development Services tend to get pulled into custom actions, MuleSoft connectors, and the unglamorous integration work that makes the agent useful rather than merely impressive.

Product teams at firms like DianApps have been fairly open about this, noting that most of the effort in an agentic rollout lands on data readiness and integration rather than on the agent itself. That matches what I’ve seen. The agent is the easy part. Everything underneath it is the project.

The economics change too

One more thing worth flagging, because it changes how you should think about ROI.

Classic Salesforce licensing is per seat. You pay for humans. Agentforce is consumption-based you pay per conversation or action. That sounds like a detail until you model it out. Deflecting 60% of tier-one support tickets doesn’t reduce your Salesforce bill; it shifts it from a predictable per-seat cost to a variable per-action cost that scales with customer volume.

That isn’t necessarily bad. It might be much cheaper. But it’s a different financial shape, and finance teams who signed off on a headcount-reduction business case sometimes get an unpleasant surprise when the consumption invoice arrives during a seasonal spike. Model the peak, not the average.

So is it actually a shift, or just good marketing?

Both, honestly. There’s a lot of noise around agentic AI right now, and a fair amount of it is rebranded chatbot.

But the underlying change is real, and it’s structural rather than cosmetic. When your CRM can read unified data, decide on a course of action, execute it across connected systems, and escalate when it’s unsure, the label “CRM” has stopped describing the thing. It’s an automation layer that happens to sit on customer data.

The organisations that get value out of it in the next two years probably won’t be the ones with the most sophisticated agents. They’ll be the ones who cleaned their data, tightened their permissions, and picked processes narrow enough to actually measure.

That’s an unsexy conclusion. It’s also, I’d bet, the accurate one.

FAQ

Is Agentforce just a chatbot with better branding?

No. A chatbot answers questions from a script or a knowledge base. Agentforce agents take actions, updating records, calling APIs, triggering flows, and choosing which actions to take based on the situation. The difference is between retrieval and execution.

Do we need Data Cloud to use it?

Not strictly, but you’ll get much less out of it. Agents ground their responses in available data. If that data is trapped in systems Salesforce can’t see, the agent works with a partial picture and behaves accordingly.

How much control do we have over what the agent does?

Complete control over the action set. The agent can only invoke actions you’ve explicitly defined and permitted. What you don’t control deterministically is the sequence it chooses, which is exactly why clear instructions and careful permissioning matter so much.

What’s a realistic first project?

A single high-volume, low-risk process with clean data and a clear success metric. Order status lookups, appointment scheduling, and basic account updates are common starting points. Anything involving money movement or regulated decisions should wait until you’ve built confidence and a review loop.