The video above shows how quickly you can click through a first Agentforce agent. Speed of setup is the easy part. What decides whether that agent is useful — or a liability — is everything around the build: what job you give it, what it's allowed to touch, and who checks its work. This page covers that layer.
One scope note: I only describe Salesforce capabilities that Salesforce documents publicly, and I link to those sources. Menus and feature names change between releases, so if your screen doesn't match, trust Salesforce's current Trailhead documentation over any tutorial — including mine.
What you need before you start
- An org with Agentforce enabled. Edition, licences and contract terms decide access. Ask before you plan.
- A safe place to build. A sandbox or trial org, not production.
- Admin-level permissions to create and configure agents, or someone who has them.
- Clean source material. The answers you want the agent to give should already exist somewhere reliable — help articles, policies, product data. An agent can't be more accurate than what it's grounded in.
- A named human owner for reviewing conversations after launch.
How the pieces fit together
Salesforce's own training describes Agentforce Builder as the low-code tool where you define an agent's role, skills, access and settings, and the newer builder lets you start by describing in plain language what the agent should do. Under the hood, three ideas carry most of the weight:
- Topics — the jobs the agent will and won't do. They're also your first guardrail.
- Instructions — how the agent should behave inside each topic: tone, required checks, when to hand off.
- Actions — what the agent can actually do, such as looking something up or running a flow.
My practical read: think of topics as the job description, instructions as the training manual and actions as the keys you hand over. You'd never give a new hire every key on day one. Don't give an agent every action either.
A practical first workflow
- 1
Write the job description before you open Setup
One sentence on who the agent serves, one on what it should do, and a short list of what it must never do. If you can't write this, the agent will inherit your vagueness.
- 2
Confirm access in a sandbox or trial org
Agentforce availability depends on your Salesforce edition, licences and enabled features. Confirm with your admin or Salesforce account team, and build the first version somewhere that isn't production.
- 3
Create the agent in Agentforce Builder
Salesforce's builder lets you start a new agent and describe its role in plain language. Use the job description from step 1 rather than improvising in the prompt box.
- 4
Keep the first version to one or two topics
In Salesforce's model, topics define the jobs an agent handles, instructions shape how it handles them, and actions are what it is allowed to do. A narrow first scope is easier to test and easier to trust.
- 5
Attach only the actions the job needs
Every action is a permission. Start with read-only or low-risk actions and add record updates only once the conversation behaviour is proven.
- 6
Test the ugly questions, not the happy path
Use the builder's testing and preview tools with off-topic requests, angry customers, missing data and attempts to get the agent to do something outside its topics. Log what breaks.
- 7
Define the human handoff and review owner
Decide when the agent escalates to a person, who reviews its conversations each week, and who can switch it off. Then — and only then — consider activation.
A good first use case (and a bad one)
Good: an internal or customer-facing agent that answers common questions from approved help content and hands off to a person when it's unsure. Low risk, easy to review, easy to measure against your existing support queue.
Bad: an agent that issues refunds, changes contracts or edits customer records from day one. Those may be valid goals later. They're the wrong place to learn how your agent behaves.
Security and review limits to plan for
- Permissions are the real guardrail. Prompts and instructions guide behaviour; access controls decide what's possible. Review both.
- Agents can be wrong confidently. Treat every answer about pricing, policy or legal terms as something a human has to spot-check.
- Sensitive data needs a decision, not a default. Agree with your security or compliance owner what the agent may read and say before it goes live.
- Review on a schedule. Read real conversations weekly at first. Tighten topics and instructions based on what you see, not on what you expected.
- Keep an off switch. Know who can deactivate the agent and how quickly.
Where this fits in your stack
Agentforce makes most sense if Salesforce is already your system of record. If you're a smaller team still choosing a CRM, start with the best CRM for startups guide, and see the best AI agents roundup for options outside the Salesforce ecosystem. For Salesforce's own product overview, see the official Agentforce page.
The bottom line
Building the agent is minutes. Deciding its job, limiting its access and owning its review is the work. Do that part properly and your first agent becomes a template for the next one. Skip it and you've built a fast way to say the wrong thing to a customer.