Agentforce brand voice: set the tone and test difficult conversations

An agent can resolve the case and still sound like a support macro nobody wanted to send. Repeated apologies, long answers, and unnatural formality can make a correct response hard to read.

Start by checking the controls for your version of Agentforce Builder. Then write a short voice specification and test it against the conversations that put it under pressure. A label such as “friendly” is a starting point; a transcript shows whether the result fits your customers.

Check which builder you are configuring

Salesforce’s language settings documentation distinguishes the current builder from the legacy builder. The legacy Language Settings tab offers Formal, Neutral, and Casual tone choices, with Casual as the default. Restart the preview conversation after changing those settings.

For the current builder, the same page describes Settings → Languages for default and allowed languages, with adaptive language mode marked beta. Don’t assume the legacy tone dropdown appears in the same location. Follow the controls documented for your agent type and builder.

Use the language configuration to establish the languages you intend to support. Then review the agent and subagent instructions that shape responses. Keep a record of where voice guidance lives so future editors don’t add a conflicting instruction in another part of the agent.

Salesforce’s instruction-writing guidance explains the nondeterministic nature of natural-language instructions. They influence behavior; they don’t provide the same enforcement as application logic.

Describe a response a reviewer can recognize

Replace vague adjectives with observable behavior. “Professional and empathetic” leaves substantial room for interpretation. “Acknowledge the reported problem once, then give the next useful step” lets a reviewer judge a transcript without guessing what the writer intended.

For example, a support agent’s draft voice instructions could read:

Answer the customer's question in the opening sentence when the
available information supports an answer.

Use the product and field names the customer sees in the application.
Explain an unfamiliar term when it is needed for the next step.

For an error, acknowledge its effect briefly, explain the verified
next action, and say what information is still missing.

When approval is pending, describe it as pending. Confirm a refund
only after the refund action reports success.

These are example instructions to evaluate in your own agent. They aren’t a promise that every response will follow them, and the final line doesn’t replace the refund action’s authorization checks.

Keep two or three examples of approved responses alongside the specification. Include a refusal, an unresolved request, and a successful transaction. A brand voice has to work when the agent has little useful information to offer.

Separate presentation from permission

A tone instruction can ask for a calm explanation. Your Flow or Apex action should check whether the caller can see the record and whether the requested operation is allowed. Changing the wording of the reply must not change eligibility for a refund or access to customer history.

Use Agent Script where the supported control flow needs an explicit sequence or condition. Keep authorization and data validation inside the action or service that performs the work. Test the combined path, including failures returned from downstream systems.

Required wording deserves an explicit rendering and testing plan. Don’t assume mentioning a disclaimer in an instruction guarantees verbatim delivery on every channel. Check the actual output, and use a supported controlled response mechanism when exact text is necessary.

The Einstein Trust Layer and other safety controls address different risks from brand voice. Their presence doesn’t prove that a response is accurate, appropriate, or on-brand. Evaluate those properties separately.

Read the conversations that cause drift

Build a small regression set with an angry customer, a short factual question, an ambiguous request, a topic change, and an action that fails. Include a long conversation so the review isn’t limited to the first reply.

Grade observable criteria: whether the opening answers the question, whether an apology repeats, whether the next step is clear, and whether the agent claims an action succeeded before the system confirms it. Preserve examples of pass and fail decisions so reviewers apply the same standard.

For multilingual agents, have a fluent reviewer check each supported language. A literal translation of an English example may be grammatical while sounding abrupt or excessively formal.

Run the same set after changing instructions, actions, models, or response formats. Use your agent testing process to retain the transcripts and the agent version. A voice improvement is worth keeping when it survives difficult cases without weakening factual accuracy or the action boundary.