Agentforce Agents
Agentforce Agents are the autonomous AI workers built on Salesforce's Agentforce platform that can hold a conversation with a customer or employee, decide which actions to take, execute them against Salesforce records or external systems, and respond grounded on real org data.
Definition
Agentforce Agents are the autonomous AI workers built on Salesforce's Agentforce platform that can hold a conversation with a customer or employee, decide which actions to take, execute them against Salesforce records or external systems, and respond grounded on real org data. Each Agent is a configured combination of Topics (what the agent can talk about), Actions (what it can do), Instructions (how to behave), Channels (where it runs), and Grounding sources (where its facts come from). Agents are the deployable unit of work on Agentforce.
The Agent runs on a large language model (Atlas Reasoning Engine, GPT, or another supported LLM) constrained by the Topics and Instructions an admin defines in Agent Builder. When a customer message arrives, the Agent decides which Topic best matches, picks Actions to fulfill the request, calls those Actions, returns a grounded response. Agents differ from Einstein Bots (the older Dialog-based chatbot product) in being LLM-driven rather than dialog-tree-driven, capable of handling novel utterances the admin never explicitly scripted, and able to chain Actions autonomously. They are the strategic direction for conversational AI in Salesforce.
How Agentforce Agents work, what they can do, and how they differ from Einstein Bots
Topics: the agent''s scope
Each Agent has a set of Topics, each scoped to a business area: Order Management Topic, Account Servicing Topic, Returns Topic. Each Topic includes Instructions (how the agent should behave on this topic), associated Actions (what it can do), and Examples (sample customer utterances). When a customer message arrives, the LLM picks the best-matching Topic. The Topic boundary is the soft scope the agent works within; well-scoped Topics produce predictable behaviour, overly broad Topics produce unfocused agents.
Actions: what the agent can do
Actions are the work-units an Agent can invoke. Standard Actions come pre-built from Salesforce (lookup an order, create a case, draft an email). Custom Actions wrap Flows, Apex methods, or prompt templates. The Agent decides which Action to call based on the Topic and the customer''s message. Action design is the highest-leverage piece of agent building; well-named Actions with clear input/output schemas get called correctly, poorly-named or overlapping Actions confuse the LLM and produce wrong calls.
Instructions and the prompt-engineering layer
Each Topic carries Instructions: natural-language directives telling the agent how to behave. "Always confirm the customer''s identity before sharing account details." "Never quote pricing without checking the current price book." "Escalate to a human after three unsuccessful attempts to resolve." Instructions are how admins constrain LLM behaviour without writing code. They are also where prompt-injection attacks land; the Einstein Trust Layer mitigates these but designers should write defensive instructions.
Grounding: where facts come from
Agents ground their responses on real org data rather than rely on LLM training data. Three grounding patterns. CRM direct lookup: the Action queries Salesforce records and returns structured facts. Data Cloud retriever: the Agent searches an index built over Knowledge articles, files, or DMO records. Document libraries: pre-uploaded reference docs the agent can reference. Direct CRM lookup is best for transactional data (this customer''s current order status); Data Cloud retrievers are best for unstructured content (how does the return policy work).
Channels: where agents run
Agents deploy to multiple channels: Lightning Service Console (internal agent assist), Experience Cloud (public-facing customer chat), Slack (internal team channels), WhatsApp, SMS, voice (via Service Cloud Voice integration). Each channel has its own configuration: authentication, UI styling, message length limits. One Agent can serve multiple channels with channel-specific overrides for tone and behavior. Channel decisions are usually made after Topics and Actions are stable.
Testing and the Agentforce Testing Center
Agents are tested in the Agentforce Testing Center, which runs synthetic conversations against the agent and scores responses against expected outcomes. Tests cover normal flows (happy path), edge cases (incomplete data, ambiguous requests), and adversarial cases (prompt injection attempts). The testing framework is what makes agents shippable to production; ad-hoc testing misses too many edge cases. Build a test suite per Topic and run it before every deployment.
Agentforce versus Einstein Bots
Two conversational AI products coexist. Einstein Bots use Dialog trees with admin-defined paths and NLP-based Intent matching. Agentforce Agents use LLM reasoning over Topics and Actions, capable of handling novel utterances. Einstein Bots are predictable and brittle; Agents are flexible and probabilistic. Migration from Einstein Bots to Agentforce Agents is manual (no auto-convert); the underlying model is different enough that you redesign the conversation rather than translate it. For new conversational AI work, default to Agentforce Agents.
Building an Agentforce Agent from concept to deployed channel
Agent setup runs in five phases: design the use case, build Topics and Actions, define Instructions, ground on data, test, deploy. Plan four to eight weeks for a non-trivial agent rollout.
- Define the use case and scope
Pick a specific business problem: customer-facing order status agent, internal SDR-assist agent, employee benefits help-desk agent. Define what the agent handles and what it escalates. Scope creep is the biggest agent design failure mode; ship narrow first.
- Create the Agent in Agent Builder
Setup, Agent Builder, New Agent. Pick the agent type (Customer Service Agent, Sales Coach, custom). Configure name, description, and the underlying LLM. Save to enter the build workspace.
- Build Topics and add Actions
For each business area within scope, create a Topic. Add 5-15 sample utterances per Topic. Attach Actions: standard actions where pre-built ones fit, custom flow actions for org-specific logic, prompt templates for content generation. Set Topic-level Instructions.
- Configure grounding
Attach Data Cloud retrievers for unstructured knowledge. Wire flow Actions for direct CRM lookups. Upload reference documents to the agent''s document library. Test grounding by asking the agent factual questions before going live.
- Test and deploy to a channel
Use Agentforce Testing Center to run synthetic conversations. Build a test suite per Topic. Once tests pass, deploy to a single channel first (typically internal Slack or Service Console for early feedback). Expand to customer-facing channels after a release cycle of monitoring.
Customer Service Agent, Sales Coach, custom. Each ships with starter Topics and Actions for common use cases.
Atlas Reasoning Engine (Salesforce default), GPT (via Salesforce-managed OpenAI), or other supported models. Pick based on use case and Trust Layer compatibility.
Service Console, Experience Cloud, Slack, WhatsApp, SMS, voice. One agent serves multiple channels with channel-specific configuration.
Direct CRM lookup via flow Actions, Data Cloud retrievers, document libraries. Combine multiple sources for richer grounding.
- Scope creep kills agent quality. Narrow scope and well-designed Actions produce reliable agents; broad scope with many overlapping Actions produces confused ones.
- The LLM picks Actions based on names and descriptions. Poorly-named or overlapping Actions get called wrong; spend time on Action naming.
- Grounding is what prevents hallucination on factual content. Skip grounding and the agent invents customer-specific data that is wrong but sounds plausible.
- Testing requires synthetic conversations covering happy path, edge cases, and adversarial attempts. Ad-hoc testing misses too many failure modes.
- Migration from Einstein Bots requires rebuilding the conversation as Topics and Actions. There is no auto-convert from Dialog trees to Topic graphs.
Trust & references
Cross-checked against the following references.
- Agentforce OverviewSalesforce Help
- Agent Builder OverviewSalesforce Help
Straight from the source - Salesforce's reference material on Agentforce Agents.
- Agent TopicsSalesforce Help
- Agent ActionsSalesforce Help
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What technology powers Agentforce Agents in Salesforce?
Q2. What is a key benefit of Agentforce Agents for business users?
Q3. How does the Einstein Trust Layer relate to Agentforce Agents?
Discussion
Loading discussion…