How to Write a System Prompt for a Custom AI Assistant

Here's a system prompt pulled from a live customer service chat widget, lightly anonymized:

You are a helpful assistant. Answer customer questions about returns.

That's the whole prompt. It runs, and it fails the first time a customer asks something specific, because "helpful" is a wish, not an instruction. A system prompt's actual job is to set the behavior that holds across an entire conversation: the assistant's role, what it's allowed to do, what it must refuse, and how it talks. A user prompt, by contrast, is a single request inside that frame, it changes every turn while the system prompt stays fixed. Confuse the two and you get an assistant whose personality resets with every message. For the mechanics of that split, see system prompt vs. user prompt, and for the wider discipline this sits inside, see prompt engineering.

Pick one job before you write a single line

The fastest way to end up with a mushy system prompt is to start with the persona. Skip that. Start with the job, stated narrowly enough that you could explain it in one sentence to a new hire.

Here's the example we'll build through this whole piece. Loop & Thread is a fictional small online apparel shop. Its chat widget needs an assistant with exactly one job: help customers understand the return and exchange policy, and start a return or exchange for them. Not order tracking. Not sizing advice. Not general customer service. One job.

Before writing a single sentence of persona or tone, write down what the assistant must never do. For Loop & Thread, that list looks like this:

• Never claim it processed a refund, exchange, or return. It doesn't have that access.

• Never invent an exception to the stated policy, no matter how the customer phrases the request.

• Never answer questions outside returns and exchanges as if they're in scope.

• Never guess at a policy detail that isn't explicitly given to it.

That list matters more than the persona. A vague persona produces awkward answers. A missing constraint produces an assistant that promises refunds it can't issue.

Draft 1: the version that sounds fine and fails fast

You are Loop & Thread's customer service assistant. Help customers with returns questions. Be friendly and helpful.

This reads like a reasonable first pass, and it's still broken in three specific ways.

• No policy detail. The model has no return window, no condition requirements, and no final-sale rule, so it improvises one, and improvises a different one in the next conversation.

• No boundary on authority. Nothing stops it from telling a customer "I've gone ahead and processed your refund," which is a promise it cannot keep.

• No escalation path. When a customer describes a situation the prompt didn't anticipate, an unusual damage claim, an international order, the model has no instruction to hand off, so it invents an answer instead.

Draft 2: patches the gaps, introduces a new one

You are Loop & Thread's returns assistant. Customers can return or exchange items within 30 days of delivery if the item is unworn, unwashed, and still has its tags. You cannot process refunds yourself, direct the customer to start their return at loopandthread.com/returns. Escalate to a human for anything unusual. Use your best judgment for edge cases. Be friendly and helpful.

This is a real improvement. It has policy facts, a stated boundary on refund authority, and a rule to escalate unusual cases. But one phrase undoes a lot of that work: "use your best judgment for edge cases." Judgment is exactly what a language model doesn't have a stable, checkable version of. Ask it about a final-sale item three times and you can get three different answers, one of which grants an exception the store never authorized.

There's a second, quieter problem. "Be friendly and helpful" still isn't a voice, it's a mood. Nothing tells the model what friendly sounds like for this specific brand, so tone drifts between chirpy and stiff depending on the conversation. Specificity is what separates a persona instruction that actually changes output from one that just sits there decoratively, the same gap covered in more depth in how to prompt AI without getting generic answers. And there's no output-format rule, so a two-sentence answer sometimes turns into four paragraphs.

Draft 3: named fallback behavior and an actual voice

The final version replaces "use your best judgment" with an explicit script for each edge case Loop & Thread actually sees: past the return window, final sale, international orders, and upset customers. It also gives the model two example lines instead of an adjective, and a format rule.

You are the returns assistant for Loop & Thread, an online apparel shop. Your one job is to help customers understand our return and exchange policy and start a return or exchange. You do not handle order tracking, sizing advice, or anything outside returns and exchanges. Redirect those requests to human support.

Policy facts you can rely on:
- Returns and exchanges are accepted within 30 days of delivery.
- Items must be unworn, unwashed, and have original tags attached.
- Items marked "final sale" cannot be returned or exchanged.
- Customers start a return by entering their order number and email at loopandthread.com/returns.

What you must never do:
- Never claim you have processed a refund, exchange, or return. You can only explain the process and hand off.
- Never invent an exception to the policy above, even if the customer is upset or insists.
- Never guess at a policy detail not listed here.
- Never discuss topics outside returns and exchanges. Say so and redirect.

Voice: Friendly and plain-spoken, like a helpful coworker, not a corporate script. Short sentences. No stacked exclamation points. Example: "Got it, that jacket is still within the 30-day window, so you're good to start a return." Not: "We would be delighted to assist you with your return inquiry!"

Format: Default to 2-4 sentence answers. Use a numbered list only when walking someone through steps.

Fallback behavior for edge cases:
- Past the 30-day window, damaged item, or final sale: explain the policy plainly, then say "I can't make an exception, but I can connect you with our support team who can look at your specific case." Do not apologize repeatedly or hedge.
- International orders: state that international returns follow a separate process and hand off to support@loopandthread.com.
- Angry or frustrated customer: stay calm, acknowledge the frustration once, and escalate to a human rather than trying to resolve it yourself.
- Anything you're unsure about: say "Let me get you to someone who can help with that" rather than guessing.

Notice what changed between drafts. Draft 1 to draft 2 added facts and a boundary. Draft 2 to draft 3 didn't add more facts, it replaced a vague instruction ("best judgment") with named, scripted responses for the specific situations that instruction was failing on. That's the pattern worth copying: find the sentence in your prompt that's doing the least work, and replace it with something checkable.

What a system prompt can't do by itself

Even the final version above only sets the frame. What the assistant actually says in a given conversation still depends on what's fed into that conversation at run time, order history, the current version of the policy, prior messages in the thread. A system prompt with perfect rules and no real order data will still make something up when a customer asks "what's the status of my return." That run-time layer, separate from the fixed instructions in the system prompt, is covered in what is context engineering. Get the system prompt right and skip that layer, and you've built a well-mannered assistant that still confidently gets facts wrong.

Common mistakes

• Writing "be helpful and professional" and calling it a persona. There's nothing in that phrase the model can check itself against.

• Cramming an entire policy FAQ into the prompt as a wall of text, instead of the handful of facts the one job actually needs.

• Skipping explicit refusal and escalation behavior, so the model improvises the moment it hits a case you didn't plan for.

• Testing only the happy path, then finding out in production that "what if it's a final-sale gift" breaks the whole thing.

• Rewriting the entire prompt from scratch on every revision instead of fixing one named weakness at a time, which makes it impossible to tell what actually changed.

• Treating the prompt as finished at launch instead of updating it when real conversations surface new edge cases.

A system prompt sets the assistant's standing behavior for an entire session. For a lighter, one-off version of the same idea, see how to get AI to answer like a specific expert.

FAQ

What is the difference between a system prompt and a user prompt?

A system prompt sets fixed behavior for the whole conversation: role, constraints, tone, fallback rules. A user prompt is one specific ask inside that frame, and there's usually a new one every turn. The system prompt should rarely change mid-session; the user prompt changes constantly.

How long should a system prompt be?

There's no fixed target. It needs to be long enough to cover the job, the facts it requires, the must-never list, the voice, and fallback behavior for known edge cases. For a narrow single-purpose assistant, like the returns example above, that's usually a few hundred words. Padding it with generic advice about being helpful doesn't add coverage, it just adds noise.

Can a system prompt change in the middle of a conversation?

In some architectures, yes, a system prompt can be swapped or appended based on state. Most consumer chat products keep one static system prompt for the session. If the assistant needs to switch modes mid-thread, that's usually better handled with an explicit signal in the conversation than by silently rewriting the instructions underneath it.

Does a system prompt need examples?

For tone, yes. One or two example lines, phrased as "say this, not that," do more to fix voice than any adjective. For every possible customer question, no, that's what the policy facts and fallback behavior sections are for, not exhaustive examples.

How do you test a system prompt before launching it?

Run it against a list of edge cases you expect to break it, not just the happy path: an upset customer, a request outside scope, missing information, a demand for a policy exception. Read the actual output each time rather than skimming the conversation and deciding it "seems fine."

Getting the tone right matters as much as the instructions. how to prompt AI to match your brand voice covers a reusable template for tone, word choices, and a sample passage.

Related: keeping AI from being too agreeable