A support agent picks up a call about a failed order. Before they’ve said a word, the case history, the customer’s last three interactions and a draft summary of the account are already sitting on screen. That’s Agentforce doing its job well: invisible, fast, and out of the customer’s way. Ten minutes later the same customer is angry about a refund policy exception, and the agent needs to read the room, bend a rule slightly, and say something that sounds human. That’s a different job entirely, and it’s not one Agentforce should be doing.
I’ve spent years inside contact-centre Service Cloud orgs, and the pattern with Agentforce is becoming clear fast: the technology is genuinely good at a specific band of work, and genuinely bad at the work either side of that band. Knowing where that line sits matters more than any feature list Salesforce ships this year.
Where Agentforce earns its place
The strongest use cases I’ve seen all share one trait: they’re information-retrieval and drafting problems, not judgment problems.
Summarising before the agent needs to ask
Case summarisation is the easiest win in the whole platform. An agent opening a case with eleven prior interactions, three transfers and a product return doesn’t need to read all of that. They need the three facts that matter right now. Agentforce reading case history and surfacing a two-line summary saves real seconds on every single call, and seconds compound across thousands of calls a week.
First-draft replies on routine requests
Password resets, order status, standard policy questions: these have one correct answer and no emotional complexity. Letting Agentforce draft the reply and having the agent review and send it is faster than typing from scratch, and it’s lower risk than it sounds, because the agent is still the one hitting send.
Routing and triage
Classifying an inbound case by intent, urgency and the right queue is exactly the kind of pattern-matching large language models are built for. I’ve watched Omni-Channel routing improve meaningfully once case classification stopped depending on a customer picking the right dropdown option on a web form.
Where it should stay out of the way
The failure cases I’ve seen cluster around three things: emotional nuance, irreversible actions, and genuine edge cases the model has never seen framed quite that way.
Anything with an angry or vulnerable customer
An agent can hear tone shift in someone’s voice and adjust. A model reading transcript text is working from a much thinner signal. Handing de-escalation, retention conversations, or anything touching a customer in genuine distress to an autonomous agent is a bad trade even when the model gets the facts right, because the facts were never the hard part.
Actions that can’t be undone
Refunds above a threshold, account closures, data deletion requests: give Agentforce a narrow, well-tested action for these and it’ll happily execute it exactly as scoped. The risk isn’t the model being wrong occasionally. It’s that “occasionally” compounds fast when the action is irreversible and the volume is high. I treat any Apex action tied to money or data loss as something a human approves, full stop, no matter how good the surrounding prompt is.
The exception that breaks the pattern
Every contact centre has cases that don’t fit the normal shape: the customer who’s a VIP but isn’t flagged as one, the policy exception that was agreed on a call six months ago and never got written down, the integration that silently failed last Tuesday and left three systems disagreeing about the truth. Agentforce has no way to know what it doesn’t know. A human agent, at minimum, knows when something feels off.
A rough framework for the line
When I’m scoping where Agentforce should sit in a Service Cloud build, I ask three questions about the task:
- Is there a single correct answer, or does the right answer depend on reading a person?
- Can the action be reversed cheaply if the model gets it wrong?
- Has this exact shape of request happened often enough that the model has real pattern density to draw on?
Three yeses, and Agentforce can probably run with real autonomy. Two yeses, give it a supporting role with a human in the loop. One or zero, keep it out of the workflow entirely and spend the budget somewhere else.
What this means for the build
Practically, this changes how I scope Agentforce actions. I design the narrowest possible action for each task rather than one broad “handle the case” agent. A tight action that looks up order status is easy to test, easy to monitor, and easy to trust. A broad action that can also issue refunds, update addresses and escalate cases is none of those things, even if it demos beautifully.
It also changes where I put the guardrails. Input validation on every Apex action an agent can call isn’t optional, because the agent will eventually call it with something you didn’t anticipate. And every action above a certain blast radius gets a human approval step before anything executes, not because I distrust the model specifically, but because that’s the same discipline I’d apply to any automation touching customer money or customer trust.
None of this is an argument against Agentforce in a contact centre. It’s an argument for being precise about which parts of the job it’s actually solving. The agents who do this well in six months won’t be the ones who gave Agentforce the most access. They’ll be the ones who worked out, task by task, exactly where the model was reliable and designed everything else around a human doing what humans are still better at.
Leave a Reply