Give Agentforce its own queue and something changes that most teams don’t plan for. It’s not the AI accuracy, and it’s not the setup. It’s the moment a case sits in a queue with no human attached to it, waiting on a decision an agent made, and nobody in your support team can immediately tell you why that decision got made.
Agentforce Coworker (the setup where an agent operates as a routable teammate, with its own queue, its own skill set and its own workload) is a genuinely different operating model from Agentforce as a chat widget bolted onto a help page. A chat widget fails politely: the customer gets a bad answer, or no answer, and either way a human was never that far from the interaction. A Coworker in a queue is making the same kind of call your Tier 1 agents make: accept this case, resolve it, escalate it, or sit on it. The difference is nobody’s watching over its shoulder in real time.
What actually changes when the agent has a queue
Three things shift the moment you give Agentforce a real queue instead of a chat window.
Routing logic has to treat the agent as a resource, not a fallback
Most orgs I’ve worked in built Omni-Channel routing around humans: skills, capacity, presence status. Bolting an AI queue onto that model as an afterthought usually means it only picks up the leftovers nobody wants, which defeats the point. If Agentforce Coworker is meant to carry real volume, your routing rules need to know what it’s actually good at (password resets, order status, simple entitlement checks) and route those cases to it first, not last. That’s a configuration change, but it’s also a trust decision your contact-centre lead has to sign off on, and it’s worth writing down explicitly rather than letting it drift out of whatever the default routing config happened to do.
Escalation needs a real contract, not a vibe
When a human agent is stuck, they know it, and they ask for help or bump the case up. An AI agent doesn’t have that instinct unless you build it in. I’ve seen Agentforce actions configured with no explicit escalation condition at all, just an implicit assumption that it’ll “figure out” when it’s out of its depth. It won’t, reliably. You need hard boundaries: confidence thresholds, specific topics it’s never allowed to resolve (refunds over a dollar value, anything touching a complaint flagged as a formal grievance), and a clean handoff that carries full context to the human who picks it up. Build that contract before go-live, not after the first case that goes sideways.
Case ownership and reporting assume a person on the other end
Most Salesforce orgs have years of reports, dashboards and SLA rules built around the assumption that a case owner is a person with a name, a manager and a performance conversation. Put Agentforce in the owner field and a surprising number of those reports quietly break or mislead: average handle time calculations that don’t account for the agent resolving in nine seconds, SLA breach alerts that fire because nobody built an exception for machine-resolved cases, team leaderboards that either exclude the AI entirely or compare it unfairly against a junior agent six months into the job. None of this is hard to fix. All of it needs to actually get fixed before the dashboards go in front of a steering committee.
The guardrail that matters most: what the agent is allowed to decide alone
The single highest-leverage design decision in a Coworker deployment is drawing the line between “the agent resolves this and closes the case” and “the agent prepares the answer, a human approves it.” Too many teams treat this as a binary switch for the whole queue. It isn’t. It’s a per-topic decision, and it should be reviewed on a cadence, not set once at launch and forgotten.
A practical starting point I’d recommend to a client: anything reversible, low-value and well-bounded (status lookups, basic troubleshooting steps, scheduling) gets full autonomy from day one. Anything irreversible, financial, or legally sensitive goes through human approval for the first few months regardless of how confident the agent seems in testing. You loosen that over time based on actual production accuracy, not sandbox demo performance, which almost always looks better than it should.
Where this actually pays off
I’d be skeptical of a business case built purely on headcount reduction. The more durable value I’ve seen in contact-centre work is consistency: an AI teammate handling the same category of case the same way every single time, at 2am on a Sunday as reliably as 11am on a Tuesday, without the variance you get across a roster of forty human agents with different experience levels and different days. That consistency shows up in SLA compliance and first-contact resolution rates faster than it shows up in a cost line.
It also changes what you ask your human agents to do. If the straightforward 40% of volume moves to a Coworker queue, your remaining human team is left with the harder, more ambiguous cases disproportionately. That’s good for engagement if you plan for it (more interesting work, more authority to resolve things end to end) and genuinely bad for morale if you don’t (every case feels harder, nothing feels like a quick win anymore). Worth raising with whoever owns the contact centre before the agent goes live, not after the engagement scores drop.
Before you flip the switch
If you’re scoping this for a client or your own org, get three things nailed down before Coworker goes into production: the routing logic that decides what it sees, the escalation contract that decides when it bails out, and the reporting changes that stop your dashboards from silently misrepresenting what actually happened. Skip any of the three and you’ll find out about it from a customer complaint or a confused operations manager, rather than from a test case.