Agent demos are easy. Agents in production are a governance exercise. The model is not usually the risk — the risk is an agent that answers confidently from the wrong data, takes an action nobody authorised, or keeps talking when it should have handed over to a human.
All three are design problems with known solutions. This is the checklist I work through before an Agentforce agent gets anywhere near a customer.
Key takeaways
- An agent is a scope, not an intelligence. Its behaviour is bounded by topics, instructions, actions and the data it is grounded in.
- Grounding decides what it knows. Ungrounded agents do not fail loudly — they improvise plausibly, which is worse.
- Actions decide what it can do. Every action inherits the permissions of the running user, so the running user is a security decision.
- Escalation is a feature, not a fallback. Design the handover before you design the conversation.
- Ship narrow. One topic, one audience, one measurable outcome, one clear off switch.
The four things that define an agent
Topics
A topic is a job the agent is allowed to do, described in natural language, with instructions about how to do it. “Answer questions about order status.” “Help a prospect choose between our two service tiers.” Each topic carries its own instructions and its own set of permitted actions.
The discipline: a topic should be narrow enough that you can write its instructions in under 200 words and enumerate every action it needs. If you cannot, it is two topics.
Actions
Actions are what the agent can actually do — query a record, invoke a flow, call an Apex method, send something. This is the security surface. Two facts to internalise:
- Actions execute as a defined running user, and that user’s permissions are the agent’s permissions. Give the agent an over-permissioned service account and you have given every conversation that permission set.
- Read actions are cheap to review; write actions are not. Anything that mutates a record, sends a message, or moves money deserves an explicit approval step or a hard constraint in the action itself, not a hopeful instruction in the topic prompt.
Grounding
Grounding is how the agent gets facts. In the Salesforce ecosystem that generally means retrieval over your own content and records — knowledge articles, records the running user can see, and unstructured content indexed through Data 360.
The failure mode is specific and important: an agent with insufficient grounding does not say “I do not know.” It produces a fluent, well-formatted, entirely invented answer. That is why grounding coverage is a launch gate rather than a nice-to-have — and why the first test set should include questions you know the grounding cannot answer, to confirm the agent declines rather than improvises.
Stale content is worse than missing content
An agent grounded in a knowledge base that nobody has curated for two years will confidently quote a discontinued product, a superseded policy, or last year’s pricing. Before grounding a corpus, someone has to own it. If no one will commit to that ownership, exclude the corpus.
Guardrails
Guardrails are everything that constrains behaviour outside the happy path: what the agent must refuse, what it must never claim, when it must escalate, what it must log, and what data must never appear in a response.
Write these as explicit instructions per topic, and then test them adversarially. Someone on the team should spend an hour actively trying to get the agent to promise a discount, quote a competitor, give advice outside its remit, or reveal another customer’s data. That hour is the highest-value testing you will do.
The escalation path is part of the product
Every agent needs a defined answer to: what happens when this goes wrong for a real person?
At minimum, decide four things before launch. Trigger: what conditions force a handover — explicit request, detected frustration, a topic outside scope, a failed action, or a repeat question. Destination: which queue or channel, staffed during which hours. Context: what transcript and record context travels with the handover, so the human does not restart the conversation. Fallback: what the agent says when the destination is closed.
An agent that cannot escalate is not autonomous, it is stuck — and the customer experiencing it will remember that far longer than the twenty questions it answered correctly.
Scoping a first agent
The pattern that consistently works is deliberately unambitious:
- Pick one high-volume, low-consequence job. Order status, event registration questions, tier comparison, documentation lookup. High volume gives you data; low consequence gives you room to be wrong.
- Pick one audience and one channel. Internal before external is a legitimate and underrated first step — your own colleagues give better feedback and forgive more.
- Define the measurable outcome up front. Deflection rate, first-response time, or task completion. Decide the number before launch so success is not decided retrospectively by whoever is loudest.
- Build the test set before the agent. Fifty real questions from real tickets or real sales calls, with the correct answer written next to each. Include ten the agent should refuse.
- Run it shadowed. Agent drafts, human reviews and sends, for long enough to see the failure modes. Then flip to autonomous for the subset that passes.
- Instrument and review weekly. Transcripts, escalations, refusals, and the outcome metric. Weekly for the first month, then monthly.
The off switch
Before launch, write down exactly how to disable the agent, who is allowed to do it, and how long it takes. Test it. An organisation that cannot turn something off in five minutes will not be comfortable turning it on — and rightly so.
The questions your security and legal reviewers will ask
Get ahead of these; they are entirely reasonable and they are always asked eventually.
| Question | What they need to see |
|---|---|
| What data does the model see? | The grounding sources, the running user’s permission scope, and the data-handling terms of the platform’s trust layer |
| Is customer data retained by the model provider? | Documented answer from the platform’s trust and compliance materials, not an assumption |
| Can the agent take an irreversible action? | An enumerated list of write actions with the constraints on each |
| How do we audit a bad interaction? | Where transcripts are stored, for how long, and who can read them |
| Do customers know they are talking to an AI? | Your disclosure wording and where it appears — increasingly a regulatory requirement, and always a trust one |
| What happens on failure? | The escalation design, with staffing and hours |
The honest position on readiness
Agentic capability in the Salesforce ecosystem is moving quickly, and the distance between the keynote and the release notes is real. That is not a reason to sit out — but it is a reason to pick use cases where being early is cheap.
A well-scoped agent doing one high-volume job, grounded in content someone owns, with a real escalation path and an off switch, is a genuinely useful thing to have running today. An ambitious agent with broad topics and write permissions, launched to prove the organisation is innovative, is a governance incident waiting for a slow news week.