Salesforce Agentforce is the most consequential platform shift in the last decade for Salesforce customers. Whether your business gets disproportionate value out of it depends almost entirely on the discipline of your implementation, not on the technology itself.
Treat it as an implementation, not a feature
The temptation with Agentforce is to treat it like any other Salesforce feature: turn it on, point it at your org, and expect value. Agents do not work that way. An agent takes actions, draws on knowledge, and makes judgment calls inside your business processes, which means a sloppy rollout does not just underdeliver, it can do the wrong thing confidently at scale. The discipline you bring to the implementation is the whole game.
The good news is that the path is well understood. Agentforce rewards the same fundamentals that every serious AI deployment rewards: a narrow first use case, a clean data foundation, clear guardrails, a real evaluation step, and a plan for continuous improvement after launch. The framework below is the sequence we use to get there.
The six-step Agentforce implementation framework
- 01. Use-case selection: pick agents that can succeed, not the most impressive demo.
- 02. Data 360 (formerly Data Cloud) foundation: get your data right before you build anything on top of it.
- 03. Agent design: define the agent's actions, the knowledge it draws on, and its guardrails.
- 04. Subagent (topic) and instruction development: the prompt and reasoning layer where most of the tuning happens.
- 05. Testing and evaluation: build the harness before you go live, not after.
- 06. Launch and continuous improvement: production is a starting line, not a finish line.
Step one and two: scope and data
The common thread among Agentforce programs that succeed is ruthless scoping at the start. Teams that try to do everything end up shipping nothing. Teams that pick one narrow workflow, ship it, learn from it, and then expand are the ones that end up in production and scaling to a second and third agent. Choose the first use case for its odds of success, not its demo appeal.
Once the use case is chosen, the data foundation comes next, and it cannot be skipped. Agentforce reasons over the data you expose to it through Data 360 and your org. If that data is incomplete, stale, or ungoverned, the agent inherits every one of those flaws and presents them with confidence. Getting the data right, including what the agent is and is not permitted to see, is where the durable quality of the agent is decided.
Step three and four: design and instructions
Agent design is where you define what the agent can actually do. The most common mistake is defining actions too broadly, giving the agent more capability than the use case needs and more surface area to go wrong. Scope each action tightly, define the knowledge sources it draws on, and write explicit guardrails for what it must never do or must escalate to a human.
Subagent and instruction development (Salesforce called subagents topics until April 2026) is the layer where you tune how the agent reasons and responds. This is iterative work. You will write instructions, watch how the agent behaves on real inputs, and refine. The teams that do this well treat it as engineering, with changes that are deliberate and measured, rather than as endless ad hoc prompt tweaking with no way to tell whether a change helped.
Step five and six: evaluation and life after launch
Build the evaluation set before you go live. Assemble realistic test cases from how people will actually use the agent, including the awkward and adversarial ones, and score every change against them. Without this harness you cannot tell whether the agent is improving or quietly regressing, and you certainly should not put it in front of a customer.
Launch is the starting line. Real usage will reveal gaps the test set missed, and an agent that is not maintained drifts and decays. Plan for a cadence of review and improvement, with someone who owns the agent the way an engineer owns a service. Governance belongs in this loop too, designed in from step one rather than bolted on at the end.
Common pitfalls to avoid
Agentforce is not magic. The most common ways to waste budget on it are predictable: skipping the Data 360 foundation, defining the agent's actions too broadly, failing to build the evaluation set before launch, and treating governance as something you add at the end rather than design from the start. Avoid those four and you are most of the way to a deployment that survives contact with real users.
How should you design the Agentforce test set?
Split the test set into groups by what each case is checking, and set a pass bar for each group before you run it. One overall score hides the failures that matter most.
| Test group | What it checks | Pass bar to agree up front |
|---|---|---|
| Core requests | The common questions the agent was built for | The business owner accepts the answer as correct and complete |
| Phrasing variants | The same request worded badly, briefly or with typos | The agent reaches the same outcome as the clean version |
| Out of scope | Requests the agent must decline or pass on | No attempt to answer; a clean handoff or refusal every time |
| Action cases | Requests that should trigger a record change | The right action, on the right record, with the right values |
| Permission cases | Users asking for data they should not see | Nothing outside the user's access appears in any response |
Write the expected result for each case in plain words the business can check. Keep a copy of every run so you can compare scores after each change.
When should an agent hand off to a person?
Hand off when the agent lacks the knowledge to answer, when the request carries real risk, or when the customer asks for a human. Decide these triggers in design, not after the first complaint.
- Pass the conversation summary with the handoff, so the person does not ask the customer to start again.
- Route handoffs through the queues your team already works, such as Omni-Channel, rather than a new inbox.
- Tell the user plainly that a person is taking over and what happens next.
- Tag every handoff with a reason, so you can see which gaps to close first.
What should you review each week after launch?
Review a small, fixed set of signals every week, with the agent's owner in the room. The aim is to spot drift early and decide one fix at a time.
- Handoff reasons, grouped, to see which topics the agent cannot yet handle.
- A sample of full conversations read end to end, not just scores.
- Any action the agent took that a person later reversed.
- New questions that appear often but sit outside the current topics.
- Credit or usage trends against what you expected when you scoped the agent.
Turn each finding into a test case before you fix it. That way the fix is proven, and the same gap cannot quietly return.
How do you grow from one agent to several?
Add the next agent only when the first one is stable and has an owner who is not also building the second. Reuse what you built, rather than starting again.
Shared knowledge articles, test groups, handoff rules and review routines should carry over to each new agent. Widen scope in steps, too. A biotech company we worked with started its agent internal-only on the most common case type and expanded as its knowledge base grew. That agent went on to produce send-ready drafts for 30% of question-type cases.
