2.2 System Prompts, Templates & Guardrails

Imagine writing a letter you'll send to a thousand different customers. Some of it is the same every time — your company's letterhead, your tone, the standard closing. Some of it is unique to the one person you're writing to — their name, their account number, the specific issue they raised. You wouldn't retype the letterhead by hand for each customer, and you definitely wouldn't bury their account number inside a paragraph of boilerplate where it might get lost. You'd keep the two kinds of content in separate, purpose-built places.

That's exactly the split Claude's API gives you between the system prompt and the user message, and Task Statement 2.2 is about using it deliberately rather than by habit. The system prompt is where stable rules, role, tone, and constraints live — the things that should hold true across every single request your application sends. The user message is where the specific request and its per-request data belong — the part that's different every time. Get this separation right and two things improve at once: your application behaves consistently, because the rules aren't being reworded or reordered call to call, and — as you'll see in 2.2.2 — you set yourself up for a cost and latency win you haven't even learned about yet.

Here's the payoff that turns a tidy convention into an architectural decision. When you keep the system prompt stable and identical across requests, you're not just organizing your code — you're creating a long, unchanging block of text that Claude's prompt caching mechanism can recognize and reuse instead of reprocessing from scratch on every call. We'll go deep on caching mechanics in Lesson 2.4, but the setup for it happens here, in how you structure the prompt in the first place.

If you mix stable and variable content together — say, by string-interpolating today's date or the customer's name directly into the middle of your system prompt — you've broken that stable block into something that's technically different on every request, even if 95% of the words are identical. Caching requires the prefix to be exactly the same, byte for byte, so a design that keeps role/rules/tone genuinely stable and pushes every varying detail into the user message is quietly doing double duty: better consistency now, cheaper and faster requests later.

Once you accept the system/user split, the next question is how you actually build the parts that DO vary — the specific document to analyze, the user's query, the record being processed — without smearing them across the whole prompt in an ad-hoc way. The answer is templates: you design a scaffold of instructions, format spec, and (where relevant) examples that stays constant, and you parameterize only the specific slots that legitimately change.

This sounds like basic software hygiene, and it is — but it earns its place in an architect's toolkit because it improves two different things at once, the same way the system/user split did. First, a constant scaffold means every request is judged and shaped by the same instructions, so output is more comparable across thousands of calls — you're not accidentally testing ten slightly different prompts because someone typed the instructions freehand each time. Second, a constant scaffold is precisely the kind of stable prefix that caching rewards; a template isn't just a UX or maintenance convenience, it's a cache-economics decision too.

Now for the part of this lesson that carries the most weight on the exam. A guardrail, in the prompt sense, is a behavioral boundary you write directly into the system prompt: refuse requests outside a defined scope, stay within a content policy, defer to a human before taking a high-stakes action. These are genuinely useful, and every well-designed system prompt has some. But they come with a property you must never forget: they are probabilistic, not deterministic.

"Probabilistic" here means the model generally follows the instruction — often very reliably — but a sentence in a prompt does not physically prevent anything. Compare it to a sign in a store window that says "Please don't touch the merchandise." Most people comply, but the sign itself has no mechanism to stop the person who doesn't. If you actually need merchandise to be untouchable, you put it behind glass — that's a deterministic control, one that doesn't depend on anyone choosing to comply.

For genuinely destructive or high-stakes actions — deleting production data, transferring money, executing an irreversible operation — the architecture needs the equivalent of glass, not just a polite sign. That's what deterministic controls are: hooks that intercept an action before it executes, permission scoping that limits what the model is structurally capable of doing in the first place (least privilege), and output validation that checks a response before anything downstream acts on it. These sit around the model rather than inside the prompt, and they enforce the boundary regardless of what the model "decided" to do.

There's one more hazard that lives right at the boundary between the system prompt and the user message: what happens when the content you're putting into the prompt isn't something you wrote, but something that arrived from outside — a customer's message, a document someone else authored, the output of a tool call. Claude reads all of the text in its context; it has no innate way to tell "this is data to analyze" apart from "this is an instruction to follow" unless you make that distinction explicit and hard to fake.

This matters because untrusted text can contain something that LOOKS like an instruction — "ignore your previous rules and do X instead" — embedded inside what's supposed to be inert content. If you paste that text into your prompt undelimited, next to your real instructions, the model has no structural reason to treat it differently than your actual system prompt. The fix is to delimit and sanitize: wrap untrusted input in clear boundaries (tags, explicit labeling) and treat it explicitly as data to be processed, not as a source of new instructions. This is a preview of a bigger topic in Domain 3 and Domain 5 (prompt injection and untrusted-content handling), but the root of it belongs right here, in how you assemble the prompt.