Salesforce Agentforce Channels: Where Do Agents Actually Live?

⚡ 1-Minute Summary

In Salesforce Agentforce, agents are divided into two main categories based on who interacts with them: Employee Agents and Service Agents. Employee agents assist your internal staff natively within Lightning, Slack, and the Salesforce mobile app. Service agents interact directly with your customers across web chat, Experience Cloud sites, messaging platforms (like WhatsApp and SMS), and voice.

The magic of this architecture? The exact same Agent Script powers both. You build the logic, topics, and actions once, and deploy them across any surface. When you switch to a channel like voice, the physics change (latency, spoken numbers, short conversational turns), but the underlying business logic remains untouched.

🗺️ Module Map

MODULE 10 root: 'Where does the agent actually appear?'
 ├─ 10.1 Where agents live
 ├─ 10.2 Voice: same script, different physics
 └─ 10.3 Escalation to a human
  

📍 Where Agents Live

💬 In plain words: Think of the agent as a brain, and the channels as doors. Employee agents appear on internal doors (tools your team uses). Service agents appear on external doors (places your customers hang out). Because the brain doesn't change between doors, you keep all your decision-making logic centralized instead of rewriting it for every platform.

📌 Real-Life Example: Meridian Corporation runs a single script for its "Outage Agent." That identical logic serves the company's website chat, their WhatsApp support line, and their automated voice phone number. There is zero duplication of the agent's core instructions.

🧩 Core Concept: One Brain, Many Doors

To master Agentforce, you need to understand exactly where and how these AI agents operate:

• Employee Agents are strictly supported in internal channels: the Agentforce panel within Lightning Experience, Slack integrations, and the Salesforce mobile app.
• Service Agents run on customer-facing surfaces: Messaging for In-App and Web, Experience Cloud sites, WhatsApp, SMS, email, and Voice.
• Headless Access: Any agent can be triggered headlessly through the Agent API, or called from backend automation using Flow or Apex invocable actions.
• Channel Independence: One script serves many surfaces. What changes per channel is presentation and pacing (e.g., waiting for someone to finish speaking on a phone call), not the decision logic.

🔑 Key Points

• Build Once, Deploy Anywhere: The core logic sits centrally. A new channel is simply a new deployment, not a massive rebuild.
• Voice Considerations: While the logic is the same, Voice changes the physics. Latency becomes "dead air," conversational turns must be shorter, and numbers need specific text-to-speech pronunciation rules.
• Licensing Dependencies: Deploying Service Agents on external messaging platforms requires the Digital Engagement add-on, meaning you cannot test web messaging in a standard plain developer org.

🧭 360 Card — Where Agents Live

Rule: Build channel-independent logic and adapt only the pacing and presentation for the specific surface.
Gain: Adding a new communication channel requires configuration, not rebuilding the AI from scratch.
Price: You must resist the urge to fork your code or create channel-specific agent variants when one surface behaves awkwardly.
Limits: Employee agents are rigidly restricted to internal employee channels. External text/web messaging requires Digital Engagement.
Mirror (The alternative): Building one agent per channel. It feels tailored at first, but every business rule change now requires three separate updates.

⚠️ Developer Trap: Do not try to fork your Agent Script just because a specific channel (like SMS) has character limits. Handle formatting at the channel layer, not the reasoning layer. If you split your logic, you destroy the scalability of Agentforce.

🎯 Core Q&A

Q: Which channels can an Agentforce agent run on?

🎯 Say this first: Employee agents run in Lightning, Slack, and Mobile. Service agents run in web chat, community sites, messaging apps, and voice. Both can be accessed headlessly via the Agent API.

A: You have to split the answer by agent type because the channels are not interchangeable.

• Employee agents are supported in employee channels: the Agentforce panel in Lightning, Slack, and the Salesforce mobile app.
• Service agents cover customer surfaces: Messaging for In-App and Web, Experience Cloud sites, WhatsApp, SMS, email, and voice.
• Either can also be reached headlessly through the Agent API, or invoked from Flow and Apex.
• The most important architectural point is that the logic does not change between channels. One Agent Script serves all of them. What changes is pacing and presentation (most visible when transitioning to voice).

🔗 Follow-up Questions to Connect the Dots

• "If the logic is the same, how do we handle complex data tables over a Voice call versus a Web Chat?"
  Answer: While the agent pulls the same data, the UI layer on text channels can render rich components (like LWC), while Voice relies on prompt instructions to summarize the top results concisely.
• "How does escalation to a human work if the user is interacting headlessly via API?"
  Answer: Headless API interactions generally return the agent's intent to escalate as a payload. Your custom backend application must catch that payload and route the user to a human through your own system's interface.

✓ Core Takeaway
One brain, many doors. Build the logic once. The channel is just a doorway, not a different agent. This architecture makes adding new communication channels incredibly fast and cheap.