Your org is ready. Now comes the part most teams skip and later regret.
Before you open Agentforce Builder, you need a clear picture of
what the agent will handle and how it will do it.
Where we left off
In previous post we confirmed our license, enabled the right setup, grounded the agent in clean data, secured data access, identified your Flows and actions, chose your channel, and planned for sandbox testing. That foundation now shapes every decision in this step. In case you missed, read here:
The teams that struggle with Agentforce almost always built before they designed. The agent gave random responses, routed incorrectly, and nobody could explain why.
The fix is simple: two concepts: Topics and Actions and a 30-minute design exercise before you click anything.
The Mental Model
Think of it like building a team. You hire people for specific roles, give each role a clear scope, and equip them with tools. Agentforce works the same way.
Good Practice
In Your Company
When a user sends a message, the reasoning engine matches it to the best Topic, then runs the Actions inside it. If nothing matches, the agent says it cannot help and that is the correct behaviour.
01. Decide what kind of agent you are building
Revisit your Step 1 decision: employees, customers, or both? A Service Agent faces external customers (case status, order tracking, bookings). An Employee Agent faces your internal team (lead summaries, drafting emails, pulling case history).
Do not mix both in the same agent. The security model, data access, and topic structure are different. Keep them separate from the start.
02. List what the agent should handle: these become your Topics
A Topic is not a prompt or a job title. It is the boundary that tells the reasoning engine what category of work to handle right now. Write down 3 to 5 things users will ask this agent. Each one is a Topic.
Each Topic needs two things:
A Classification Description (plain language, tells the engine when to pick this topic - be specific)
A Scope (what the agent will and will not do here).
Example Classification
"Use this when a customer asks about their bill, charges, or payment history." Scope: "Only handle billing from the last 12 months. Do not process refunds directly."
Watch Out
One Topic called "General" or "Customer Support" with everything under it is the most common design mistake. The reasoning engine cannot distinguish a billing question from a technical issue if they live in the same Topic. Separate Topics = accurate routing.
03. For each Topic, list what the agent needs to do - these become your Actions
Actions are what the agent physically does - retrieve data, update records, run a process, call an API. A Topic without Actions is just a label.
Write 2 to 4 Actions per Topic. They can come from:
Standard Actions: (Agentforce's built-in library- always check here first)
Flows: (the autolaunched Flows you identified in Step 1), or
Custom Actions: (Apex, Prompt Templates, MuleSoft โ only when standard options are not enough).
Good Practice
Design Actions to be reusable. One well-built "Summarize Account Details" action can serve multiple Topics. Keep things lean: it is easier to maintain and easier to test.
04. Sketch your agent before opening the builder
30 minutes. Notepad or whiteboard. Write down: your agent type, your 3โ5 Topics with one-line descriptions, your 2โ4 Actions per Topic, and which of those Actions already exist as Flows or Apex in your org.
That sketch is your architecture. When you open Agentforce Builder, you are executing a plan - not staring at a blank canvas.
Pre-Builder Checklist
Standard Actions: (Agentforce's built-in library- always check here first)
Flows: (the autolaunched Flows you identified in Step 1), or
Custom Actions: (Apex, Prompt Templates, MuleSoft โ only when standard options are not enough).
