Skip to main content

System prompts and instructions: steering the model on purpose

The steering part of the context, written on purpose: system-prompt anatomy — role, task, boundaries, output format — and why system content sets a stronger foundation than the user turn. The techniques that actually hold: be clear and direct, give the model the why behind a rule, show worked examples (few-shot), let it reason out loud for multi-step work, and decompose a too-big task into a chain. Stated honestly: a model cannot think privately, so reasoning only helps if it is allowed to output it. Every change scored against an eval set (principle 3) — structure and ordering beat volume.

Reference·Last updated 2026-06-03·Drafted by Lira · Edited by German Medina

A capable model with a vague instruction is a smart employee handed a one-line brief and left to guess the rest. It will do something — fluent, confident, and only sometimes the thing you meant. The fix is not a stronger model; it is writing the steering part of the context on purpose. This page is about that part: the system prompt and instructions that tell the model who it is and what it is doing, and the techniques that reliably hold it on task. Vague instructions are the single biggest cause of a model that wanders — the same lesson the platform-native side learns through Agentforce Instructions (see Agentforce agents), here at the level of the raw prompt.

This is a reference, not a recipe. The techniques below are the ones that hold up across tasks; which ones a given task needs, and how much, is what an eval set decides (principle 3 — if you can't evaluate it, you can't ship it). The throughline under all of them: structure beats volume. More rules is not more control.

The system prompt versus the user turn

Most model APIs separate two kinds of input: the system prompt and the user turn. They are not interchangeable, and the difference is worth getting right before any technique.

The system prompt is where you set the durable frame — who the model is acting as, what it is for, what it must not do, and the shape its answers take. It is the standing instruction that holds across every turn of a conversation. The user turn is the specific request this time — the question, the document, the task instance. The split maps cleanly: stable steering goes in the system prompt, the variable input goes in the user turn. System content sets a strong, consistent foundation for behavior precisely because it is not re-litigated on every message; it is the frame the user's request arrives into.

Putting steering in the wrong place is a common, quiet mistake. Bury the role and the rules inside each user message and you repeat them forever, drift between phrasings, and dilute the request they are wrapped around. Lift them into the system prompt once and every turn inherits the same frame for free.

System-prompt anatomy

A system prompt that holds up has four parts. Name them and you can debug a wandering model by asking which part is thin.

  • Role — who the model is acting as. "You are a support assistant for a B2B billing product" is not flavor; it sets the register, the assumed knowledge, and the defaults for everything after. A model with no role assumes a generic one and answers like the open internet.
  • Task — what it is doing, concretely. Not "help the user" but "answer billing questions from the retrieved account record, and resolve disputes up to the limit in your instructions." The task is the spine the rest hangs on.
  • Boundaries — what it must not do, and when to hand off. The refusals, the out-of-scope topics, the point where it stops and routes to a human. This is the same discipline as an agent's boundaries — a model with no stated edges treats every request as in-scope (it ties to principle 8: non-determinism needs a human gate where it is customer-facing).
  • Output format — what shape the answer takes. A sentence, a JSON object, a bulleted list, a specific structure. Stating it here is the difference between an answer you can parse and one you have to wrestle (the full mechanic is its own page — structured output).

These four are a checklist, not a fixed template. The point is coverage: a prompt missing its boundaries produces a model that never declines; one missing its output format produces answers in a different shape every time.

Be clear and direct — and say why

The highest-frequency prompting fix is the least clever: say exactly what you want, in plain instructions, and tell the model why the rule matters. Explicit beats implicit, and direct beats ornate. A model is not rewarded for reading between your lines — an instruction it has to infer is one it can infer wrong.

Two moves carry most of this.

  • Be clear and direct. Prefer a plain imperative — "answer in two sentences," "do not mention pricing," "cite the record you used" — over a hint the model has to decode. Vague phrasing ("be helpful and concise") leaves the model to guess what concise means here, and it guesses differently every run. Precision in the instruction is precision in the output.
  • Give context and motivation. Telling the model why a rule exists measurably improves how well it follows it. "Do not give legal advice — you are not a lawyer and a wrong answer here has real consequences for the user" holds up better than the bare "do not give legal advice," because the model can now generalize the intent to cases your rule did not enumerate. The why turns a brittle list of dos and don'ts into something the model can reason from.

This is the same failure the Agentforce agents page names from the platform side: vague Instructions are the number-one cause of an agent that wanders off task. At the raw-prompt level the cure is identical — explicit instruction, stated motivation.

Few-shot: show, don't just tell

For any task with a consistent shape, the single highest-leverage technique is few-shot (also called multishot) prompting: include a couple of worked input→output examples right in the prompt. Examples do what prose struggles to — they pin down format and reasoning at once, by demonstration rather than description. A model shown two examples of the exact output you want will match it far more reliably than one told, in words, to produce it.

Examples earn their place fastest on tasks where the shape of a good answer is hard to describe but easy to show — a particular extraction format, a house style for a summary, a classification with non-obvious edge cases. Two or three well-chosen examples often outperform paragraphs of instruction, because the model generalizes from the demonstration instead of parsing a specification. Keep the examples representative (cover the cases that vary, including a tricky one) and consistent (every example obeys the format you are asking for — an inconsistent example teaches inconsistency).

# A couple of worked examples pin the format the prose can only gesture at.

Input: "My card was charged twice for invoice 4471."
Output: { "category": "duplicate_charge", "invoice": "4471", "needs_human": true }

Input: "How do I download last month's receipt?"
Output: { "category": "self_service", "invoice": null, "needs_human": false }

Notice the second example carries a null and a false — it is there precisely to show the shape when fields are absent, which a single happy-path example would leave the model to guess.

Chain of thought: room to reason

For analysis and multi-step work — anything where the answer depends on a chain of reasoning, not a lookup — give the model room to reason before it answers. This is chain-of-thought prompting: "think step by step," a set of guided steps to work through, or a dedicated reasoning section the model fills before its final answer. Reasoning out loud measurably improves accuracy on math, logic, and multi-constraint tasks, because the model works the problem instead of leaping to a conclusion.

One point has to be stated accurately, because the framing is easy to get wrong: a model cannot think privately. Its "reasoning" is just more output tokens — text it generates on the way to the answer. There is no hidden scratchpad it computes in and then discards. So chain-of-thought only helps when the reasoning is allowed to be output. Asking a model to "think carefully but only show me the final answer" gives you neither the benefit of the reasoning nor a way to check it — you have told it to do the helpful part and then throw it away. If you want the reasoning's accuracy gain, let the reasoning land in the response; if you do not want it cluttering the final answer, separate it rather than suppress it.

The clean way to separate reasoning from answer is to give each its own tagged section, kept in a fenced block so the angle brackets stay out of the prose:

Think step by step inside <thinking> tags, then give your final answer
inside <answer> tags. Only the <answer> content is shown to the user.

<thinking>
... the model works the problem here, and this is real output, not hidden ...
</thinking>
<answer>
... the final, user-facing answer ...
</answer>

That pattern keeps the accuracy gain (the reasoning is genuinely produced) while letting your code show only the <answer> section downstream. It is honest about the mechanic: the thinking is output you choose to hide from the user, not thinking the model did in secret.

Decomposition: chain the prompts

Some tasks are too big for one prompt to do well. A request that bundles three distinct jobs — extract, then transform, then format — into a single instruction tends to do each one worse than a prompt focused on it alone, because the model splits its attention and the instruction set bloats. The fix is decomposition, also called prompt chaining: break the task into smaller prompts, each doing one thing, and feed the output of one into the next.

A chain trades a little orchestration for a lot of reliability. Each step is now simple enough to instruct precisely and to evaluate on its own, and a failure is localized to one link instead of smeared across a monolith. This is the deterministic shape from the orchestration patterns page seen from the prompting side — a chain is a fixed sequence you control, distinct from handing the whole job to one agent and hoping it sequences the steps itself. When a single prompt is straining to hold too many instructions, decomposing it is usually the move before reaching for anything more elaborate.

The discipline, restated

The techniques differ, but the rule under all of them is one sentence: every change to a prompt is scored against an eval set, not eyeballed (principle 3). "It reads better" is not a measurement — a clearer-sounding instruction can quietly lower accuracy, an extra example can pull the model toward the wrong shape, and you will not know which without a set of cases that scores it. The other half of the discipline is that structure beats volume: a model is steered by the salience and ordering of what you tell it, not the sheer amount, and past a point more rules dilute the ones that matter (principle 10 — context is a budget, not a bucket). So the question before you add another paragraph to a prompt is the same every time — does the eval show this earns its place, and is it placed where the model will actually weight it. Get that right and the prompt stays small and sharp. Get it wrong and you grow a wall of instructions nobody can change. (See prompting gotchas for the ways this goes wrong in production, and what is context engineering for where the steering sits inside the whole context the model sees.)

Related

Reference: