Agentforce demos extremely well. You point it at a clean org, ask it a question it has good data for, and it produces a fluent, accurate answer. Then it meets your actual service queue — forwarded email threads, three order numbers in one message, a customer who describes the product by colour rather than SKU — and the gap between demo and production becomes obvious.
The gap is almost never the model. It is grounding, guardrails and measurement. Here is what each one requires before an agent should touch a real customer.
1. Grounding is a data project, not a prompt project
An agent can only be as accurate as what it can retrieve. Before writing a single instruction, answer three questions about every fact the agent will need to state.
- 01Where does this fact live — a Salesforce record, a Knowledge article, or an external system behind an API?
- 02Is it current, or is it a snapshot that goes stale between syncs?
- 03Is the agent user permitted to see it, at object, record and field level?
That third question is the one teams skip. The agent runs as a user, and it inherits that user's sharing and field-level security. If the retrieval works in your sandbox because you tested as a system administrator, it will fail differently in production — usually by returning nothing and inventing a plausible answer instead.
Knowledge articles need curation before they need indexing
Most knowledge bases contain contradictions accumulated over years — two articles describing the same return policy differently, one of them four versions out of date. Retrieval will surface both. Deduplicate and date-stamp your articles before you point an agent at them, and retire anything you would not want quoted verbatim to a customer.
2. Guardrails are configuration, not instructions
Telling an agent in natural language not to do something is a preference. Preventing it at the platform level is a control. Serious deployments use both, and only the second is defensible in a security review.
- Run the agent as a dedicated user with a permission set scoped to exactly the objects and fields it needs — nothing inherited from a broader profile.
- Expose actions through invocable Apex and Flow rather than giving the agent generic record access, so every write path is explicit and testable.
- Mask or exclude sensitive fields at the Trust Layer so they never enter a prompt in the first place.
- Define escalation as a first-class outcome: low retrieval confidence, an unresolvable reference, or a sentiment signal should route to a human queue, not generate a best guess.
- Keep a human in the loop for outbound communication until deflection quality is proven. Draft-and-review costs a few seconds per case and buys you an audit trail.
An agent that escalates cleanly is worth more than an agent that answers everything. The failure mode you cannot tolerate is a confident wrong answer sent to a customer.
3. Measure before you launch, or you cannot prove anything
If you do not capture a baseline before go-live, you will spend the next quarter arguing about whether the programme worked. Capture these numbers for at least two weeks before the agent handles a single case.
- Volume by case reason — you need to know how big the target category actually is.
- Median and 90th-percentile handle time for the target category.
- First-response time and full resolution time.
- Reopen rate, which is your quality signal after deflection.
- CSAT for the target category, segmented from your overall score.
After launch, track deflection rate alongside escalation reasons. The escalation breakdown is more useful than the deflection number: it tells you exactly which retrieval gap or missing action to build next.
4. Pick a first use case that can actually succeed
Score candidate use cases on three axes: volume, data readiness and action complexity. You want high volume, high data readiness and low action complexity for the first build. Order status, appointment changes, account lookups and policy questions usually qualify. Anything requiring negotiation, judgement or a commercial decision does not.
An illustrative order-status workflow can follow that shape: accept inbound email, extract order references, retrieve live data, and prepare a reply for agent review. Keep inputs unambiguous, lookups deterministic, and a person accountable for the response.
The short version
Ground it in data the agent is genuinely permitted to see. Enforce guardrails in configuration rather than in prose. Baseline your metrics before launch. Start with the boring, high-volume use case. Everything interesting becomes possible once that one is running reliably.