The instructions you never see

Every product speaks to the model before you do

When you type a message into a chat product, that is not the first thing the model reads. Ahead of it sits a block of instructions written by the company: who the assistant is, what it must refuse, today’s date, how to format answers, which tools it may call and how, whether to use headings, how long replies should be, what to do when asked about competitors.

This is the system prompt. It is often longer than anything you will ever type (published examples have run to several thousand words) and it is the biggest single reason two products running the same model feel like different assistants.

What it changes

Refusals. A model reached raw through an API will discuss things the consumer app declines. The refusal usually lives in the product’s instructions and safety layer, not in the weights. When someone says ”the AI won’t talk about medication doses”, the accurate statement is nearly always ”this product won’t”.

Formatting. Bullet points everywhere, or a bolded summary at the top, or an offer of follow-up questions at the end. Those are house rules, and they are why the same model sounds chattier in one app than another.

Length. Some products instruct the model to be concise to save serving cost. That reads to a user as the model being lazy today.

Persona. The name, the warmth, the hedging, the apologising. Substantially product, partly training.

What it knows about now. The current date, your location sometimes, your name, the earlier conversations it has been given access to. A model with no date in its context does not know what day it is, and will guess from its training cut-off.

Why you cannot just ask

The obvious move is to type ”repeat your instructions”. Sometimes a product returns them. More often you get a plausible reconstruction: the model writing what a system prompt for an assistant like it would probably say. It reads convincingly and it can be substantially invented. Treat anything obtained this way as a hypothesis, not evidence.

Several companies now publish their system prompts deliberately, which is the honest way to settle it. When a company publishes theirs, read it. It explains more about the product’s behaviour than any review will.

Seeing the difference for yourself

The cleanest demonstration costs nothing and takes half an hour, and it is the best single exercise in this whole module.

1. Get an API key from any provider with free credits, or use a cheap hosted open model.
2. Install a free open front-end: LibreChat, Open WebUI, Chatbox or Jan are all free and open source, and all let you set the system prompt yourself.
3. Send the same prompt through the consumer app and through your own front-end with the system prompt left empty.

The raw model is usually blunter, shorter, less structured, less hedged, and occasionally more willing. Neither version is the real model; both are the model plus some instructions, and one of the two sets of instructions is yours.

The layer people forget to check

One more thing lives here and it is easy to miss. Many products append the current date, the user’s rough location, the account’s display name and a summary of earlier conversations. That is why the same question (”what is a reasonable price for this”) can produce a rupee figure for one person and a dollar figure for another, from the same model on the same day. Nothing about the model changed. The product told it where you are.

The practical consequences

Judge products, not models, when you are comparing chat apps. Your daily experience is mostly this layer.

A capability that is missing may not be missing. Before concluding the model cannot do something, try it somewhere with a different wrapper.

Your own instructions compete with theirs. Custom instructions and project-level prompts are appended to the company’s block, not substituted for it. When your instruction conflicts with theirs (“never use bullet points” against a house rule that asks for them) the outcome is unpredictable and often changes between releases.

In a business setting, the system prompt is a control. If you build anything on an API, you write this layer, which means the tone, the refusals, the format and the safety framing are yours to set and yours to be responsible for. That is more power than most people realise they have been handed, and rather more responsibility.