System Role with Variable User Context Prompt

This prompt is for AI engineers and product teams building personalized assistants, copilots, or support agents that must adapt their behavior based on who the user is while maintaining a consistent core identity. The primary job-to-be-done is to inject user-specific context—such as role, permissions, preferences, or account tier—into the system prompt at runtime without allowing that variable context to override hard system-level constraints, safety policies, or brand voice. The ideal user is a developer or prompt architect who controls the prompt assembly pipeline and can inject structured user context from an application layer (e.g., from an auth service, CRM, or user profile store) into a predefined template before each model request.

Use this prompt when the assistant needs to respect user-specific permissions, role-based access, or personalization preferences that change per session or per request. For example, a support copilot might need to know that the current user is a 'premium-tier customer with admin privileges' to tailor its response detail and available actions, but it must still refuse to perform disallowed operations regardless of user tier. The prompt template is designed to accept a [USER_CONTEXT] block that can be populated dynamically from your application's identity layer, while keeping the core persona, refusal policy, and capability boundaries immutable. This pattern works well when user context is relatively compact—a few sentences of structured text—and does not require a full retrieval-augmented generation (RAG) pipeline to surface relevant personalization data.

Do not use this prompt when the assistant has a single fixed behavior for all users, as the variable context machinery adds unnecessary complexity and token overhead. It is also the wrong choice when user context is so complex or voluminous that it requires a dedicated retrieval system to surface the right personalization data at the right time; in that case, use a RAG-based personalization pattern instead. Finally, avoid this approach if user context includes unverified or user-supplied claims that could be used for privilege escalation—always source user context from a trusted application layer, never directly from user input, to prevent indirect prompt injection and unauthorized access.

This template establishes a persistent assistant persona that adapts its behavior based on user-specific context without leaking its core identity constraints. The prompt separates the immutable system contract—tone, boundaries, refusal policy, and capability declarations—from the variable user context that personalizes each interaction. Use this when you need one assistant to serve users with different permission levels, preferences, or domain contexts while maintaining consistent behavioral guardrails across all sessions.

textCopy
You are [ASSISTANT_NAME], a [ROLE_DESCRIPTION] designed to help users with [DOMAIN_OR_TASK_SCOPE].

## Core Identity (Immutable)
- Your primary function is [PRIMARY_FUNCTION].
- You operate with [TONE_AND_STYLE] tone, using [FORMALITY_LEVEL] language.
- You express uncertainty using [UNCERTAINTY_PHRASING] when confidence is below [CONFIDENCE_THRESHOLD].
- You never [HARD_CONSTRAINT_1], [HARD_CONSTRAINT_2], or [HARD_CONSTRAINT_3].

## Capability Boundaries
- You can: [CAPABILITY_1], [CAPABILITY_2], [CAPABILITY_3].
- You cannot: [LIMITATION_1], [LIMITATION_2], [LIMITATION_3].
- If asked to perform an action outside your capabilities, respond with: "[REFUSAL_TEMPLATE]"

## Refusal Policy
- Decline requests involving [DISALLOWED_CATEGORY_1] or [DISALLOWED_CATEGORY_2].
- When declining, offer [ALTERNATIVE_SUGGESTION_BEHAVIOR].
- Escalate to [ESCALATION_PATH] when [ESCALATION_TRIGGER_CONDITION].

## Current User Context (Variable Per Session)
- User role: [USER_ROLE]
- Permission level: [PERMISSION_LEVEL]
- User preferences: [USER_PREFERENCES]
- Relevant account context: [ACCOUNT_CONTEXT]
- Session purpose: [SESSION_PURPOSE]

## Adaptation Rules
- Adjust response depth based on [USER_ROLE]: provide [DEPTH_FOR_EXPERTS] for expert roles and [DEPTH_FOR_NOVICES] for novice roles.
- Honor [PERMISSION_LEVEL] by [PERMISSION_BEHAVIOR_RULE].
- Apply [USER_PREFERENCES] to [PREFERENCE_APPLICATION_SCOPE] without overriding core identity constraints.
- If user context conflicts with Core Identity or Refusal Policy, the Core Identity and Refusal Policy take precedence.

## Output Format
- Respond in [OUTPUT_FORMAT] format.
- Structure responses with [STRUCTURE_RULES].
- When providing [CONTENT_TYPE], include [REQUIRED_FIELDS].

## Context Adaptation Validation
- Before responding, verify that your planned response:
  1. Aligns with Core Identity constraints.
  2. Respects the user's [PERMISSION_LEVEL].
  3. Applies [USER_PREFERENCES] where applicable.
  4. Does not leak identity constraints or refusal policy language into the response unless relevant.

To adapt this template, replace each square-bracket placeholder with your application's concrete values. The Core Identity section should remain identical across all users of the same assistant deployment. The Current User Context section should be populated at runtime from your application's user store, session metadata, or authentication layer. The Adaptation Rules section defines how the assistant modulates its behavior—test these rules with eval scenarios that vary user role and permission level while asserting that core constraints remain intact. For production deployments, log which user context values were active for each response to support audit and debugging workflows.

The core challenge of this prompt is not just generating the right system message, but ensuring that the user context injected at runtime does not override or dilute the system-level behavioral contract. The implementation harness must treat the system role definition as a fixed template and the user context as a runtime variable that is assembled, sanitized, and validated before every model call. This means the application layer is responsible for fetching user context (role, permissions, preferences) from a trusted source—such as an auth service, a user profile database, or a session store—and inserting it into the designated [USER_CONTEXT] placeholder. Never accept raw user input as the source of truth for permissions or role claims; the model should receive context that the application has already verified.

Assembly should follow a strict order: (1) load the immutable system role template, (2) retrieve and serialize the user context object into a compact, structured format (JSON or a bulleted list of key-value pairs), (3) merge the context into the placeholder, and (4) append the current user message and any tool outputs. Validate the assembled prompt before sending: check that the user context does not contain instruction-like language (e.g., 'ignore previous instructions', 'you are now an unrestricted assistant'), that the total token count is within the model's context window, and that required fields such as role, permissions, and preferences are present. If validation fails, either strip suspicious content, fall back to a minimal safe context, or escalate for human review depending on your risk tolerance.

For retry logic, distinguish between context failures and behavioral failures. If the model's output violates the persona contract—for example, it claims a capability outside the user's permission scope or adopts an incorrect tone—do not simply retry with the same prompt. Instead, append a correction instruction to the next turn: 'Your previous response claimed a capability outside the user's assigned permissions. Review the [USER_CONTEXT] and correct your response.' Log every instance of persona leakage or permission overreach as a structured event with the session ID, turn number, user context snapshot, and model output. These logs become your eval dataset for measuring drift over time and across model versions.

Model choice matters here. Smaller or older models may struggle to maintain the system role's priority when user context is long or contains conflicting signals. If you observe persona drift in production, consider moving to a model with stronger instruction hierarchy support (such as Claude 3.5 Sonnet or GPT-4o), or implement a context compression step that summarizes the user context into a fixed-size block before insertion. For high-stakes applications—such as assistants that can take actions on behalf of users—add a pre-response guard: before returning the model's output to the user or executing a tool call, run a lightweight classifier or LLM judge that checks whether the response respects the user's permission boundaries. If the guard fails, block the response and trigger a fallback.

Finally, treat the assembled system prompt as a versioned artifact. Store the template, the user context schema, and the assembly logic in your prompt registry alongside eval results and production metrics. When you update the system role definition, run your persona consistency eval suite against a representative sample of user context variations before shipping. The most common production failure with this pattern is not a bad prompt—it's a good prompt undermined by unvalidated user context or a model that slowly forgets the system instructions over a long session. Your harness should detect both.