Most explanations of Salesforce Agentforce read like either a keynote or a feature list, and neither helps you decide whether it belongs in your org. This post covers what an agent is made of, how it decides what to do, where it fits, and where a plain Flow does the job better. It's day one of a five-part series that goes from "what is this?" to "how do we get it into production without regretting it?"
The Short Version
An Agentforce agent is a language model layered on top of things your Salesforce org already has: records, permissions, Flows, Apex, and knowledge. The model doesn't replace any of them. It reads a request written in plain language, works out which of the capabilities you've given it apply, calls them, and turns the results into a response or an update.
That tells you where the work goes. Most of the effort in a real build is in the deterministic layer underneath: the actions the agent can call, the data it can see, and the rules for when it hands off to a person. If that layer is weak, the agent will be confidently wrong. If it's solid, the agent becomes a flexible front door to logic you already trust.
What an Agentforce Agent Is Made Of
Without the branding, an agent is built from a handful of parts.
Topics
A topic is a job the agent knows how to do, such as "check order status", "reschedule an appointment", or "summarize an account before a call". Each topic has three things. A description helps the agent recognize which requests belong to it. A scope says what's in bounds and what isn't. And there's a list of the actions it's allowed to use. Topics are how you keep an agent focused. An agent with three sharp topics is usually more reliable than one with fifteen vague ones.
Instructions
Instructions are plain-language guidance attached to a topic: "always confirm the order number before sharing shipping details" or "never offer a refund above the policy limit; escalate instead". They shape how the agent behaves, but they're guidance to a model, not code. That difference comes up again below. Anything that must be enforced every single time belongs in an action or a permission, not in an instruction.
Actions
Actions are what the agent can actually do. In Salesforce, they're usually backed by one of these:
- Flows, for record lookups, updates, and multi-step business logic you already maintain
- Apex, for logic that's too complex or too performance-sensitive for Flow
- Prompt templates (built in Prompt Builder), for generating text grounded in record data, like a case summary or a draft reply
- API calls and integrations, for reaching systems outside Salesforce
Each action has defined inputs and outputs plus a description of what it's for. Those descriptions matter more than people expect, because they're how the agent picks the right tool.
Grounding Data
The agent answers from data, not from memory. That data comes from CRM records, knowledge articles, and Data Cloud where it's set up. Grounding is the difference between "the model guessed" and "the model looked it up". It also means the agent inherits whatever state your data is in, including duplicates and stale fields.
The Trust Layer and Permissions
Requests and responses pass through the Einstein Trust Layer, which handles things like masking sensitive data, toxicity checks, and audit logging. Separately, the agent runs with a defined set of permissions that limit what it can see and change. These are your guardrails, but they won't design your access model for you.
How the Agent Decides What to Do
Agentforce uses a reasoning engine, which Salesforce calls Atlas, to plan each turn. In practice the loop looks roughly like this:
User request
|
v
Classify -> pick the best-matching topic
|
v
Plan -> which actions, in what order, with what inputs?
|
v
Act -> call a Flow, Apex, a prompt template, or an API
|
v
Observe -> are the results enough to answer, or is another step needed?
|
v
Respond, ask a clarifying question, or hand off to a human
Here's a worked example. A customer writes: "My order hasn't arrived and I'm traveling next week. Can I change the delivery address?"
- The agent matches the request to an order-management topic rather than, say, a returns topic.
- It needs to identify the order, so it either asks for the order number or calls a lookup action using the verified contact.
- It calls a Flow-backed action to get the shipping status.
- It checks whether the address can still change, ideally via an action that returns a clear yes or no rather than by reasoning over policy text.
- If the change is allowed, it calls an update action. If not, it explains why and offers the next best option or a handoff.
The model handles what's hard to hard-code: a messy request with two intents, a sequence of steps, and the wording of the answer. Every step that changes data or applies a rule runs through an action you built and tested. That split is what makes Agentforce builds hold up. The model interprets, and deterministic actions handle anything with consequences.
Where Agentforce Is Genuinely Useful
Agentforce earns its place when the input is unstructured and the path varies, but the set of possible outcomes is known.
Requests That Arrive in Natural Language
Customer messages, internal "how do I…?" questions, and reps asking for context all arrive as free text. A Flow needs structured input to start, so turning that text into the right action is exactly the gap an agent fills.
Work That Needs Several Lookups Stitched Together
Preparing for a renewal call might mean pulling open cases, recent activity, contract dates, and product usage. Each lookup is simple. The agent adds value by deciding which ones matter for this account and summarizing them.
High-Volume Conversations With Known Resolutions
Think of order status, appointment changes, access requests, and simple entitlement questions. They follow a small number of patterns, but people phrase them in many different ways. The agent handles the phrasing, and your actions handle the resolution.
We've built the same shape outside Salesforce. We built a customer support AI triage system with OpenAI, the Zendesk API, and vector embeddings. It auto-resolved 40% of tickets, with instant response times. The model wasn't the reason that worked. It worked because the categories it could resolve were well defined, the knowledge it needed was easy to retrieve, and everything else went to a person quickly. An Agentforce service agent should follow the same pattern.
Where a Flow Is the Better Answer
Plenty of work that gets pitched as an "agent" use case is better handled by automation you already know how to build.
| Situation | Better fit | Why |
|---|---|---|
| Triggered by a record change (stage moves, field updates) | Record-triggered Flow | There's no language to interpret, and it's deterministic and cheaper |
| The same input always produces the same output | Flow or Apex | An LLM adds variability and cost with no benefit |
| A compliance rule must apply every time | Flow, validation rule, or Apex | Instructions guide the model; they don't enforce anything |
| Scheduled batch work (nightly sync, cleanup) | Scheduled Flow or Apex job | There's no conversation and no reasoning involved |
| A user fills in a known form | Screen Flow | The input is already structured |
| Free-text requests with several possible outcomes | Agentforce, calling Flows as actions | Interpreting the request is the hard part |
Put simply: if the decision tree fits on a whiteboard, build the decision tree. Agents are for cases where the outcomes are easy to define but the way requests arrive is messy.
Cost is the other reason. Agentforce is priced on consumption, so every conversation has a cost, while a record-triggered Flow running thousands of times a day doesn't consume per-interaction AI usage. Moving deterministic work into an agent rarely makes it better and almost always makes it more expensive and harder to test.
The two aren't competing anyway. Most good Agentforce implementations are mostly Flows, with the agent deciding which one to call.
A Simple Test Before You Build Anything
Before you commit to an agent for a process, ask four questions:
- Is the input unstructured? If requests already arrive as structured fields, you probably don't need a model to interpret them.
- Is the set of outcomes small and known? Agents work best when they choose among a handful of well-defined actions, not when they have to invent a resolution.
- Do the actions already exist, or could they be built as Flows? If the underlying automation doesn't exist yet, building it is the real project.
- What happens when it's wrong? If a wrong answer means a slightly awkward draft, start there. If it means a wrong refund or exposed data, you need much tighter guardrails and a person reviewing the output.
If the answers are "yes", "yes", "yes", and "we can live with it", the process is a candidate. If any answer is shaky, fix what sits underneath first. Tomorrow's post covers how to tell whether your org is ready for a pilot, and the red flags that mean "not yet".
Key Takeaways
- An Agentforce agent is built from topics, instructions, actions, grounding data, and guardrails. The model is the smallest part of the build.
- The reasoning engine interprets the request and plans the steps. Your actions, mostly Flows and Apex, do the work that has consequences.
- Agents fit unstructured, repetitive requests with a known set of outcomes. Logic that's deterministic, triggered by record changes, or critical for compliance belongs in Flow or Apex.
- Anything that must happen every time should be enforced in an action or a permission, not written as an instruction.
- Most good agent builds are mostly automation. If the automation doesn't exist yet, build it first.
FAQs
Is Agentforce just a chatbot?
No. A traditional chatbot follows a scripted dialog tree. An agent interprets the request, chooses and calls actions, and decides its next step from the results. It also works outside chat, inside a rep's Salesforce workflow.
Do I need Data Cloud to use Agentforce?
Not for every use case. Agents can ground their answers in CRM records and knowledge articles. Data Cloud becomes important when the information the agent needs is spread across several systems or has to be unified before it's useful.
Can an agent replace our existing Flows?
It shouldn't. Agents call Flows as actions. Keep the deterministic logic in Flows and let the agent decide when to use them.
How does the agent avoid making things up?
Grounding answers in retrieved data, limiting it to defined topics and actions, and handing off when it can't resolve something. The Trust Layer adds masking and monitoring on top.
What's a good first use case?
Something high-volume, low-risk, and well understood, such as case summaries, draft replies, or call prep, so you get fast feedback with little downside.
Working on Something Similar
If you're trying to work out where Agentforce fits in your org, and where it doesn't, that's what our Agentforce Opportunity Audit is for. We map your candidate use cases against your data, automation, and permissions, then tell you which ones are worth piloting. You can see how it works on our Agentforce page, or get in touch and tell us about the process you have in mind.
Comments
No comments yet. Questions and counterpoints are welcome.
Leave a comment