One practice per minute. Four areas: Design, Instructions, Actions and Data, Ship and Monitor. Every one of these comes from shipping agents and watching them break.

20 Agentforce Best Practices in 20 Minutes | SF Bolt

These are not generic tips. Every one of them comes from actually shipping agents and watching them break in ways nobody warns you about. Twenty practices. Four areas. One practice per section below.

Section 1 · Practices 1–5

Design

Five things to decide before you even open the Builder

01Design

Decide what your agent should do — before you build anything

Write one simple sentence about what you want your agent to actually do. That sentence decides everything else you build after it.

Wrong

An agent for customer service.

Right

Resolve order status and refund requests for verified customers without human escalation.

02Design

Know where your agent needs to work — before you decide what kind it is

Agentforce has multiple agent templates and you need to pick the right type before building anything. An Employee Agent works inside Salesforce, on your phone, and in Slack. A Service Agent works in customer-facing chat, email, and phone. Pick the wrong one and you don't get to tweak it later — you have to start over.

Wrong

Build a Service Agent, then try to deploy it to the team's Slack workspace.

Right

Build an Employee Agent from the start, since Slack only accepts that type.

03Design

Don't give your agent too many jobs at once

Every subagent and action you add is something the router has to weigh on every single turn. A small, focused list routes cleanly. A crowded one slows responses and raises the odds the router picks the wrong subagent entirely.

Wrong

One agent handling Order Lookup, Refunds, HR Leave Requests, IT Password Resets, and Marketing FAQs.

Right

One agent handling only Order Lookup and Refunds — the two things it was actually built for.

04Design

Write descriptions for the computer, not for a person reading it later

Every subagent has a description field. That field is read by the agent to decide who should handle a given request. Write it accordingly.

Wrong

Order management.

Right

Handles order lookup, refunds, and order updates for verified customers.

05Design

Hide options from your agent instead of just asking it nicely

Don't write a business rule as plain text and hope the model enforces it every time. Encode it directly as deterministic Agent Script logic using available when — so the platform enforces it, not the model's reading of a sentence.

Wrong

Written in plain instructions: "Only show the refund option after the customer is verified."

Right

The refund option gated with available when, so the platform enforces the rule — not the model's reading of a sentence.

Section 2 · Practices 6–10

Instructions

Five practices for how you actually write instructions

06Instructions

Use a strict rule for important steps, let the AI phrase the rest

For anything where a mistake actually matters — like booking something or moving money — write it as a fixed rule in Agent Script.

Agent Script — deterministic booking step

if @variables.ready_to_book:
    run @actions.get_account_info
    with account_id = @variables.account_id
    set @variables.hotel_code = @outputs.hotel_code

True story: I once let the model decide, in its own words, exactly when to trigger a booking. It was right most of the time — which sounds fine until you remember that "most of the time" is a genuinely terrifying phrase to hear about something that charges a credit card.

07Instructions

Point directly at the thing you mean, don't describe it in a roundabout way

Name your subagents, actions, and variables directly using the @ symbol instead of describing them as plain text.

Wrong

Refer to the user by their name. If they seem upset, transfer them to a person.

Right

Refer to the user by name @variables.member_name. If they ask for a service agent or seem upset, use @actions.go_to_escalation.

08Instructions

Make sure nothing you tell your agent contradicts something else you told it

Check the main instructions, each subagent's instructions, action descriptions, and knowledge content for conflicts. Contradictions don't cause errors — they cause unpredictable behaviour.

Wrong

System instruction: "be concise." Subagent instruction: "explain thoroughly."

Right

One consistent rule stated once, at the layer that actually follows it.

09Instructions

Store information in a labeled box instead of repeating it in a sentence

When your agent looks something up, save it into a variable. Save the values you may need later in the conversation — don't rely on the model to remember them.

Agent Script — save action output to variable

run @actions.GetOrderByOrderNumber
with order_number = @variables.order_number
set @variables.order_details = @outputs.orderDetails

True story: I used to just hope the agent remembered the order number from three messages earlier. It did not. It asked the customer for it again, then again — like a very polite goldfish.

10Instructions

Know which of your instructions the agent actually reads, before you edit them

Instructions on a subagent only matter if that subagent is actually reached in the conversation. Before refining wording, check the resolved prompt for a real turn and confirm the instruction is even part of it.

Wrong

Spent an hour refining the tone of the Escalation subagent's instructions, assuming it applies broadly.

Right

Checked the resolved prompt for a real turn, and found the Escalation subagent is only reached after three failed attempts — so that tone rarely shows up at all.

Section 3 · Practices 11–15

Actions and Data

Five practices about what your agent actually does and what it is allowed to know

11Actions and Data

Know the difference between a deterministic step and a step where the AI is guessing

A Flow, an Apex method, or an API call does the same thing every time. A prompt template can come out slightly different each time. Use the correct mechanism for the requirement.

Wrong

A prompt template calculates the account balance.

Right

A Flow looks up the account balance directly from the record.

12Actions and Data

Ground answers in curated data, never in model knowledge

Every fact your agent states should come from an actual record or article you control — not from what the AI already "knows." Model knowledge cannot be updated, verified, or audited.

Wrong

The agent states the refund policy from its own training knowledge.

Right

The agent states the refund policy pulled from your actual Knowledge Article.

13Actions and Data

Confirm who someone is before letting your agent do anything sensitive for them

Gate sensitive actions behind a real verification step using the standard Verify Customer action — not an instruction telling the model to be careful.

Wrong

"Can you confirm your email?" followed by any typed response, accepted as proof.

Right

The standard Verify Customer action, with an actual one-time code check.

True story: Early on, my agent treated "can you confirm your email" followed by literally any typed response as identity verified. Someone could have replied "banana" and gotten straight through.

14Actions and Data

Use Custom Lightning Types instead of narrated text

When an action returns structured data, render it as a Lightning Web Component instead of letting the model read every field aloud as one long sentence. Use complex_data_type_name to link the output to the Lightning type, and is_displayable to tell the platform to render it.

Wrong

The model reads every field aloud as one long sentence.

Right

A clean Lightning Web Component card renders with all information structured and scannable.

15Actions and Data

Connect outside tools the official way, not with your own custom shortcut

A callout you write yourself has no visibility for the rest of the team, no risk assessment, and no central way to revoke access later. Agentforce Registry gives you all three in one step.

Wrong

A private Apex callout to a shipping API, visible only in the code, with no record of what it can reach.

Right

The same shipping API registered as an MCP server in Agentforce Registry, with a Risk Score and centrally controlled access.

Section 4 · Practices 16–20

Ship and Monitor

The last five — what happens after your agent looks finished

16Ship and Monitor

Test your agent properly — don't just try it once yourself and assume it works

Preview is one path, one phrasing. Testing Center runs many phrasings automatically and scores every run. Those are completely different levels of coverage.

Wrong

Five polite, well-worded questions tried once in Preview.

Right

Dozens of phrasings run automatically through Testing Center, scored every time.

17Ship and Monitor

Re-test after any change to any part of the solution

Any change at all should trigger a full re-test — not just a glance at the specific thing you changed. Agents are interconnected. A small knowledge edit can change routing behaviour in a subagent you didn't touch.

Wrong

"Just a tiny knowledge edit, no need to re-test."

Right

Every change, however small, triggers a full re-test.

18Ship and Monitor

Check what your agent is allowed to see, separately from what you are allowed to see

You test as an administrator with access to everything. The deployed agent runs as its own separate user. Those are not the same permissions. Check the Einstein Service Agent user's permissions independently.

Wrong

Tested while logged in as an admin, who can see every field.

Right

Checked the actual Einstein Service Agent user's permissions separately.

True story: My agent worked flawlessly for two straight days of my own testing. Then a real user tried it and it failed instantly — because I was logged in as an admin who can see everything, and the agent, running as its own actual user, could see almost none of it.

19Ship and Monitor

Turn on observability before you go live, not after an incident

Once an agent is live, a bad conversation leaves no trace unless tracing was already on. Session Tracing, Agent Analytics, and Agent Health Monitoring need to be part of the deployment checklist — not a reaction to a complaint.

Wrong

An agent goes live. Three weeks later a customer complains about a bad interaction, and there is nothing to review.

Right

Session Tracing, Agent Analytics, and Health Monitoring are already on before the very first real conversation happens.

20Ship and Monitor

Refine from real transcripts, not from assumptions

Use actual conversation transcripts and real user feedback to decide what to fix. Your test questions are phrased the way you think about the problem. Real users phrase it completely differently — and that gap is where most failures live.

Wrong

Test questions written by you, in your own words.

Right

Real user transcripts, in their actual words.

All Twenty — In Four Lines

Design: Decide what your agent should do, and keep its toolset small.
Instructions: Turn important steps into fixed rules, and point at things by name.
Data: Only let the agent state facts you can back up with a record you control.
Ship: Check how it behaves before it goes live — not after something breaks.

If you only remember one thing from all twenty: fewer tools, clearer descriptions, and real approved information will fix more problems than any amount of rewording your instructions.