Prompt & system prompt
The full input sent to an LLM: instructions, examples, retrieved context and the user's message. The main lever for controlling behaviour.
A prompt is everything you send to the model in one request. In a real product that is far more than the user's question: a system message describing the job and the rules, a few worked examples, documents fetched by retrieval, and the conversation so far.
The answer depends heavily on this text, so writing, versioning and testing prompts is engineering work, not wordsmithing.
A brief handed to a very capable contractor who has never met you: everything they need to know has to be written on the page.
Iterating by eyeballing five outputs. Without a golden set, the fix for one case silently breaks others, and you find out from users.
Chat APIs take role-tagged messages (system, user, assistant, tool results) and serialise them with special tokens into one sequence. Reliable prompts separate concerns: role and task; rules and output format; grounding context in clearly delimited blocks with source ids (XML-style tags work well); and 3–5 examples chosen to cover edge cases, not easy cases.
Order is a cost decision. Stable content (instructions, tool schemas, examples) goes first so it can sit behind a Prompt caching breakpoint; volatile content (retrieved chunks, the question, timestamps) goes last. Untrusted text, including retrieved documents and tool output, is data, never instructions, because of Prompt injection (indirect). A prompt is code: it lives in git with a version id (Prompt versioning), and every change runs the Eval harness against a Golden set before it ships behind a Canary & ramped rollout.
System prompt in git with a version id logged on every request; sections for role, task, rules, output schema; retrieved context in XML-style tags with ids; 3–5 edge-case examples; stable content before one cache breakpoint; provider structured outputs instead of 'please return JSON'; a 200-case golden set run in CI on every prompt change.
Insurance claims triage. System: 'You classify first notice of loss reports. Use only the clauses inside <policy>. Return JSON matching the schema. If the policy does not mention the peril, set covered to "unknown".' Then <policy><clause id="HO-7.2">Sudden and accidental discharge of water is covered; gradual seepage is excluded.</clause></policy>, then <claim>Ceiling stain growing for three months under the upstairs bathroom.</claim>. Expected output: covered = false, reason 'gradual seepage', citation HO-7.2. The 6,500 stable tokens sit before the cache breakpoint; the ~600-token claim and clauses after it.
Treat prompts as deployable artifacts: versioned, eval-gated on a 200+ case golden set, rolled out to 5% first, with instant rollback. Say how you structure them for caching (stable prefix, volatile suffix) and for injection safety (untrusted content delimited and never given tool authority). The follow-up is 'how do you know a prompt edit helped?': a paired comparison on the same golden set with a confidence interval, not a handful of eyeballed outputs.
Numbers worth knowing
- Accuracy swing from a one-line instruction edit
- ±1–5 pointsrange seen on 200–500 case golden sets; measure it, never assume zero
- Few-shot examples
- 3–5gains flatten beyond ~8 while tokens keep costing on every call
- Minimum golden set to detect a 3-point change
- ~400–500 casespaired comparison, baseline accuracy ~85%, 95% confidence
How to decide
| When | Do this |
|---|---|
| Output is parsed by code | Use provider structured outputs or Structured output / decoding, not format instructions alone. |
| The static prefix is over ~1k tokens and reused within 5 minutes | Put a cache breakpoint after it and move every volatile field below it. |
| The prompt includes retrieved or user-supplied text | Delimit it, label it as data, and never let it select or authorise tools. |
| A prompt exceeds ~8k tokens of instructions and examples on a high-volume route | Consider Fine-tuning the behaviour in and shrinking the prompt. |
Cost maths
Instruction cost = static_tokens × calls × p_in. Assume $3 / M input (illustrative). A 6,500-token static prefix × 1M calls/month = 6.5B tokens = $19,500/month uncached. With caching at 0.1× reads and, say, 95% hits: 6.5B × (0.95 × 0.1 + 0.05 × 1.25) × $3 / M ≈ $3,070/month. Shortening the prefix by 2,000 tokens saves another ~$940/month cached, or $6,000 uncached.
Operating it
- More than one team edits the same prompt
- Prompt changes ship more than weekly
- Golden-set run takes longer than the review cycle and gets skipped
- Format-violation rate per prompt version: alert above 1%
- Judge score delta vs previous version on sampled traffic: alert at −2 points
- Cache hit rate on the static prefix: alert below 70%
When it goes wrong
Product-spec answers on an e-commerce catalog assistant stopped citing sources: citation compliance fell from 97% to 81%.
Nightly LLM-as-judge sampling of 500 production answers, two days after the change.
A 'be concise, skip preamble' edit was merged without a golden-set run; the model read citations as preamble.
Prompts became versioned artifacts with a CI eval gate (block on −2 points on any slice), 5% canary for 24 hours, and a one-click rollback by version id.
Related terms
Where it shows up
Sources
- Prompt engineering overview — Anthropic, 2026docs
- Not what you've signed up for: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection — Greshake et al., 2023paper
Check yourself
Three questions. Every option is explained once you answer.