The system prompt

The video is in Italian; this page is the written version in English.

A conversation with a model has three voices: the system, the user and the assistant. The first is written by whoever builds the tool, arrives before everything else, and the end user usually never sees it.

Message	Written by	When	Visible?
System	The developer	before everything	usually not
User	The user	every turn	yes
Assistant	The model	in reply	yes

It is not a user message with extra authority: it is closer to the stage directions an actor gets before walking on. It defines who they are, how they behave, what they do not do.

The difference shows immediately

With no system prompt, “how do I sort a list in Python?” gets a generic answer with five different methods and a long explanation.

With this in front:

You are a Python tutor for beginners. Answer with ONE method, the simplest. Five lines
maximum. Always with a runnable example.

the answer becomes:

numbers = [3, 1, 4, 1, 5]
numbers.sort()
print(numbers)  # [1, 1, 3, 4, 5]

Same model, same question. Only the script changed.

What to put in it

A useful system prompt answers four questions. Who you are — the role, which steers vocabulary and level of detail. How you answer — length, tone, format. What you do not do — explicit limits, more effective stated positively (“if the question is off topic, say so and stop”). With what context — the fixed information needed every time, which would be wasteful to repeat in each message.

The traps

Overload. Twenty rules do not produce a model twenty times more precise: they produce one that ignores half of them. Better few rules, ordered by importance, with the critical ones on top.

Conflicting rules. “Be concise” and “always explain your reasoning in detail” cannot both hold, and the model will satisfy one or the other at random.

Decorative roles. “You are a world-class expert” adds almost nothing unless followed by concrete guidance on what actually changes in the behaviour.

Confusing behaviour with knowledge. The system prompt defines behaviour; to give the model content — documents, data, archives — you need context or RAG, not a rule.

A note on security

The system prompt is not a vault: with enough persistence users often get it recited back, and clever instructions hidden in user text may try to override it. Never put keys, passwords or confidential information there, and never make it the only security control in a system.

It is not a security boundary

Worth stating plainly, because it is the source of an entire category of trouble: system instructions are a very strong suggestion, not a wall.

They are not secret. With enough persistence — repetition requests, role play, translation — a user can often get them recited back. Treat them as public: no keys, no passwords, no internal system details.

They are not inviolable. Instructions inside user text, or inside a document the system retrieves on its own, can try to override them. The model has no reliable way to distinguish “legitimate instruction” from “instruction that arrived inside the data”.

Defence	Why it works
Delimit external data	The model separates instructions from content better
Repeat the constraint at the end	The tail of the prompt carries more weight
Checks outside the model	The only real defence: validate output in code
Minimal tool permissions	If it cannot do something, no prompt makes it possible

The last row matters most. If a system can delete files, send messages or spend money, the control cannot live in a sentence of the system prompt: it must live in the code that performs the action. The prompt steers behaviour, the code defines what is possible.

In one line: the system prompt is stage direction, not security. It makes the part well played; it does not stop someone walking onto the stage.

A complete, annotated example

Theory lands better on a real case. Here is a system prompt that works, and why.

You are the support assistant for invoicing software.
Answer only about this software.

Format:
- Five lines maximum
- If a procedure has multiple steps, number them
- If you need information the user has not provided, ask instead of guessing

Limits:
- If the question is off topic, say so in one line and stop
- If the answer is not in the supplied documentation, say so: do not invent procedures

Remember: five lines maximum.

What makes this different from a list of good intentions.

The role is operational, not decorative: it states the domain, not “you are a world-class expert”. The format is measurable: “five lines maximum” can be checked, “be concise” cannot. The limits say what to do, not only what to avoid: “say so and stop” is executable, “do not ramble” is a wish. The most important rule is repeated at the end, because the tail of the prompt carries more weight — a trick that counts double with small models.

And above all: six rules, not twenty. Every extra rule dilutes the others.

How to prove it works

A system prompt is not evaluated by reading it, it is evaluated by breaking it. Four tests, five minutes.

Test	What it checks
Normal question	Does it respect format and length?
Off-topic question	Does it stop as instructed, or answer anyway?
Question with missing data	Does it ask, or invent?
Question that contradicts it	Does it hold, or get talked round?

The last is the surprising one: explicitly asking it to ignore the instructions. The model usually resists, but “usually” is not a guarantee to build on — which brings us back to the previous section: the real limits live in code.

In short

Concept	In one line
System prompt	Stage directions, ahead of every conversation
What it holds	Role, answer style, limits, fixed context
Overload	Too many rules means half get ignored
Conflicts	Contradictory rules produce random behaviour
Security	Not a secret: no keys, no confidential data
Security	The system prompt steers, it does not protect: limits belong in code
A good example	Operational role, measurable format, executable limits, key rule repeated
How to prove it	Four tests: normal, off-topic, missing data, contradiction