The Third Umpire · Lesson 3 — The Briefing ← Course

The briefing — the system prompt.

Before a ball is bowled, you can tell the umpire how to judge every one. That standing instruction is the system prompt.

Every time you chat with an AI, one message does the most work — and you never see it. Whoever built the tool writes it before your conversation starts, and it tells the model who to be and how to answer: its job, its tone, the rules it follows, the shape of its replies. That standing, hidden instruction is the system prompt.

Before a match, the captain briefs the umpire on how this game will be run — “watch closely for faint edges”, “explain your calls to the young keeper”, “keep your signals clear”. The umpire holds that briefing in mind on every ball. The deliveries are identical; only the handling changes.

And the umpire does not memorise the briefing once and forget it. A model has nothing to remember it with — so the system prompt is re-sent with every single ball, riding quietly ahead of each question you ask. One short instruction shapes every reply that follows.

Same umpire, same appeal — swap the briefing and the answer changes completely. That is why the system prompt is the first thing a builder reaches for: often you do not need a different model or a cleverer question, just a clearer brief.

Swap the briefing and replay the same appeal. Watch the umpire's manner change — never the facts.

Same appeal, four briefings. Pick one and see how the umpire answers.
the briefing · system prompt · set before play
+ ↓
the appeal · the field umpire asks
the umpire's call

One argument, set once.

In code the briefing is just a system instruction handed to the model alongside the question. Change that one string and every answer changes with it.


      

One briefing, every ball.

Set before the conversation and sent on every turn, the briefing is the lens the model reads each answer through. Same appeal, same facts; change the briefing and you change the tone, the length, the format, even the role the umpire plays.

It is the builder's first and biggest lever: before you reach for a different model or a cleverer question, change the instruction the model is standing on.

Next: the specifics →
Go deeper — getting a briefing right optional

Who writes the briefing

The system prompt is set by the builder of the tool, not by the person typing questions into it. The model gives it higher standing than an ordinary message, because of how it was trained rather than any special mechanism, and treats it as the frame for the whole conversation — which is exactly why it is the right place to fix behaviour once, instead of repeating yourself in every message. It is not a separate rule engine — it is text in the window like everything else, and it teaches the model nothing that outlasts the conversation.

It is always in the window

From the last lesson: the system prompt sits in the context window on every single turn. That makes it powerful — it is never forgotten halfway through a chat — but it is also a standing cost. A bloated briefing is tokens you spend before the conversation even begins, so good ones stay tight: a few clear rules, not an essay.

What a good briefing covers

The dependable ingredients are a role (“you are a conservative umpire”), the rules to follow, the tone to take, the format to answer in, and what to refuse. Vague briefings give vague behaviour; specific ones give predictable answers. Most of what people call “prompt engineering” begins right here.

It steers, it does not lock

A briefing strongly shapes how the model responds, but it is guidance, not an unbreakable rule — a determined user can still push against it. Making instructions genuinely stick is a harder problem the course comes back to later.