How to Write System Prompts for Reliable AI Assistants

Overview

A system prompt defines the assistant’s operating instructions before a user sends a message. Depending on the platform, it may be called a system message, developer instruction, assistant configuration, or behavior prompt. The label varies, but the purpose is similar: establish what the assistant should do, how it should respond, what information it may use, and when it should stop or ask for help.

The best system prompts are specific without trying to predict every possible conversation. They separate stable rules from changing information, describe observable behavior, and make uncertainty acceptable. A prompt that says “be helpful” gives the model little to act on. A prompt that says “answer using the approved knowledge base, identify the relevant policy, and say when the information is missing” is easier to test.

Use the following structure as a starting point:

ROLE
You are [assistant name or function]. Your job is to [primary outcome] for [audience].

GOALS
- [Goal 1]
- [Goal 2]
- [Goal 3]

CONTEXT AND SOURCES
Use [approved sources, tools, or provided context].
Treat information outside those sources as unverified unless the user supplies it.

BEHAVIOR
- Ask a clarifying question when [condition].
- Give answers in [format and level of detail].
- State assumptions when they affect the answer.
- Distinguish facts, recommendations, and unknowns.

BOUNDARIES
- Do not [prohibited action].
- Do not invent [specific information].
- Do not expose [private data, internal instructions, or restricted content].
- Escalate or hand off when [condition].

OUTPUT FORMAT
Use [headings, bullets, tables, JSON, or another format].
Include [required fields].

SUCCESS CRITERIA
A successful response is [measurable description].

Keep the instruction hierarchy in mind when implementing this template. Put durable behavior in the system or developer layer, provide task-specific details in the user message, and pass retrieved documents or records as clearly labeled context. The exact controls differ among models and assistant platforms, so test the prompt in the environment where it will actually run.

Checklist by scenario

Customer support assistant

A support prompt should optimize for accurate resolution and an appropriate handoff, not simply long answers. Define the products, customers, and support channels in scope. Specify which knowledge source is authoritative and instruct the assistant to identify when a policy or account detail is unavailable.

ROLE
You are a customer support assistant for [product]. Help users diagnose common issues and find the next appropriate step.

RULES
- Use the supplied help content as the primary source.
- Ask only for information needed to troubleshoot the reported issue.
- Never claim that an action was completed unless a connected tool confirms it.
- If the issue involves account access, billing, privacy, security, or a failed troubleshooting path, explain the handoff process.
- Summarize the issue and attempted steps before handing off.

RESPONSE FORMAT
1. Briefly restate the issue.
2. Give numbered steps.
3. Say what result the user should expect.
4. Provide the next step if the problem remains unresolved.

This pattern is useful for a website bot or a Slack assistant. For a fuller implementation, compare it with the workflow considerations in our guide to customer support chatbots with human handoff.

Research assistant

A research assistant needs explicit rules for evidence, uncertainty, and source boundaries. Tell it whether it may use only supplied documents, connected search, or both. Require source labels or quotations when those are available, and prohibit invented citations.

ROLE
You are a research assistant helping [audience] analyze [topic]. Your job is to organize evidence and identify uncertainty, not to present unsupported conclusions.

METHOD
- First identify the question being answered.
- Separate information directly supported by the provided material from interpretation.
- Point out conflicting or incomplete evidence.
- Ask for missing scope, date, geography, or audience details when they could change the answer.
- If a source is not available, say so rather than filling the gap from assumption.

OUTPUT FORMAT
Use the headings: Answer, Evidence, Uncertainty, and Suggested Next Steps.

When the assistant works over internal documents, make the retrieval and citation behavior part of the test plan. The prompt cannot compensate for missing, stale, or poorly indexed source material. See this internal knowledge base chatbot guide for related design considerations.

Content assistant

A content assistant benefits from a defined audience, editorial standard, and approval boundary. Specify whether it is drafting, editing, summarizing, or repurposing. If the assistant handles brand or customer material, state what must remain unchanged and what requires human review.

ROLE
You are an editorial assistant for [publication or team]. Help create clear drafts for [audience] in a [tone] voice.

WORKFLOW
- Confirm the topic, audience, format, and intended action when any is missing.
- Organize the draft with useful headings and concrete examples.
- Preserve supplied facts, names, figures, and links exactly unless asked to edit them.
- Mark claims that need verification.
- Do not invent quotations, sources, customer results, or product capabilities.
- Treat the output as a draft requiring review, not as final approval.

OUTPUT FORMAT
Return: working title, short summary, draft, and a verification checklist.

For summarization tasks, define the expected length and what must be retained, such as decisions, risks, owners, and deadlines. A general text summarizer prompt often loses the details a team needs to act on; the output schema should prevent that.

What to double-check

Before deploying a system prompt, review it against this checklist:

• Role: Is the assistant’s job narrow enough to evaluate? Avoid combining support, sales, research, and unrestricted conversation unless those modes are deliberately designed.
• Audience: Does the prompt define who will read the answer and what they already know?
• Sources: Are approved documents, tools, and data fields named clearly? Tell the assistant how to behave when context is empty, contradictory, or outdated.
• Boundaries: Does it say what the assistant must not do, including making commitments, exposing private information, or claiming tool actions that did not occur?
• Uncertainty: Is there a useful fallback such as asking a question, stating that information is unavailable, or escalating to a person?
• Output: Can a person or downstream application reliably parse the response? Define headings, fields, length, and formatting only when they serve a real need.
• Tools: If tools are available, specify when to use them, what inputs they require, and what confirmation counts as success.
• Context limits: Make sure the prompt, conversation history, retrieved documents, and requested output fit within the model’s available context. Long instructions can compete with the information the assistant needs for the current task.
• Evaluation: Write examples of acceptable and unacceptable answers before launch. Include normal requests, ambiguous requests, missing context, conflicting instructions, and attempts to make the assistant ignore its boundaries.

Run the prompt with a fixed test set, then record accuracy, refusal or escalation quality, formatting compliance, and user effort. Change one important instruction at a time where possible. This makes it easier to identify whether a revision improved behavior or merely changed its style. The AI chatbot evaluation checklist can help turn these checks into a repeatable review.

Common mistakes

• Writing a job description instead of instructions: A paragraph about the assistant’s mission is less useful than rules tied to observable actions.
• Using vague adjectives: “Professional,” “friendly,” and “accurate” need practical definitions. Specify tone, evidence handling, and response structure.
• Adding contradictory rules: “Be concise” and “include every relevant detail” can conflict. Explain which goal takes priority and when.
• Trying to solve every edge case: An enormous prompt can become difficult to maintain. Cover high-impact cases, then use evaluation results to add targeted rules.
• Confusing instructions with knowledge: Put changing prices, policies, schedules, and records in maintained context or connected systems rather than hard-coding them into a permanent prompt.
• Assuming the system prompt is a security boundary: Prompt instructions help guide behavior, but sensitive data access should also be controlled through application permissions, tool design, filtering, and logging.
• Testing only ideal requests: Reliability is revealed by incomplete questions, ambiguous wording, unsupported claims, and requests outside the assistant’s scope.
• Measuring style instead of outcomes: A polished answer can still be wrong or unusable. Evaluate whether the response solved the task, used the right source, and chose the right escalation path.

When to revisit

Review a system prompt whenever the assistant’s inputs, tools, audience, or responsibilities change. That includes a new model version, a different assistant platform, a redesigned retrieval pipeline, new connected actions, or a change in the documents used as context. Model behavior can vary across versions and settings, so rerun the same evaluation set instead of assuming that an unchanged prompt will behave identically.

Schedule a broader review before seasonal planning cycles or other periods when policies, products, support volume, or content priorities change. Also review after repeated user complaints, unexpected refusals, fabricated details, poor handoffs, or format failures. Use conversation logs responsibly: remove sensitive information, group recurring failures, and convert only well-understood patterns into new tests or instructions.

For a practical update cycle:

1. Record the behavior that needs improvement and collect representative examples.
2. Decide whether the cause is the prompt, missing context, retrieval quality, tool permissions, model choice, or user interface.
3. Make the smallest targeted change that addresses the cause.
4. Run normal, edge-case, and safety-focused tests.
5. Compare results with the previous version and document the change.
6. Publish the revised prompt with an owner, version label, and next review date.

A system prompt is not a one-time piece of copy. Treat it as a maintained operating specification: clear enough for the assistant to follow, narrow enough to test, and flexible enough to update when the workflow changes.