Most Agentforce tutorials start with the happy path — a clean demo org, a well-behaved prompt, a satisfying result. This one starts with what you actually need to have in place before the happy path is possible, because skipping that part is why most first attempts produce something that does not work and nobody knows why.
Two things need to exist before you build anything: Data Cloud connected to your org, and a clear definition of what the agent is allowed to do.
Data Cloud is how Agentforce accesses your org's data — accounts, cases, contacts, custom objects. Without it, your agent is reasoning in a vacuum. The connection is set up in Setup under Data Cloud → Salesforce Connector. If your org already has Data Cloud provisioned, this is a configuration step, not a licensing step. If it does not, you need to get it provisioned before you proceed.
The scope definition is something you write in plain language before touching any configuration. Answer these three questions: What is this agent for? What data does it need to read? What actions is it allowed to take? If the answers are vague, the agent will be vague. Specificity here saves an enormous amount of debugging time later.
Agent type. You start by choosing the agent type — currently the main options are Service Agent (customer-facing, handles cases and queries) and Sales Agent (handles lead qualification, meeting prep, opportunity summaries). Choose the one that matches your use case. This determines the default topic templates and actions available to you.
Topics. Topics are the areas of conversation your agent handles. Each topic has a label ("Order Status"), a description that tells the agent what belongs in this topic, and a set of instructions for how to handle it. The instructions are the most important thing you write. They are the equivalent of an agent playbook — what to check, in what order, how to respond, when to stop and ask a human.
Write the instructions as if you were briefing a very literal new hire. Do not assume the agent will use common sense. State the sequence explicitly: "First check the related case record. If the status is Closed, tell the customer the resolution. If the status is Open, check the last activity date. If no activity in the past 48 hours, escalate to the service queue." That specificity is what separates a useful agent from one that hallucinates answers.
Actions. Actions are what the agent can actually do — not just what it can say. Actions include querying records (via Flow or Apex), triggering record updates, sending emails, calling external APIs, or creating new records. You add actions to each topic, and the agent's reasoning engine decides which action to invoke based on the conversation.
Start with read-only actions. An agent that can look up information and report it accurately is useful and low-risk. An agent that can update records or send emails introduces consequences. Get the read-only version working first, then expand the action set incrementally.
Escalation path. Every agent needs a defined exit — what happens when the problem is outside the agent's scope, or when the customer asks for a human, or when the agent has tried and failed. This is not optional configuration. An agent with no clear escalation path will either loop unhelpfully or give up with a generic apology. Define the fallback explicitly: transfer to queue, create a case, send a handoff summary.
Agent Builder has a built-in conversation preview — use it, but treat it as a starting point rather than a proof of readiness. The preview does not simulate real data volume, edge cases, or unexpected conversation paths. Before going live, test against at least ten real scenarios, including the ones where the agent should fail or escalate. If you only test the scenarios where the agent should succeed, you will discover the failures in production.
Pay particular attention to what happens when the agent cannot find a record, when the data is incomplete, and when the user asks something adjacent but outside the defined topic. Those three situations account for a significant portion of real conversations.
Agentforce agents deploy to channels — Embedded Service (website chat), Experience Cloud sites, Slack, or as background agents triggered by record events. The channel determines the user interface; the agent logic is the same across all of them.
For a first deployment, Embedded Service on a test Experience Cloud site gives you real conversation data without customer exposure. Run it there for a week, review the conversation logs in Agentforce Analytics, identify where the agent is performing poorly, and iterate before putting it in front of actual customers.
A well-built first agent handling a narrow, data-rich use case will perform well. It will handle a meaningful percentage of the volume you point at it, and the escalations it produces will be better-informed than the ones a human handles cold.
A broad first agent handling everything will perform inconsistently. The inconsistency will be attributed to AI. The real cause will be scope, data quality, and underspecified instructions — all of which are fixable, but only if you diagnose them correctly.
Start narrow. Build confidence. Expand scope as the data proves it.