What is a system prompt, and should I own the one my chatbot developer writes?

What it is, in plain words

Think of the briefing a new receptionist gets on day one. Who we are. What you can answer yourself. What you never promise on the phone. When to put the call through to a manager. The receptionist does not memorise the whole company; they carry that briefing into every call.

A system prompt is that briefing for an AI model. Every time a customer writes to your chatbot, the software quietly sends the model two things: the standing instructions, and the customer’s message. The customer only sees their own message and the answer. The instructions are sent with every conversation, and they shape every answer.

A typical one holds:

• A role. “You are the support assistant for [business]. You answer questions about orders and opening hours.”
• Limits. “Answer only from the documents provided. If the answer is not there, say so and offer to connect the customer with a person.”
• A never-do list. No refunds promised, no prices that are not in the documents, nothing about other customers.
• Tone and language. Short answers, friendly, in the customer’s language.
• The handoff. When and how to pass the conversation to a person.

It matters more than people expect. Anthropic’s prompting documentation notes that setting a role in the system prompt “focuses Claude’s behavior and tone for your use case”, and that even a single sentence makes a difference.

A concrete example

I do not run a customer chatbot, but I run AI jobs that work from standing instructions, and they behave the same way.

A nightly job in my content pipeline starts an AI tool and hands it a long instruction file: which items to take from a queue, how to write, what never to do. When three of its outputs once wrote one field in the wrong shape, the lasting fix was not in the code. After correcting those three, I added a sentence to the instructions saying exactly what shape that field must take, at the point where the output is produced. One sentence changed the behaviour of every run after it.

My own workspace has a similar file that the AI tool reads at the start of every session: the folder layout, the naming rules, and a handful of rules that should never have to be relearned. When something goes wrong twice, a line goes into that file.

The instructions also have to arrive intact. In one test run, the job received only the first five words of its instruction file, because of how the script passed the text along. The field note on that cut-off prompt is a reminder that “the bot has instructions” and “the bot received its instructions” are two different claims.

Why it matters when you hire someone

When a developer builds your chatbot, the system prompt is where most of your business rules end up. Three things follow from that.

It is part of what you paid for. The code connects the bot to your website or WhatsApp. The system prompt decides what it says there. If you receive the code but not the prompt, the next developer has to rediscover your rules by trial and error.

It is where your never-do list lives. If you told the developer “never promise refunds”, the system prompt is where that became an instruction. Reading it is the quickest way to check your rules were actually written down, and written down the way you meant them. The guide on stopping a chatbot from making things up lists the rules worth having there.

It is not a guarantee. The model follows the instructions most of the time, not all of the time, and shouting does not help: the same documentation says newer models respond to normal wording, and that phrases like “CRITICAL: You MUST” can make a model overdo it. That is why the never-do list is also a test, as in how to test a chatbot before accepting it.

What to ask the freelancer

A good answer is short and concrete: the file, where it lives, how to edit it, how to check an edit. Put the first question into the “Maintenance” field of the chatbot brief, so updating the prompt after launch is part of the agreement rather than a favour.