You will be able to write a system prompt that fixes the role, rules and output format for an application.
Priya's summariser worked, but every summary came out a little different. One was a tidy sentence. The next was three bullet points with a heading. One customer wrote in Malay and got a summary in Malay. One complaint was only the words "same problem again", and the model invented a guess about which problem it meant. Her team could not build anything on top of output that changed shape every time.
The fix for most of that is a system prompt, written once and sent with every request.
In lesson 1.1 you saw that each message in a request is marked with a role: system, user or assistant. The system prompt is the instruction in the system role. It carries the standing rules of your application and is sent with every call, while the user message changes each time. Some providers call it a system message, others an instructions field or a developer message, but the idea is the same.
The split matters because it mirrors how your app works. The user, or your code on the user's behalf, supplies the feedback. You, the builder, supply the rules about what to do with it. Keeping them apart means you can change the rules in one place, and you never have to stitch instructions into each piece of user text by hand.
Models are trained to give the system role more weight than the user role, so standing rules belong there. Still, it is a priority, not a lock, and that point comes back at the end of this lesson.
If you took Working with AI assistants, much of this will feel familiar from lesson 1.2, Give context the way you would brief a colleague. The difference is that an application prompt has to work on inputs you will never see. There is no chance to read the reply and ask again, so the decisions you would make on the fly have to be written down in advance.
Here is what Priya's system prompt covers, in this order:
The task: summarise one piece of customer feedback for the operations team. The audience: team leads who skim dozens of these a day and only care what went wrong. Missing information: if the feedback does not say what went wrong, say "not stated" rather than guessing. Language: always reply in English, whatever language the feedback is in. Format: one sentence of no more than 25 words. The problem comes first.
Notice the missing information rule. Without it, a model fills gaps with something plausible, which is how "same problem again" became an invented complaint about late deliveries. Telling it what to do when the input is thin is one of the most useful lines you can write.
Write the format as exactly as you can. "Short" means different things to different people and to models. "One sentence, under 25 words" does not. In lesson 2.2 you will go further and ask for structured JSON, but a clear format rule in plain words is where every application prompt starts.
Priya also added two short examples of feedback with the summary she wanted for each. Examples often fix tone and length faster than more description does.
A system prompt in use affects every output after it. Edit one line and they all change. Priya once added "be concise" to fix one long summary, and the next day her team noticed that summaries had stopped naming the delivery area, which they relied on for routing.
So store the system prompt in version control with the rest of your code, in its own file or as a clearly named constant, and change it the way you change code: one edit at a time, with a commit message saying why. When output changes unexpectedly, you can then see exactly which edit caused it and roll it back. Module 7, Test the output before you trust it, shows how to check a prompt change against a fixed set of test cases before it reaches users. Until then, keep a handful of sample inputs and rerun them after every edit.
One last thing about system prompts, and it matters for everything you build in this course. A system prompt is not a security boundary. A determined user can sometimes talk a model out of its instructions with messages like "ignore the rules above" or a long, persuasive story. Text inside a document the model reads can do the same.
So never rely on the system prompt alone to stop something that must not happen. Do not put secrets in it, because a user may be able to get the model to repeat it. Do not let it be the only thing standing between a user and data they should not see. Checks that matter belong in your code, and lesson 8.2, Prompt injection: when your input gives orders, covers this in depth.
For a feedback summariser, the stakes are low. The worst a clever user can do is get a strange summary. That makes it a good first prompt to write, and that is what the activity below asks of you.
Write a system prompt for an app that summarises customer feedback, covering task, tone, missing information and format.
Junxiong-WFG Organisation is an authorised representative of AIA Financial Advisers Private Limited (Reg. No. 201715016G).