LLM System Design · Module 6 of 17 · 7 concepts · about 10 min

Prompt Management

Prompts decide how a feature behaves, so they are handled like code: written with a clear structure, stored with versions, tested before release and rolled out carefully.

At work: What keeps a product stable when a dozen people are editing the instructions that drive it, and what lets a team say which change made the answers worse.

Prompts are code

What it is

A prompt is the text sent to the model: instructions, context and the user's request. In a product, a prompt:

decides what the feature does, as surely as any function;
changes often, as the team learns what works;
can break the feature when a single sentence is changed.

So it is kept in version control, reviewed, tested and released, like code.

Why it matters

A prompt edited straight in a dashboard, with no record and no test, is the most common cause of 'the assistant got worse last week and nobody knows why'. Treating prompts as code gives you a history of every change, someone who reviewed it, and a way to go back.

In the real world: A support lead rewords one instruction to sound friendlier; refund answers quietly stop quoting the policy. With versions, the team finds the change in minutes and reverts it.

Scattering prompt text through the application as string fragments joined together in different files. Nobody can then read the whole prompt that the model actually receives, which is the first thing you need when debugging.

The parts of a system prompt

What it is

A good system prompt has a recognisable structure:

Role: who the assistant is and for whom it works.
Task: what it should do, in plain steps.
Rules: what it must and must not do, with reasons.
Context: the facts it may use (documents, user details), clearly marked.
Output format: exactly what the answer should look like.
Examples: one or two good answers, where they help.

Why it matters

Structure makes a prompt readable for the people who maintain it and clearer for the model that follows it. Giving the reason for a rule ('so the customer is not promised a refund we cannot give') works better than a bare command, because the model can apply the intent to cases the rule did not foresee.

In the real world: A team cuts a 2,000-word prompt that had grown by accretion down to 600 organised words, and both the answer quality and the cost per request improve.

Visual example

Anatomy

Not every prompt needs all six, but each has one job.

The six parts of a system prompt

part	its job	example
Role	Sets who is speaking and for whom	Support assistant for Kirana Kart
Task	Says what to do	Answer questions about orders and policies
Rules	Sets limits, with reasons	Never promise a refund amount
Context	Supplies the facts to use	The policy passage, the order record
Output format	Fixes the shape of the answer	Two or three plain sentences
Examples	Shows what good looks like	One model question and answer

ROLE
You are the support assistant for Kirana Kart, a grocery delivery app.

TASK
Answer the customer's question about their order or our policies.

RULES
- Use only the information inside <context>. If it is not there,
  say you don't know and offer to connect an agent. Customers act on
  what you say, so a guess can cost them money.
- Never promise a refund amount. State the policy and let the
  refund tool decide.

<context>
{retrieved_policy}
{order_details}
</context>

OUTPUT
Two or three sentences, plain language, no headings.

Fixing each new problem by adding another 'IMPORTANT: never...' line. The prompt grows into a pile of exceptions that contradict each other. When a rule is needed, rewrite the relevant section so the whole still reads as one clear brief.

Prompt templates and variables

What it is

A prompt template is a prompt with named gaps, called variables, that are filled in for each request:

the fixed text is written once;
variables such as {customer_name} or {retrieved_policy} are filled at run time;
the filled-in result is what the model receives.

Why it matters

Templates separate what changes per request from what does not.

The fixed part can be reviewed and versioned; the variable parts can be validated before they go in (is the order record present? is the document too long?).
It also keeps the unchanging part identical across requests, which is what prompt caching needs.

In the real world: A bug in a retrieval step returned no documents for a week; because the template refused to build without them, the feature showed a clear error instead of confident made-up answers.

TEMPLATE = """You are Kirana Kart support.

<context>
{policy}
</context>

Customer question: {question}"""

def build_prompt(policy: str, question: str) -> str:
    if not policy:
        raise ValueError("no policy retrieved")   # fail loudly, not silently
    return TEMPLATE.format(policy=policy, question=question)

Filling a variable with nothing and sending the prompt anyway. An empty {policy} leaves the model with instructions to 'use the context' and no context, which is an invitation to invent. Validate every variable before the call.

Few-shot examples

What it is

Few-shot prompting means including a few worked examples of input and ideal output in the prompt. The model copies the pattern:

the format of the answer;
its length and tone;
how to handle an awkward case.

Why it matters

Showing is often more reliable than telling, particularly for format and tone, which are hard to describe in words.

Two or three well-chosen examples can replace a paragraph of instructions.
The cost is tokens on every request, so examples have to earn their place.

In the real world: A product-description generator kept starting every description with 'Introducing the...' until the team replaced its three near-identical examples with three deliberately different ones.

Giving examples that are all alike. The model copies them too closely: the same opening phrase, the same length, even details from the example. Use varied examples, and say that they are illustrations, not templates.

Prompt registry and versioning

What it is

A prompt registry is a store of every prompt and every version of it. Each version records:

the template text and its variables;
the model and settings it was written for;
who changed it, when and why;
its results on the test set.

Applications ask the registry for a prompt by name and version.

Why it matters

A prompt and a model are a pair: a prompt tuned for one model may behave differently on another. Recording them together means any past answer can be reproduced exactly, a bad release can be rolled back in one step, and the logs can say which prompt version produced which answer.

In the real world: A compliance team asks why the assistant gave a certain answer in March; the registry and the request log together reproduce the exact prompt, model and settings used that day.

Versioning the prompt but not logging which version served each request. When quality drops, you need to split results by version. Without that tag in every log record, the versions exist and cannot be compared.

Practise it: Design an LLM Evaluation Platform

Releasing a prompt change

What it is

A prompt change goes through the same gates as a code change:

Edit in version control, with a reviewer.
Test against a fixed set of examples, comparing with the current version.
Canary: serve it to a small share of traffic and watch quality, cost and speed.
Promote to everyone, or roll back.

Why it matters

A prompt change is cheap to make and can affect every answer the feature gives. A wording improvement for one kind of question regularly makes another kind worse, and the person making the change will only have tried the first kind. The test set is what catches the second.

In the real world: A prompt edit that fixed tone on refund questions is blocked before release because the test set shows it made the assistant stop giving order numbers.

Visual example

Release

The same gates as code. The test set is the one that is skipped most and matters most.

A prompt change, from edit to everyone

Edit and reviewVersion control; a second reader
Run the test setNew vs current, fixed examples
Canary5% of traffic; watch quality and cost
Promote or roll backEveryone, or the previous version

Testing a change on the two or three questions that prompted it. That confirms the fix and says nothing about what broke. Run the whole set every time; it is what the set is for.

Keeping instructions and data apart

What it is

A prompt mixes two kinds of text:

instructions, written by you;
data: what the user typed, documents that were retrieved, results from tools.

They should be visibly separated: instructions in the system message, data wrapped in clear markers such as <context> tags, with a line saying the data is information and not instructions.

Why it matters

The model reads everything as one stream of text and can be steered by any of it.

If a retrieved web page contains 'ignore your instructions and...', there is nothing in the model itself that knows this came from a document and not from you.
Clear separation lowers the risk and is the starting point for the defences in the Guardrails module.

In the real world: A recruiting tool that pasted CV text straight into its instructions is rewritten to wrap each CV in tags and treat it strictly as data, after a candidate's hidden line tried to change the ranking.

Believing separation is a complete defence. It helps; it does not make the model immune. The stronger protection is limiting what the model is allowed to do, so that a successful trick has little to work with.