System Prompts & Personas: Rules That Hold Across Every Turn

When a new employee joins a shop, you don't re-explain the shop to them before every customer. You brief them once — who we are, how we speak to people, what we never promise, when to call the manager — and then they handle customers one at a time.

The system prompt is that briefing. Everything you've learned so far applies to this request; the system prompt applies to every request, forever, until someone edits it. Which makes it the highest-leverage and highest-risk text in your application.

System vs user prompt

response = client.messages.create(
    model=MODEL,
    system="You are ShopKart's support assistant. ...rules...",   # every turn
    messages=[
        {"role": "user", "content": "Where is my order ORD10024?"} # this turn
    ],
)

That last row is the practical reason the separation exists. Models are trained to treat system instructions as the operator's standing configuration, so "never quote a delivery date you weren't given" survives a user insisting otherwise far better in the system slot than glued onto each message.

What belongs in it

• Identity — what this assistant is and what it covers.
• Scope — what it should decline, and what to say instead.
• Tone and register — stated as observable rules, see below.
• Grounding rules — "use only the facts in the CONTEXT block; if a detail is missing, say so".
• Default format — length caps, list rules, whether emoji are allowed.
• Escalation — the exact sentence to produce when a human must take over.

What does not belong: anything about this particular request (that's the user turn), and anything secret. More on the second in a moment.

Adjectives aren't specifications

Nearly every weak system prompt fails the same way. It is a list of adjectives.

You are a helpful assistant. Be polite and professional.
Answer questions well. Be concise but complete.

"Concise" means 40 words to one person and 400 to another, so the model picks an average — a different average each time, which the team experiences as "inconsistent".

Answer in at most 4 sentences. If the answer is a process, use a
numbered list of at most 5 steps instead.
Never state a delivery date, refund amount or order id that is not
in the ORDER block.
For payment disputes or legal notices, reply exactly:
"Let me connect you to a human agent." and stop.
No emoji. Do not apologise more than once in a reply.

If a reviewer can't check whether a rule was followed, the model can't either. Anything countable — sentences, steps, forbidden phrases, exact escalation wording — actually constrains behaviour. Adjectives decorate.

Personas — and what they can't do

"You are a patient teacher." "You are a strict code reviewer." A persona is a compact way to set vocabulary, depth and what the answer assumes the reader knows.

The trap, repeated from lesson 2 because interviewers keep testing it: a persona changes register, not knowledge. "You are a senior tax consultant" does not unlock tax expertise the model lacks — it makes uncertain answers sound authoritative, which is a net negative if you were hoping for accuracy.

Where personas genuinely earn their tokens:

💡 The higher-value move is usually describing the reader instead of the speaker. "Explain to a second-year student who knows Python but has never seen SQL" shapes the answer far more than "You are an expert".

Wait — isn't the system prompt a security control?

It is guidance, not enforcement, and confusing the two is how teams get hurt. Two specific consequences.

Rules can be argued around. A determined user, or a poisoned document your app fetched, can steer the model past a system instruction. It is text competing with other text. Lesson 9 is entirely about this.

It isn't secret. "Users can't see the system prompt" is false in practice — extraction attempts succeed often enough that you must assume anything in context is potentially disclosable. So: no API keys, no internal pricing formulas, no other customers' data, nothing you'd be embarrassed to see screenshotted.

The corollary, worth stating in an interview: if a rule has real consequences — money moving, data leaving, a promise being made — put a check outside the model that inspects the output before it reaches anyone.

When system prompts get long

Real ones grow. A rule per incident, added by whoever handled it, for two years. Then the symptoms start: the model follows some rules and ignores others, apparently at random, and nobody can say which rule is authoritative.

This is contradiction and dilution, not a hidden length limit. The fixes are unglamorous and effective:

• Audit for duplicates and conflicts; delete rather than add.
• Resolve genuine conflicts explicitly — "if the length rule and the completeness rule conflict, completeness wins".
• Move situation-specific instructions out of the standing prompt and into the turn that needs them.
• Group rules under headings so related ones sit together.
• Put the non-negotiables near the start and restate the two or three that matter most at the end.

🎯 Selection-round radar: "What's the difference between a system prompt and a user prompt?" is a near-certain question. Give the definition, then the two lines that show experience: "models weight system instructions more heavily on conflict — but it's guidance, not a security boundary, so anything consequential also gets a check outside the model."

Structuring one for production

## Identity
You are the support assistant for ShopKart, an Indian e-commerce
site. You help with orders, returns, refunds and delivery.

## Grounding
Use only the details in the ORDER block. If a detail is missing,
say what is missing and ask for it. Never invent an order id,
date, amount or policy number.

## Format
At most 4 sentences, or a numbered list of at most 5 steps.
End with one concrete next action. No emoji.

## Scope and escalation
Payment disputes, account deletion and legal notices ->
  reply exactly: "Let me connect you to a human agent." and stop.
Anything unrelated to ShopKart -> one line declining, then offer
  to help with an order.

## Conflicts
If the format rule and the escalation rule conflict, escalation wins.

Two structural notes. Keep this text byte-identical across requests and put it first — prompt caching works on a stable prefix, and a timestamp at the top quietly destroys that (lesson 8). And if you run several products on the same logic, factor it: one shared behaviour block, a small swappable tone block per product. Forked copies drift.

Common mistakes

• Filling it with adjectives instead of checkable rules.
• Believing a persona grants knowledge.
• Putting secrets in it because "users can't see it".
• Treating it as a security boundary rather than guidance.
• Letting it grow to hundreds of contradictory accumulated rules.
• Putting per-request details in it instead of in the user turn.
• Prefixing it with a timestamp or username, killing prompt caching.

Quick recap

Practice Zone — PYQs from real selection rounds

Six MCQs, then two tasks: rewrite a vague system prompt as a specification, and decide where a persona actually helps.

Q1System promptseasy

What is the practical difference between a system prompt and a user prompt?

Asked in

aThe system prompt is encrypted; the user prompt is notbThe system prompt is the standing configuration you write once for every conversation — role, rules, tone, boundaries — while the user prompt is the one request being made right nowcThe system prompt is processed by a different modeldThere is no difference; the API merges them identically

Q2System promptsmedium

Your support bot's system prompt says "be helpful". Users complain the answers ramble. The best fix is:

Asked in

aSwitch to a bigger modelbReplace the adjective with an observable rule — "answer in at most 4 sentences; if the question needs steps, use a numbered list of at most 5 items"cAdd "be helpful" three more timesdLower the temperature to 0

Q3Personasmedium

Assigning a persona ("You are a senior tax consultant") mainly changes what?

Asked in

aThe model's underlying knowledge — it unlocks tax data it otherwise hidesbThe register and framing of the answer — vocabulary, level of detail, what it assumes the reader already knows — not the facts it hascThe number of tokens billeddWhether the model can call tools

Q4System promptshard

A system prompt has grown to 900 lines of accumulated rules. Symptoms: the model follows some rules and ignores others, unpredictably. The most likely cause is:

Asked in

aThe API silently truncates system prompts at 500 linesbRules contradict each other and compete for attention — with dozens of instructions, the model effectively picks winners, and nobody can say which rule is authoritativecSystem prompts stop working after 100 linesdThe temperature is too low

Q5System promptsmedium

Where should a rule like "never give medical dosage advice; redirect to a professional" live?

Asked in

aAppended to every user message by the frontendbIn the system prompt, stated as a positive alternative behaviour — plus an independent output check, because a prompt rule is guidance and not enforcementcNowhere — the model already refuses everything unsafedIn the first few-shot example only

Q6System promptshard

Your assistant must sound formal for banking customers and casual for a student app, but the logic is otherwise identical. Best structure?

Asked in

aMaintain two entirely separate 900-line prompts and keep them in sync by handbOne shared system prompt for behaviour and rules, plus a small swappable tone block per product — so a logic fix lands in both without a copy-pastecAsk the model to guess the audience from the questiondFine-tune two models

Hands-on tasks:

You are a helpful assistant for ShopKart customer support.
Be polite and professional. Answer questions well.
Don't say anything wrong. Be concise but complete.

FAQ

Next lesson: the reusable moves — delimiters, decomposition, self-critique, instruction placement — Lesson 7: Prompt Patterns →