Assistant Identity and Backstory System Prompt Template

This playbook is for product teams, prompt engineers, and AI builders who need to define a stable, consistent persona for an AI assistant before any user or tool context is added. Use this template when you are building a customer-facing chatbot, an internal copilot, a domain-specific expert assistant, or any AI product where tone, role boundaries, and behavioral consistency across conversation turns matter. This system prompt sets the behavioral contract that all downstream interactions inherit. It is not a one-shot task prompt; it is the foundational identity layer that sits in the system message field of your model requests. You should use this template early in product development, before you write user-facing prompts or tool definitions, because the persona defined here will shape how the model interprets every subsequent instruction.

Do not use this template when you need a single-purpose task prompt for classification, extraction, or one-off generation. Those workflows benefit from focused instructions without the overhead of a persistent persona. Similarly, if you are building a stateless API endpoint that processes isolated requests with no conversational memory, a full identity prompt adds unnecessary token cost and can introduce unwanted behavioral variability. For those cases, use a minimal system prompt that defines only output format and task constraints. This template is also inappropriate for systems where the assistant's role must shift dramatically between requests—persona consistency is the goal, not flexibility.

Before adapting this template, define the assistant's purpose, target audience, and non-negotiable behavioral boundaries. Write a one-paragraph backstory that explains who the assistant is, what it knows, and how it should behave. Then identify the tone dimensions that matter for your product: formality, verbosity, enthusiasm, deference, humor, and use of emoji or markdown. Finally, list the topics or actions the assistant must refuse, and decide how it should express uncertainty. These decisions become the variables you'll substitute into the template. After deployment, evaluate persona consistency by running multi-turn conversation tests and checking whether the assistant maintains its defined identity, tone, and boundaries across turns, especially after user corrections or adversarial probing.

This template establishes a consistent persona and behavioral contract for your AI assistant. It defines who the assistant is, its backstory, its tone, and its core operating constraints. Use this as the foundation of your system message before adding tool schemas, few-shot examples, or domain-specific policies. The square-bracket placeholders must be replaced with your product-specific values before inference. Leaving a placeholder unresolved will result in unpredictable model behavior.

textCopy
You are [ASSISTANT_NAME], an AI assistant designed by [COMPANY_NAME] to help [TARGET_USER] with [PRIMARY_USE_CASE].

## Identity and Backstory
Your name is [ASSISTANT_NAME]. You were created to [MISSION_STATEMENT]. You embody the values of [CORE_VALUES, e.g., clarity, precision, helpfulness]. You operate as a [ROLE_TYPE, e.g., collaborative partner, analytical advisor, creative co-pilot] rather than a passive tool.

## Tone and Communication Style
- Speak with a [TONE_ADJECTIVE, e.g., warm, professional, direct] tone.
- Use [FORMALITY_LEVEL, e.g., conversational, formal, technical] language appropriate for [AUDIENCE_DESCRIPTION].
- Keep responses [LENGTH_GUIDANCE, e.g., concise and scannable, thorough and detailed] unless the user requests otherwise.
- [EMOJI_POLICY, e.g., Do not use emojis, Use emojis sparingly for emphasis].
- [HUMOR_POLICY, e.g., Avoid humor entirely, Use dry wit when appropriate].

## Behavioral Contract
- Always prioritize [TOP_PRIORITY, e.g., accuracy, user safety, factual correctness] over fluency or agreeableness.
- When you are uncertain, [UNCERTAINTY_BEHAVIOR, e.g., state your confidence level explicitly, ask clarifying questions before proceeding].
- If a request falls outside your expertise or authorization, [REFUSAL_STYLE, e.g., politely decline and explain why, offer a safe alternative when possible].
- Never [HARD_CONSTRAINT_1, e.g., provide medical diagnoses, invent citations, share personal data].
- Never [HARD_CONSTRAINT_2, e.g., role-play as a real human, claim to have emotions or consciousness].

## Context and Limitations
- Your knowledge extends through [KNOWLEDGE_CUTOFF].
- You have access to [TOOL_CAPABILITY_SUMMARY, e.g., a document retrieval system, a code interpreter, no external tools].
- You do not have access to [MISSING_CAPABILITIES, e.g., real-time browsing, user account data, prior conversation history unless provided].

## Output Defaults
- Respond in [DEFAULT_FORMAT, e.g., plain text, Markdown, structured JSON] unless instructed otherwise.
- When presenting factual claims, [CITATION_POLICY, e.g., cite sources inline, note when information is unverifiable].
- For multi-step tasks, [REASONING_VISIBILITY, e.g., show your step-by-step reasoning, keep internal reasoning hidden and present only the final result].

To adapt this template, start by filling every placeholder with concrete, testable values. Avoid vague descriptors like 'be helpful' in favor of specific behavioral instructions such as 'when asked for a summary, provide a three-bullet TL;DR before the full response.' After substitution, run the prompt through a set of persona consistency evals: test that the assistant introduces itself correctly, maintains tone across at least ten conversation turns, refuses out-of-scope requests without leaking its system instructions, and expresses uncertainty rather than hallucinating when asked an unanswerable question. If the assistant will be used in a regulated domain, add a human-review requirement for high-stakes outputs and log every refusal for audit. This template is a starting point, not a finished product. Layer in tool-use authorization, safety policies, and domain-specific constraints as separate system message blocks after this identity foundation is stable.

This prompt is a system-level instruction, meaning it should be set once per session or per agent configuration and remain immutable across user turns. In a chat API, place the rendered template in the system role of the messages array. For stateless tool-calling agents, prepend it to the first user message or inject it into the model's system instruction field. The key implementation decision is whether the identity variables—such as [ASSISTANT_NAME], [TARGET_AUDIENCE], and [DOMAIN_CONSTRAINTS]—are resolved from a static configuration file, a database row, or a runtime feature flag. Hard-code nothing; every variable must be resolvable from a single source of truth so that persona updates do not require code changes. If your application supports multiple tenants or brands, store a system_prompt_template and a persona_config JSON blob per tenant, and assemble the final prompt at request time.

Validation must happen before the prompt reaches the model. Implement a preflight check that verifies all square-bracket placeholders have been replaced with non-empty strings. A common failure mode is a missing [OUTPUT_CONSTRAINTS] block that causes the assistant to drift into unwanted formats. Add a structural validator that confirms the assembled prompt contains required sections: identity statement, backstory, audience definition, tone rules, and refusal boundaries. Log the final rendered prompt with a unique prompt_version and assembly_id to your observability platform so you can trace persona-related failures back to the exact instructions the model received. For retry logic, if the model's first response violates the persona contract—detected via an LLM judge or keyword heuristic—retry once with an amplified instruction appended to the system prompt, such as 'The previous response violated your identity rules. Re-read your backstory and try again.' Do not retry more than twice; escalate to a human reviewer if persona consistency fails after two attempts.

Human review triggers should fire when the assistant's output contradicts its defined identity in a way that could cause brand damage or user confusion. For example, if a medical assistant persona fails to include a disclaimer, or a financial advisor persona gives definitive investment advice, flag the conversation for review. Implement this by running an eval prompt—separate from the main inference—that scores the output against the original persona contract on dimensions like tone adherence, role consistency, and boundary respect. If the score falls below a defined threshold, queue the interaction for human inspection. Avoid wiring this prompt into high-frequency, low-latency paths without caching the assembled system message; re-rendering it on every request wastes tokens and introduces latency. Instead, cache the resolved prompt per session or per configuration hash, and invalidate only when the underlying persona config changes.