--- title: "Agentforce conversation design" url: "https://trailassembly.com/agentforce-conversation-design/" topic: "Agentforce and AI" published: "2026-09-19T10:50:22+00:00" updated: "2026-10-06T13:58:52+00:00" --- # Agentforce conversation design **The short version:** conversation design is mostly three decisions. How much the agent asks before it acts, whether it confirms a consequential action before performing it, and what it does on the turn after it gets something wrong. Teams spend their design time on greeting copy and persona, which is the part that matters least. The recovery turn is the part users judge you on. ## Turn-taking: ask less than you want to The instinct is to gather everything up front. Order number, email address, product, symptom, then act. That is form-filling with extra steps, and users abandon it. The better shape is to act on what you have and ask only for what blocks progress. If the user is authenticated and has one open order, do not ask which order. If they have four, ask once, with the four listed, so the answer is a selection rather than a recall exercise. A rule that holds up: never ask for something the org already knows. A question that could have been a lookup tells the user the agent is not connected to anything. The opposite failure is real too. An agent that acts on an ambiguous request and gets it wrong has spent more of the user’s time than one that asked. The dividing line is reversibility. Guess freely when the cost of guessing wrong is a follow-up sentence. Ask when the cost is a cancelled order. ## Confirmation before action Any action that writes, sends, cancels, refunds or notifies a third party gets a confirmation turn. Not a vague one. State the specific values and wait. Weak: ```apex Shall I go ahead and make that change? ``` Strong: ```apex I'll change the delivery address on order 4471 to 14 Mill Lane, Bristol, BS1 4TR. Delivery moves to Friday. Confirm? ``` The second version lets the user catch the mistake the agent has already made in its interpretation, which is the actual point of the confirmation. It also gives you a transcript line showing exactly what was agreed, which the first version does not. Two things to avoid. Do not confirm reads. Asking permission to look something up is noise. Do not accept an ambiguous yes to a compound proposal. If the agent proposed two changes, confirm them separately or expect to do the wrong half. ## Recovery is the design The agent will misunderstand. Plan the turn after that, because everything users hate about agents lives there. The loop is the failure mode to design out. Agent misreads, user rephrases, agent misreads adjacently, user rephrases with less patience. Nothing in the model stops this on its own, so put a counter on it. After two failed attempts at the same intent, stop trying. Offer the human. Other recovery rules worth writing into instructions: - **Do not re-ask a question the user already answered.** If the answer is in the transcript and the agent asks again, the user concludes it is not listening, and they are right. - **Acknowledge the correction explicitly.** “You meant the March invoice, not February” before continuing. It costs a clause and it repairs a lot. - **Never blame the user’s phrasing.** “I didn’t understand that” is fine. “Please rephrase your question” three times is a design that has given up and made it the user’s problem. - **Keep the escape hatch open on every turn.** “Talk to a person” should work from anywhere, in whatever words the user uses, including rude ones. ## Things worth less than people think Persona. A name and a personality paragraph change very little about whether the agent completes tasks, and a strong persona makes failures more jarring, not less. Keep it plain. Long greetings. The first message should say what the agent can do and what it cannot, in two sentences, then get out of the way. A scope statement up front prevents more bad conversations than any instruction further down. ## Testing the design rather than the model Write your test cases as conversations, not single utterances. Include an interruption mid-flow, a correction after a confirmation, a user who answers a different question than the one asked, and a user who types nothing but “no”. Single-turn testing tells you the classifier works. It tells you nothing about whether the conversation does. ## Frequently asked **How long should a conversation be?** Shorter than you expect. If a task routinely takes more than five or six turns, the task probably wants a form with the agent alongside it. **Should the agent remember previous sessions?** Only if the user would expect it to and the data supports it. Half-remembering is worse than starting fresh. **Can instructions guarantee the confirmation always happens?** No. Instructions are followed most of the time, not always. If a confirmation is genuinely mandatory, enforce it in the action itself. --- Source: https://trailassembly.com/agentforce-conversation-design/ Trail Assembly — independent Salesforce write-ups.