Role Conflict Resolution Prompt for Multi-Hat Assistants

This prompt is for platform engineers and AI product teams whose assistants must serve multiple roles—such as a support agent that also handles sales inquiries, or a coding assistant that also enforces security policy—where those roles can issue conflicting directives. The job-to-be-done is producing a stable, testable priority scheme that resolves conflicts between role obligations, selects the correct role for a given context, and discloses conflicts to the user when they cannot be cleanly resolved. The ideal user is an engineer who already has a working multi-role system prompt and is now hitting production failures: the assistant over-refuses, silently switches roles mid-conversation, or applies the wrong role's constraints to a task.

Use this prompt when you have at least two explicit role definitions with documented obligations, and you need a conflict-resolution layer that sits above them. It is appropriate when role conflicts are structural—for example, a 'be helpful' obligation colliding with a 'never disclose account details' obligation—rather than stylistic. The prompt expects you to provide a list of roles, their priority order, context-dependent selection rules, and examples of past conflicts. It is not a prompt for defining roles from scratch; use the Role Boundary Definition Prompt for Production Assistants or Assistant Persona Construction Prompt Template for that. Do not use this prompt when you have a single role, when conflicts are purely tonal, or when you need a general-purpose safety policy rather than role-specific conflict logic.

Before using this prompt, ensure you have catalogued the specific conflicting obligations that are failing in production. The prompt works best when you feed it real conflict examples, not hypotheticals. After generating the resolution rules, you must run the included role-conflict stress tests and resolution consistency checks before shipping. If the assistant operates in a regulated domain, add a human-review step for any conflict that cannot be resolved deterministically. The output of this prompt should become a section of your system prompt, not the entire system prompt—it is a conflict-resolution module that sits alongside your role definitions and behavioral policies.

This template provides the structural foundation for an assistant that must serve multiple, potentially conflicting roles—such as a support agent that also handles sales, or a coding assistant that must enforce security policy. The prompt is designed to be inserted into the system-level instructions of a multi-hat assistant. It establishes a clear priority hierarchy, context-dependent role selection rules, and mandatory conflict disclosure language. Use this template when your assistant's roles have overlapping or contradictory obligations, and you need deterministic behavior rather than leaving conflict resolution to the model's default judgment.

codeCopy
# ROLE CONFLICT RESOLUTION PROTOCOL

You serve multiple roles: [ROLE_LIST]. Each role has distinct obligations, constraints, and communication styles defined in the sections below.

## ROLE DEFINITIONS
[ROLE_DEFINITIONS]

## PRIORITY RULES
When obligations from different roles conflict, resolve using this priority order:
1. [HIGHEST_PRIORITY_RULE]
2. [SECOND_PRIORITY_RULE]
3. [THIRD_PRIORITY_RULE]

## CONTEXT-DEPENDENT ROLE SELECTION
Select your active role based on these triggers:
- When [CONTEXT_CONDITION_1], operate as [ROLE_A] and apply [ROLE_A_CONSTRAINTS].
- When [CONTEXT_CONDITION_2], operate as [ROLE_B] and apply [ROLE_B_CONSTRAINTS].
- When [CONTEXT_CONDITION_3] is ambiguous, ask [CLARIFICATION_QUESTION] before proceeding.

## CONFLICT DISCLOSURE RULES
If you detect a conflict between roles that cannot be resolved by the priority rules above:
1. State the conflict explicitly: "I notice a conflict between my role as [ROLE_X] and [ROLE_Y]."
2. Explain the conflicting obligations without favoring either role.
3. Ask the user which role should take precedence for this request.
4. Do not proceed until the conflict is resolved.

## OVERRIDE CONDITIONS
[USER_ROLE] may override role priority by stating: [OVERRIDE_PHRASE]. When overridden, acknowledge the override and proceed under the specified role.

## PROHIBITED ROLE COMBINATIONS
Never combine the following roles in a single response: [PROHIBITED_COMBINATIONS]. If a request requires both, disclose the conflict and ask for role selection.

## TEST DIRECTIVES
When you receive [TEST_TRIGGER_PHRASE], output your active role, the priority rule that selected it, and any suppressed roles.

To adapt this template, replace each square-bracket placeholder with concrete values from your assistant's role taxonomy. The [ROLE_DEFINITIONS] placeholder should contain the full persona, capability, and constraint definitions for each role—reference your existing persona construction prompts here. The priority rules must be total and transitive: every possible role pair must have a deterministic resolution path. If your assistant operates in a regulated domain, add a [COMPLIANCE_OVERRIDE] rule at the highest priority level that blocks any role behavior violating regulatory requirements, regardless of other priorities. Before deploying, run the conflict stress tests from the companion evaluation section to verify that the priority rules produce consistent resolutions across edge cases. If you observe non-deterministic role selection in production, add more specific context conditions or reduce the number of active roles.

The role conflict resolution prompt is not a standalone chat interaction—it is a policy compiler that runs before your multi-hat assistant processes user requests. In production, you should execute this prompt once during system initialization or policy refresh, cache its output as structured priority rules, and then inject those rules into every subsequent user-facing prompt. Do not call this resolution prompt on every user turn; the latency cost and token overhead are unnecessary once the conflict map is stable.

Wire the prompt into an offline policy generation pipeline. At startup or on a schedule, call the model with the full role definitions, conflict scenarios, and the output schema. Validate the returned JSON against a strict schema that requires: a priority_rules array with condition, winning_role, and rationale fields; a conflict_disclosure_template string; and a role_selection_flow object mapping context triggers to role selections. If validation fails, retry once with the validation errors injected into the prompt as [PREVIOUS_ERRORS]. After two failures, fall back to a human-curated default conflict map and log an alert. Store the validated output in a configuration store (e.g., a database row, a feature flag, or a Redis key) keyed by a version hash of the input role definitions so you can detect when roles change and re-trigger compilation.

For runtime enforcement, inject the resolved priority_rules and conflict_disclosure_template into your assistant's system prompt as a dedicated ## Role Conflict Policy section. When the assistant encounters a situation matching a conflict condition, it must reference the winning role and, if the conflict is user-visible, emit the disclosure language. Log every conflict trigger event with the matched condition, selected role, and whether disclosure was used. Run periodic consistency evals: replay a fixed set of conflict scenarios through the assistant and verify that the role selection matches the compiled priority rules at least 95% of the time. If drift exceeds the threshold, re-trigger the policy compilation pipeline. For high-stakes domains, route conflict-resolution decisions above a configurable risk score to a human review queue before the assistant acts.