How to write effective prompts for Salesforce Einstein and Agentforce

In the demo, someone pastes a paragraph into the chat box. It names the refund policy, the fields to read, and the instruction to hand off if the amount is large. The reply is perfect. The paragraph is then thrown away, because it was a user utterance. The next person types "refund this" and the agent issues the refund, because nothing on the subagent forbade it. The policy was in the demo. It was never in the system.

People say "prompt" and mean the box a user types into. For Agentforce, that box is the least durable text you have. The next person will not paste your carefully staged paragraph. They will say "where's my order" and expect the same policy the demo appeared to have.

The Atlas Reasoning Engine breaks the initial prompt into smaller tasks, evaluates each step, and proposes a plan until it reaches an answer or an action. If the only text you edit is the user's sentence, you are tuning an input you do not control. The instruction on the subagent is the prompt that is present every time. Write that. Test that. Stop polishing the utterance.

#What to write in the instructions

Write a specification. Name the objects the agent may read. Name the single action it should call for this job. Name the inputs it must have before the call. Name the stop, in the form of a record or a missing fact, not a mood. "When the customer seems satisfied" is a mood. "When the action returns a Case Id and the required fields are filled" is a stop. The plan can see the second one. It will talk through the first.

Then write the refusals in the same instruction, not in a wiki nobody attached to the agent. Do not change Opportunity StageName. Do not close the Case. Do not discuss symptoms, medicines, or results. Do not promise a time that is not already on the record. If the running user cannot see the record, say so and stop. Do not guess a status to fill the silence. A refusal that is implied by the team's culture, and absent from the instruction, is a refusal the plan has not been given.

"Be concise and on brand" does not choose an action. It changes the length of a sentence that may still be the wrong action. Keep the instruction shorter than the sources it relies on. Pasting the refund policy into the instruction creates a second copy that will go stale. The maintained article is the source. The instruction says what to do when retrieval returns nothing, or when two articles disagree: stop and hand off. Do not pick the friendlier paragraph. The friendlier paragraph is how a retired exception survives in the channel that sounds the most reasonable.

One action per job is part of the specification. If the instruction says "update the Case or create a Task or draft a reply, whichever helps", the plan has three legal finishes and will sometimes take all of them. Whichever helps is a mood. Name the action for the kind of request, and name the finish. A library that has grown past one job is no longer a prompt problem. It is a copilot that needs to be split. The instruction cannot compensate for a library that contains the wrong writes.

#Grounding beats a longer prompt

Agents answer from trusted business data, CRM records, and external data from Data 360, formerly Data Cloud. Salesforce rebranded Data Cloud to Data 360 on 14 October 2025, and you may still see the old name. The name is not the issue. When that data is wrong, split, or invisible to the running user, the plan can still finish. A longer prompt asks it to finish more eloquently. Eloquence is what makes the miss expensive, because the customer, or the employee, believes the paragraph.

You can see this failure in the trace. The right object was never retrieved, and the reply still sounds sure. Adding "only use approved sources" does not create a source the user is allowed to see. Adding "if you are unsure, say so" does not fire when the plan is not unsure. A wrong article is retrieved completely. The plan is sure. It should be sure. The article is what it was given. The fault is the article, the sharing, or the identity, and the prompt is the wrong tool for all three.

Fix those, then stop editing the prompt. The sequence for that work sits in Agentforce implementation best practices, and the checks that tell a retrieval miss from a bad paragraph are in the grounding checklist. Once the trace shows the right record was never fetched, further adjectives are wasted. They will be applied to the same miss.

The same limit applies to an Einstein prompt beside the agent. Telling a generation or a score to be accurate does not repair the Opportunity history it learned from, or the field it retrieved. A prompt that says the score is usually right makes the sentence more confident and the history no fairer. State the action, the stop, and the refusal. Do not ask the prompt to compensate for data. Compensation is how a biased score reaches a person looking like a judgement.

#Say what the agent must refuse

Refusals are the part teams leave implied, and the part that fails in production. The demo user pasted the policy into the utterance. The real user did not. The agent then did the consequential thing, because nothing on the subagent forbade it. The demo was a test of a user who already knew the rules. Production is a test of a user who does not, and who is allowed not to.

List refusals as behaviour, and test them without the policy in the user message. A refund request, with no policy text in the utterance, must hand off. A symptom mixed into a booking must hand off the clinical part and must not comment on the symptom. A request to move a stage must not write StageName. A request for a record the running user cannot see must refuse, not summarise. If the agent only behaves when the policy is pasted into the utterance, the refusal is not real. It is a property of the demo script.

Also refuse to be helpful past the stop. A second search after the record Id is already known is the plan ignoring you. Treat it as a failed test, even when the second search returns the same record and the reply is unchanged. The extra step is how a later edit starts to create a second Case "to be sure". Salesforce's own standard is escalation when the issue is beyond scope. Your refusals are how you define that scope in words the plan sees on every turn. A scope that lives in a principles document, and not in the instruction, is a scope the plan does not have.

Write the refusal next to the action it constrains. "Do not close the Case" belongs beside the action that would close it, not in a preamble about being careful. Careful is a mood. A named field is a constraint. The same standard you would apply to a Flow decision element applies here, which is why a step with a right answer belongs in Flow or Apex and the instruction should point at that step rather than restating it. Restating it is how you grow a second copy.

#How a prompt edit goes wrong

Three edits look like improvements and are not.

The adjective edit. The reply was blunt, so someone adds warmth. Warmth wraps the same action. If the action was wrong, the customer now receives a wrong action that sounds like the brand. Read the steps before you edit the voice. Voice is the last change, and only after the trace is stable.

The pasted policy edit. A refund was wrong, so the policy is pasted into the instruction. The channel behaves until the policy changes in the article and not in the instruction. You now have two policies, and the agent is quoting the one nobody maintains. Point at the article. Tell the instruction to stop when retrieval is empty or contradictory. Delete the pasted text.

The example edit. Someone adds three sample utterances that happen to include the right slot, the right tone, and the policy. The plan imitates the examples, including on utterances that do not look like them, and it imitates a slot the real user did not provide by inventing one. Examples are not a specification. If you keep one, keep it beside the rule it illustrates, and re-run a utterance that does not resemble it.

#How to tell the prompt is finished

Run a small set of real requests twice: once as a user who can see the record, once as a user who cannot. Read the plan. Right action, right Id, stop, no forbidden write. Include one utterance that is only the customer's request, with none of your policy in it. Include one that should retrieve nothing. The pass on the empty retrieval is a handoff or a sentence that says nothing was found, and a trace with no invented status.

Then change nothing in the user utterance and edit only the instruction until that trace is stable. Policy lives in the instruction and in the source. The user's sentence is just the request. When the set passes, stop. A further edit that only improves the prose is an unforced change to a plan you have already accepted, and unforced changes are how a finished prompt becomes a second specification of rules that already live somewhere else.

Re-run the table when the library gains an action or the source articles change. The prompt is finished for this week. It is not finished for the life of the org. Finished means the trace matches the table. It does not mean the paragraph has been praised in a meeting.