Agentforce Service Agent With Human Handoff
How we would design a customer-facing Agentforce service agent that answers from approved knowledge and escalates to a human with full context.
This is an illustrative blueprint. It is a reference architecture, not a write-up of a specific client project; outcomes depend on your data and setup.
This blueprint describes how we would design a customer-facing Agentforce service agent that answers from approved knowledge, completes a few low-risk tasks and hands over to a person when it should. It assumes Service Cloud with Knowledge already in use. Salesforce lists Flex Credits, Resolutions and per-user licensing, so confirm the commercial model before scoping.
Business problem
A service team receives repetitive questions through web chat and the help portal: returns policy, delivery times, updating account details. The answers already exist in knowledge articles, but customers still queue for a human to paste them. An earlier scripted chatbot broke when customers phrased things differently, and its handoffs lost the conversation.
The goal is deliberately narrow: answer from approved knowledge, perform a few safe actions, and route everything else to a human with the transcript and a case already in place.
Architecture
Components and responsibilities
| Component | Responsibility |
|---|---|
| Service Cloud (Cases, Knowledge) | System of record for cases, articles and entitlements |
| Agentforce Builder (in Agentforce Studio) | Agent definition, instructions and Agent Script for deterministic steps |
| Knowledge articles | Grounding content, filtered by data category |
| Einstein Trust Layer | Grounding in CRM data, data masking, toxicity detection and an audit trail |
| Flow and Apex actions | Lookups and simple updates the agent may call |
| Omni-Channel queues and skills | Routing escalations to the right human team |
| Portal or web chat channel | Where customers talk to the agent |
| Agentforce Observability | Reviewing conversations and failures after launch |
Since the week of 13 July 2026, new agents can only be created in the new Agentforce Builder; legacy agents keep running. Agent Script mixes deterministic logic with LLM reasoning, and Winter '27 added else if, system variables and escalate, which lets us make handoff rules explicit rather than leaving them to the model.
Data model
The agent works mostly with standard objects: Contact or Person Account for the verified customer, Case for anything needing follow-up, and Knowledge articles organised by data category. The messaging session and transcript stay linked to the case.
We add a handoff-reason picklist on Case (for example "customer asked for a person" or "verification failed") and a flag showing whether the agent resolved the conversation, so reporting stays honest. If customer context lives in several systems, a unified profile in Data 360 can supply it; see our unified customer profile blueprint.
Key components
Knowledge readiness
Most agent quality problems are knowledge problems. We audit top question themes against existing articles, retire duplicates and fix contradictions. Knowledge Blocks and AI-drafted articles (Winter '27) can help, but need a Knowledge add-on licence.
Instructions and guardrails
Instructions state what the agent covers, what it must never do (promise refunds, give legal advice) and how to respond when unsure. The Trust Layer adds masking and toxicity detection; we also limit which fields actions return.
Actions
Each action is a small, tested Flow or Apex method, such as looking up order status or creating a case. Actions that change data require verification first, enforced in Agent Script rather than the prompt.
Human handoff
Triggers include a request for a person, repeated failed answers, verification failure and out-of-scope topics. The agent updates the case, writes a summary and hands off through Omni-Channel to a skill-matched queue. Outside staffed hours, it says when the customer will hear back.
Testing and launch
- 01
Build a test set
Collect real questions from past cases, including awkward phrasing and attempts to break the rules, with the expected answer or escalation for each.
- 02
Test in a sandbox
Run the set in Agentforce Builder. Voice and Conversation Testing is Beta and the Custom Scorers UI is Beta (the API is GA), so plan some manual review.
- 03
Test handoff end to end
Confirm the case, summary and transcript reach the human agent and routing respects skills and hours.
- 04
Run UAT with service staff
Let experienced agents try to trip it up; they know which answers customers misread.
- 05
Launch narrowly
Start with one channel and a few topics, telling customers they are talking to an AI agent and can ask for a person.
- 06
Review and widen
Review transcripts and escalation reasons weekly with Agentforce Observability, fix knowledge gaps, then add topics.
Risks and variations
- Stale knowledge produces confident wrong answers. Assign article owners and review dates before launch.
- Escalation tuning cuts both ways: too eager adds little, too reluctant traps customers.
- Data exposure. Keep personal data behind verification and the running user's permissions narrow.
- Prebuilt or custom. Salesforce's generally available Help Agent ("Casey") may suit simple self-service; a custom agent suits specific actions.
- Voice. The design can extend to Agentforce Voice, with extra testing for speech.
Our Agentforce and AI automation and Service Cloud implementation services cover this build; see also our responsible AI approach and service case notification journeys.
Sources
Planning a service agent?
We can help you assess knowledge readiness, design escalation rules and test an Agentforce agent before customers see it.
