The chatbot assumption gets in the way
Agentforce is Salesforce's framework for building software agents that are handed a job rather than a script. You describe the work in plain sentences, you list the actions the agent may run, and you decide which user identity it runs under. Everything it can see and everything it can change comes from that identity and from the actions you gave it.
The word chatbot follows the product around and it sets the wrong expectation. A chatbot walks a conversation tree somebody drew in advance. An Agentforce agent takes a request in ordinary language, works out which of its defined jobs that request belongs to, then chooses which of its available actions to run and in what order. Nobody drew that path ahead of time, which is the point and also why the configuration work feels unfamiliar.
The other thing people carry in is Einstein. Einstein was a set of features you switched on inside existing screens, opportunity scoring, a reply draft, a summary on a case. Agentforce is something you design. You define what the agent is for, what it may touch, and what it must refuse, and none of that arrives configured. Teams that expect a checkbox lose a month finding that out.
Topics are the jobs, instructions are the boundaries
The building block is a topic. A topic is one job the agent knows how to do, such as answering questions about order status or preparing a rep for a renewal call. It carries a description that tells the agent when the topic applies, a set of instructions written in ordinary sentences, and the list of actions the agent may use while working inside it.
The description does more work than people expect. When a request arrives, the agent first has to decide which topic it belongs to. Two topics with overlapping descriptions produce an agent that picks the wrong job and then answers confidently from the wrong instructions. I watched a team spend a full sprint on nothing else, splitting one broad service topic into three narrow ones because the original description caught every message containing the word order.
Instructions are where you write what the agent must always do and what it must never do. Confirm the account before quoting a balance. Never quote a discount. Hand the conversation to a person if the customer mentions cancelling. These are policy sentences, and getting them right takes longer than anyone budgets, because the model follows what you wrote rather than what you meant.
Actions are the only way it touches your data
An agent cannot do anything you have not given it an action for. An action is a concrete piece of Salesforce work: a flow, an Apex method, a prompt template, a record lookup, a call out to another system. The model decides which action to run and what to pass into it. The action itself stays ordinary platform logic that an admin or a developer built and can read.
The line that matters to an admin sits between reading and writing. An agent answering a question runs a query, composes a sentence, and leaves the database exactly as it found it. The worst outcome there is a wrong answer, which is recoverable. An agent that runs a write action changes a record that reports, automations and other people's work depend on, and the recovery is a data fix with a timestamp on it.
Handle those two sets of actions differently from the first day. Read actions can go into a pilot with light review. Write actions deserve the review you would give any flow that updates production records, plus a question about when the model decides to fire them. Most teams I have worked with put a confirmation step in front of the first few write actions and kept it far longer than planned.
Every answer passes through the sharing model
Agentforce runs against the same permission and sharing model an ordinary user does. The agent is tied to a user record with a profile, permission sets, a role and everything the sharing rules imply. When it queries opportunities, it gets back the opportunities that user can see. When it updates a case, the update succeeds or fails on the same field level security that would apply if that person had typed it.
That design is the strongest thing about the product and the easiest thing to get wrong. Over-permission the agent user and it will answer with data the person asking should never have seen, with no error anywhere to warn you. Under-permission it and the agent reports that it found nothing, which reads as a broken product rather than an access problem, and people quietly stop asking it things.
A distributor I worked with last year ran an order status pilot for their partner community. The agent user's profile had been copied from a support manager, because that was the fastest way to get moving. Three weeks in, a partner asked about open orders on their account and the answer included orders belonging to a sibling account under the same parent. Nothing failed. The agent asked for what it was allowed to ask for, and the profile allowed too much.
We rebuilt that agent user from an empty profile and added one permission set at a time until the pilot worked again, which took two days. A Salesforce permission audit before the build would have found it in an afternoon, and I have opened every engagement that way since.
Bad data produces confident wrong answers
An agent reading your CRM has no way to know that two account records describe the same customer, or that a field people stopped filling in two years ago is blank rather than zero. It reads what is there and answers in a steady, complete sentence. The steadiness is the dangerous part, because a person looking at the same screen would have paused at the empty field.
Every duplicate, every abandoned custom field and every free text field carrying three different meanings turns into an answer somebody acts on. Teams underestimate this because their reports already work around the mess. A report has a filter somebody added in 2022 to exclude the test accounts, and the agent has no such filter unless you build one into the action. The CRM data model that outlives the CRM is the argument to settle before the pilot rather than after it.
Scoping what an agent must never do is real design work. No setting called safe exists. You get there by listing the situations you would not want handled without a person, writing those into topic instructions, leaving out the actions that would make them possible, and then testing the awkward requests instead of the demo ones. The handoff between human and agent work needs the same attention as the path where everything goes right.
What to settle before anyone builds the first agent
Three questions decide whether a first agent is worth building. Which job is narrow enough to describe in five sentences. Which records the agent has to read, and which user has exactly that access and no more. Whether anything it does changes a record, and who reviews that change before it lands.
If the second question takes a week to answer, the permission work is the project and the agent is the part that comes afterwards. That ordering annoys people who wanted something to show on Friday, and it separates a pilot that survives review from one that gets switched off. An agent readiness check covers the rest of the ground, and the wider AI and agents coverage is where the cross-platform comparisons live.
Pick one job, write the five sentences, then open the profile of the user your Agentforce agent would run under and read every object permission on it out loud. If you cannot say why each one is there, you are not ready to build the agent, and you have learned something more useful than a demo would have told you.
