Reusable templates and conditional prompts

By the end of October, Arjun’s review analyser had three versions. One for regular online reviews. One for Diwali hampers, which also checked whether the hamper arrived before the festival. One for wholesale clients, the cafés and offices that buy bread and cookies in bulk, which also pulled out the business name and order size. Each lived in its own Python file. Each had started life as a copy of the first.

On 3 November, Crumb’s sesame supplier changed, and some breads that never had sesame now carried traces of it. Meera asked for sesame to be added to the allergen watch list everywhere. Arjun updated the regular prompt and the Diwali prompt.

He forgot the wholesale one.

Eleven days later, the manager of Bean There, a café in Viman Nagar, phoned Meera. A customer of theirs had reacted to a Crumb multigrain loaf. The café had mentioned “sesame” in feedback twice that fortnight. Both times, Arjun’s wholesale analyser had marked mentions_allergy: false, because “sesame” was not on its list. Nobody had been alerted.

Nobody was seriously hurt. But Meera’s voice, when she came to the tech corner, was very calm, which was worse than angry. “How many places does the allergy list live, Arjun?”

“Three,” he said. Then, quietly: “It should live in one.”

Arjun’s first fix: one prompt to rule them all

Arjun’s instinct was sound: stop having three prompts. His first attempt was to merge them into one big prompt that covered every case in English:

You analyse customer feedback for Crumb & Co., a bakery chain in Pune.
Allergens to watch for: nuts, gluten, dairy, eggs, sesame.

If the feedback is about a Diwali hamper, also return "arrived_before_festival"
(true/false), considering that Diwali this year falls on...
If the feedback is from a wholesale client, also return "business_name" and
"order_volume", and be aware that wholesale clients care about consistency...
If the feedback mentions a specific store, also return "store"...
If the feedback is in Marathi or Hindi, ...
(and so on, for 40 more lines)

Return JSON with keys: product, score, mentions_allergy, allergens, and any
extra keys required above.

<feedback>
{feedback}
</feedback>

It ran. The sesame list now lived in one place. But within a day, odd things appeared. A regular review of a chocolate croissant came back with "arrived_before_festival": false. A wholesale review was occasionally scored with festival-style generosity. And the prompt had grown to about 1,900 tokens, sent with every single review.

“It’s one prompt now,” Arjun told Priya. “Why is it worse?”

“Because you’re asking the model to make a decision your code already knows the answer to,” she said. “Who knows whether a review is from a wholesale client: the model, or your database?”

Arjun paused. “The database. Wholesale clients log in with a business account. We know before we ever call the model.”

“So why are you asking the model to figure it out from forty lines of if-statements written in English?”

Mail merge, and the dough that becomes everything

Priya drew a letter on the whiteboard. “Have you ever seen a mail merge? One letter: Dear {name}, your order {order_id} ships on {date}. The bank sends it to a million people. The letter is written once. Only the blanks change.”

“A template.”

“Now picture Crumb’s kitchen. The bakers don’t keep forty separate recipes for forty breads. They have one base dough. Then: add sesame on top for this loaf, add raisins for that one, shape it differently for buns. The base is shared and tested. The additions are chosen by the baker before it goes in the oven, not discovered by the oven halfway through.”

“So the template is the dough, and my code is the baker who decides what to add.”

“Exactly. And the oven, the model, only gets the version that’s actually being baked.”

A prompt template is a prompt with named blanks, called placeholders, that code fills in at runtime. A conditional prompt goes one step further: whole sections are included or left out depending on facts your code already knows. The model never sees the wholesale instructions when reviewing a regular croissant, because they are not in its prompt at all.

Following one wholesale review through the template

Priya and Arjun rebuilt it, then traced a single real piece of feedback through every step.

The feedback, from Bean There’s account:

“Multigrain loaves this week were great, 40 delivered on time. But one customer said they tasted sesame and had a reaction. Did the recipe change?”

Step 1: what code knows before calling the model. From the database: segment = "wholesale", business_name = "Bean There, Viman Nagar", weekly_volume = 40 loaves. From one shared constant: ALLERGENS = "nuts, gluten, dairy, eggs, sesame".

Step 2: which sections are switched on. The base section (always). The wholesale section (segment is wholesale). Not the Diwali section (it is November 14, after the festival, and the product is not a hamper).

Step 3: the rendered prompt. This is exactly what the model receives:

You analyse customer feedback for Crumb & Co., a bakery chain in Pune.
Allergens to watch for: nuts, gluten, dairy, eggs, sesame.

This feedback is from a wholesale client: Bean There, Viman Nagar
(usual volume: 40 loaves a week). Wholesale clients care most about
consistency and on-time delivery. Note any request that needs a reply
from our wholesale manager.

Return JSON with keys: product, score, mentions_allergy, allergens,
needs_manager_reply.

<feedback>
Multigrain loaves this week were great, 40 delivered on time. But one
customer said they tasted sesame and had a reaction. Did the recipe change?
</feedback>

Notice what is not there: no festival rules, no store rules, no language rules. The business name is not something the model has to extract; code already put it in.

Step 4: the answer.

{"product": "multigrain loaf", "score": 3, "mentions_allergy": true,
 "allergens": ["sesame"], "needs_manager_reply": true}

The sesame mention is caught, because the list came from the one shared constant.

Step 5: the numbers. The rendered prompt is about 310 tokens, against 1,900 for the do-everything prompt. Crumb analyses about 9,000 pieces of feedback a month.

• Big prompt: 9,000 × 1,900 = 17.1 million input tokens a month.
• Template: 9,000 × 310 = 2.8 million input tokens a month.

On a small model at an illustrative $0.25permillioninputtokens,thatis$4.28 (about ₹375) against $0.70(about₹60)amonth.Smallmoney.Butonalargermodelatanillustrative$5 per million, it becomes roughly ₹7,500 against ₹1,230, every month, for the same work done worse. Shorter, relevant prompts are cheaper and more accurate at the same time.

Opening the hood: what a template really is

A template is not magic, and it is not an AI feature. It is plain string building, done carefully. Rendering a template means: take the fixed text, evaluate any conditions and loops, substitute every placeholder with a value, and produce one final string. That final string is the only thing the model ever sees. The model has no idea a template existed.

This has a practical consequence that surprises beginners: most “the model ignored my instruction” bugs in templated systems are rendering bugs. The instruction was never in the final string, because a condition was false, a variable was empty, or a section was misspelled. The first debugging step is always: print the rendered prompt and read it.

It also means templates are code, and they deserve what code gets: one source of truth, version control, review, and tests.

Building it, one layer at a time

Layer 1: named placeholders. Python’s built-in str.format is enough to start:

ALLERGENS = "nuts, gluten, dairy, eggs, sesame"   # the ONE place this list lives

BASE = """You analyse customer feedback for Crumb & Co., a bakery chain in Pune.
Allergens to watch for: {allergens}.

Return JSON with keys: {keys}.

<feedback>
{feedback}
</feedback>"""

print(BASE.format(allergens=ALLERGENS,
                  keys="product, score, mentions_allergy, allergens",
                  feedback="The bagels were lovely."))

You should see the full prompt with every blank filled. Use named placeholders like {feedback}, never bare {}. Six months from now, {feedback} tells you what belongs there.

Layer 2: conditional sections, decided in code. Add an {extra} slot and fill it based on facts from the database:

BASE = """You analyse customer feedback for Crumb & Co., a bakery chain in Pune.
Allergens to watch for: {allergens}.
{extra}
Return JSON with keys: {keys}.

<feedback>
{feedback}
</feedback>"""   # same as before, plus an {extra} slot for optional sections

WHOLESALE = ("\nThis feedback is from a wholesale client: {business} (usual volume: "
             "{volume}). Wholesale clients care most about consistency and on-time "
             "delivery. Note any request that needs a reply from our wholesale manager.\n")
DIWALI = ("\nThis is about a Diwali hamper. Diwali this year was on {festival_date}. "
          "Note whether it arrived before the festival.\n")

def build_feedback_prompt(feedback: str, customer: dict, product_type: str,
                          festival_date: str | None) -> str:
    keys = ["product", "score", "mentions_allergy", "allergens"]
    extra = ""
    if customer["segment"] == "wholesale":                    # code knows this for certain
        extra += WHOLESALE.format(business=customer["business_name"],
                                  volume=customer["weekly_volume"])
        keys.append("needs_manager_reply")
    if product_type == "hamper" and festival_date:            # so does this
        extra += DIWALI.format(festival_date=festival_date)
        keys.append("arrived_before_festival")
    return BASE.format(allergens=ALLERGENS, extra=extra,
                       keys=", ".join(keys), feedback=feedback)

Call it with a regular customer and a croissant review, and the wholesale and Diwali sections do not appear.

Layer 3: a real template engine for bigger prompts. Once you have loops (“list the customer’s last three orders”) and several nested conditions, Python strings get messy. Many teams switch to Jinja, a templating language from web development that suits prompts well. Install with uv add jinja2.

from jinja2 import Template

SUPPORT = Template("""You are Crumb's support assistant.
{% if customer.segment == "wholesale" %}
This is a wholesale client. Be concise and businesslike.
{% endif %}
{% if mentions_allergy %}
Allergy policy: we cannot guarantee any product is free from traces of nuts
or sesame. Always recommend the customer calls the store before ordering.
{% endif %}
Recent orders:
{% for o in customer.orders[-3:] %}- {{ o.date }}: {{ o.item }} ({{ o.status }})
{% endfor %}
<message>
{{ message }}
</message>""")

print(SUPPORT.render(
    customer={"segment": "retail", "orders": [
        {"date": "2 Nov", "item": "Plum cake", "status": "delivered"}]},
    mentions_allergy=True,
    message="Does your plum cake have nuts?",
))

The allergy policy appears only when the message is about allergies. The order list shows at most three orders, never fifty. Library APIs change quickly. If a name has moved, check the docs linked below.

Layer 4: templates as files, with versions and tests. Move each template into prompts/feedback_v4.jinja, commit it to git, and log the template name and version with every model call. When quality drops, you can tell whether the prompt changed or the inputs did. Then add a test that renders every combination of switches:

import itertools

def test_every_combination_renders():
    for segment, product_type in itertools.product(["retail", "wholesale"],
                                                   ["cake", "hamper"]):
        customer = {"segment": segment, "business_name": "Test Café", "weekly_volume": 10}
        prompt = build_feedback_prompt("Lovely!", customer, product_type, "1 Nov")
        assert "sesame" in prompt                 # the allergy list is always there
        assert "{" not in prompt                  # no unfilled placeholders left
        assert ("wholesale client" in prompt) == (segment == "wholesale")

Run it with uv run pytest. A test like this would have caught the sesame bug on 3 November.

Where it breaks

Templates removed the drift. They also introduced a fresh set of bugs that bit Arjun over the next two weeks.

The curly-brace crash. Arjun added an example of the expected JSON to the base template: Example: {"product": "brownie", "score": 4}. The next run crashed with KeyError: '"product"'. Python’s .format treats every {...} as a placeholder, including the braces in his JSON example. The fix is to double literal braces ({{"product": ...}}) or to use Jinja, which uses {{ }} for placeholders and leaves single braces alone. Customer text passed in as a value is safe; .format does not look inside values.

The empty section that left a hole. For customers with no orders, the Jinja template rendered Recent orders: followed by nothing. The model, seeing a heading with nothing under it, sometimes said “I can see you have no previous orders with us”, to a customer who had ordered by phone. Empty sections should disappear entirely: wrap the heading inside the if as well.

The whole object in the blank. To save time, Arjun once rendered {{ customer }} directly. The model received a 200-field dictionary, including internal flags like credit_risk: low, which then appeared in a reply. Choose the fields that matter. Anything in the prompt can end up in the output.

The blank that talks back.

Try it yourself

Write a function build_reply_prompt(message, language, is_first_order) that:

1. Always includes Crumb’s role and tone rules.
2. Adds “Reply in Marathi.” or “Reply in Hindi.” when language is "mr" or "hi", and nothing extra for "en".
3. Adds “This is the customer’s first order. Thank them for choosing Crumb.” only when is_first_order is true.
4. Wraps the message in <message> tags.

Render all six combinations and print them. Then write one test that checks every combination contains the <message> tags and that the English prompts contain no language line.

ROLE = ("You are Crumb & Co.'s support assistant. Write warm, plain replies "
        "under 100 words. Never promise refunds.")
LANG = {"mr": "Reply in Marathi.", "hi": "Reply in Hindi.", "en": ""}
FIRST = "This is the customer's first order. Thank them for choosing Crumb."

def build_reply_prompt(message: str, language: str, is_first_order: bool) -> str:
    parts = [ROLE, LANG[language]]
    if is_first_order:
        parts.append(FIRST)
    parts.append(f"<message>\n{message}\n</message>")
    return "\n\n".join(p for p in parts if p)   # drop empty sections entirely

def test_all_combinations():
    for lang in ["en", "hi", "mr"]:
        for first in [True, False]:
            p = build_reply_prompt("Hi", lang, first)
            assert "<message>" in p and "</message>" in p
            if lang == "en":
                assert "Reply in" not in p

Common mistakes

• Copy-pasting prompts between files. They drift, and the drift is invisible until it hurts. Shared rules live in one place.
• Writing if-statements in English. If code knows the answer, let code choose the section. The model should only see what applies.
• Never reading the rendered prompt. Print it while developing and log it in production. Most template bugs are visible at a glance.
• Dumping whole objects into a placeholder. Pick the fields the task needs; everything in the prompt can leak into the output.
• Literal braces in .format templates. Double them or switch to Jinja.
• Forgetting that user text is untrusted. Delimit it, and never let it alone trigger anything costly.

Recap

• A prompt template has named placeholders filled by code at runtime; the model only ever sees the final rendered string.
• Conditional prompts include only the sections that apply, which makes prompts shorter, cheaper and more accurate.
• Decide in code anything code knows for certain; leave judgement calls to the model.
• Treat templates as code: one source of truth, files in git, version numbers in your logs, render tests for every combination.
• Watch for rendering bugs: literal braces, empty sections, oversized objects, and injected instructions in user text.

That evening, Arjun showed Meera the new setup. “There’s now one allergen list, in one file. Every prompt is built from the same base, like the bakers’ dough, and my code adds the wholesale or Diwali bits only when they apply, because the database already knows. And there’s a test that builds every possible version of the prompt and fails loudly if sesame is ever missing from any of them.”

“So if we add mustard next year?”

“One line. Every prompt gets it. The test proves it.”

Meera seemed satisfied. Then she pulled out her phone. “One more thing. I want every review sorted into our five categories: freshness, taste, packaging, delivery, service. I tried asking the model myself and it invented a category called ‘emotional’.” Arjun laughed, then stopped, because she was not joking.

Go deeper

• Jinja documentation: https://jinja.palletsprojects.com
• Python tutorial, including string formatting: https://docs.python.org/3/tutorial/
• Prompt injection series by Simon Willison: https://simonwillison.net/series/prompt-injection/