Turning Agentforce on is a checkbox; running it responsibly is a configuration discipline — generative features grounded in your org's records, an agent built from standard topics with scoped actions, deployed to a channel, and supervised through session reviews and escalation rules that exist before the first customer conversation.
Tier: Core · Workflow area: ERP Copilots & Agents · ~40 minutes
Salesforce ships the machinery: Einstein generative AI features, the Einstein Trust Layer between your org and the LLM, and Agentforce agents assembled from topics and actions. What it cannot ship is your judgment about scope, grounding and supervision — which records the agent may draw on, what it must never claim, and who reviews what it actually said. This playbook stands up a standard-topic agent in a Developer Edition org the governed way, so the pattern is rehearsed before it touches a production org.
Stand up the sandbox and enable the foundations. Sign up for a free Salesforce Developer Edition org, then in Setup enable Einstein generative AI and Agentforce. Confirm the Einstein Trust Layer is active and read what it gives you: data masking options for prompts, zero-data-retention arrangement with the LLM provider, toxicity scoring and the audit trail. Write down, in your own words, what is and is not protected — that paragraph goes in your rollout doc, because "the Trust Layer handles it" is not an answer legal will accept unexamined.
Scope the agent on paper before Agent Builder. One page: purpose ("answer order-status and product questions for logged-in customers"), the topics in scope, the records it may ground on (orders, products, cases — the caller's own only), out-of-scope by name (pricing exceptions, refunds, legal, anything medical or advisory), and tone. This page is your acceptance criterion; without it you are configuring vibes.
Build from standard topics and scope every action's data reach. In Agent Builder, create the agent from standard library topics matching your scope. For each topic, review the attached actions and their data access:
Topic: Order Inquiries
Action: Get Order Status — runs as the agent user; verify the
user's record visibility (sharing rules, profile) limits it to
the requesting customer's own orders.
Classification instructions: "This topic handles questions about
order status, shipping and delivery dates. It does NOT handle
refund requests or complaints — escalate those."
The agent's integration user is a real user with a profile and sharing rules — least privilege applies exactly as it would for any integration account. What the agent user cannot see, the agent cannot leak.
Ground responses in records, and forbid answering from model memory. Wire topic instructions so answers come from retrieved org data — the order record, the product description, your knowledge articles — and instruct explicitly:
Answer ONLY from the retrieved records and knowledge articles.
If no record supports an answer, say you don't have that
information and offer to connect a human agent. Never state
policies, prices or dates that are not present in the data.
Test the negative case immediately in the preview pane: ask about a product that does not exist and a policy you never loaded. The correct behavior is a grounded refusal plus escalation offer — if you get a fluent invented answer instead, grounding is not doing its job and nothing ships until it does.
Deploy to one channel, then run structured session reviews. Publish to a single low-stakes channel first (an internal test site or a copy of your web chat). From day one, review sessions on a schedule: daily for the first two weeks, then weekly samples. Score each reviewed session on a fixed rubric — was the answer grounded in a record, was scope respected, was escalation offered when it should have been, tone acceptable — and log the misses:
Session 2026-08-06-114: asked about refund for order 8842.
Agent answered order status correctly, then speculated refund
"usually takes 5-7 days" — no grounding record. Class: scope
breach + ungrounded claim. Fix: tightened Order Inquiries
classification instructions; added refund-policy KB article;
retest passed.
This review log is the supervision artifact — it is what "we supervise our agent" means when audit asks (pb-52 will formalize the cadence).
Write the escalation and kill rules before wide deployment. Three rules, in writing: escalation — which triggers hand a session to a human (explicit request, frustration signals, out-of-scope topics, any figure the customer disputes); thresholds — what miss rate in session reviews pauses rollout (pre-commit it, pb-38 style); kill switch — who may deactivate the agent, how fast, and the fallback channel experience when they do. Rehearse the kill once in the test channel so it is a procedure, not a theory.
An agent on a public channel is your org speaking — its ungrounded claim about a refund policy can bind you commercially and its mishandling of a customer's personal data is your DPDP/GDPR event, Trust Layer or not. Deploy narrow, ground hard, review sessions like the business records they are, and keep the kill switch rehearsed.
Agentforce done right is four disciplines in sequence — scope on paper, least-privilege grounding, negative-case testing, and supervised sessions with pre-committed thresholds. The platform provides the agent; the supervision routine is what makes it an employee you manage rather than a stranger with your badge.