Multi-Role Activation Trigger Prompt

This prompt is for architects of compound AI systems who need to define explicit conditions under which different roles activate within a session. Use it when a single conversation requires multiple specialized personas, such as a triage agent handing off to a support agent, a coding assistant switching between architect and reviewer modes, or a research assistant moving from data gathering to synthesis. The prompt establishes a rule set for role selection, transition triggers, and boundary enforcement so the model does not drift between roles or activate the wrong persona at the wrong time.

Before using this prompt, you must have already defined stable system prompts for each individual role. This prompt does not create personas; it governs their activation. The ideal implementation context is an application layer that maintains a session state object tracking the current active role, conversation history, and any unresolved items from prior roles. The prompt works by injecting a structured activation schema—typically a JSON block of trigger conditions, role definitions, and transition rules—into the system instructions at the start of each turn. The model evaluates the user's input against these triggers and either continues in the current role or emits a structured role-switch signal that your application layer parses to swap the active system prompt. Do not use this prompt for single-role assistants, simple chatbots, or workflows where role switching is managed entirely by application logic outside the model. If your router is a deterministic classifier or a separate lightweight model call, you do not need the LLM to self-manage role transitions.

The primary failure mode to avoid is ambiguous role boundaries. When two roles have overlapping capabilities—for example, a 'support agent' and a 'technical specialist' who can both answer product questions—the model may oscillate between them or default to the most recently active role. Mitigate this by defining mutually exclusive trigger conditions and including a tie-breaking rule in the prompt. A secondary risk is context loss during handoffs. When a role switch occurs, the new role must receive a structured handoff summary containing the user's original intent, any decisions made, and unresolved items. Without this, the user experiences a reset. Build your application harness to extract this handoff payload from the model's role-switch signal and prepend it to the new role's context window. For high-stakes domains such as healthcare or finance, require a human review step before any role transition that changes the scope of advice or action authority.

After deploying this prompt, test it with adversarial sequences designed to confuse role boundaries: rapid topic switching, requests that sit at the intersection of two roles, and user messages that impersonate system instructions. Your eval suite should measure role selection accuracy, transition latency, and handoff context fidelity. If the model activates the wrong role more than 5% of the time in your test set, revisit your trigger condition specificity before shipping.

This prompt template establishes a multi-role architecture within a single system message. It defines distinct roles, each with its own behavioral contract, and specifies the exact conditions under which each role activates. The template uses explicit triggers—user intent signals, keyword patterns, or conversation state—to switch between roles, preventing ambiguity about which persona is active at any moment. Use this when building a single assistant that must handle fundamentally different interaction modes, such as a support agent that triages tickets, answers technical questions, and escalates to a human, each requiring a different tone, knowledge boundary, and output format.

Below is the copy-ready template. Place it in your system message or as a prefix to the conversation context. Replace square-bracket placeholders with your specific roles, triggers, and rules before deployment. The [ROLE_DEFINITIONS] section defines each role's identity, capabilities, and constraints. The [ACTIVATION_RULES] section specifies the triggers that activate each role, including priority when multiple triggers match. The [TRANSITION_RULES] section governs how context transfers between roles and what cleanup occurs on role exit. The [DEFAULT_ROLE] placeholder defines which role is active at session start and when no trigger matches.

textCopy
# SYSTEM INSTRUCTION: MULTI-ROLE ACTIVATION

You are a multi-role assistant operating under strict role activation rules. You may only adopt one role at a time. You must follow the activation triggers, transition rules, and role-specific constraints defined below.

## ROLE DEFINITIONS

[ROLE_DEFINITIONS]

<!-- Define each role with: name, description, behavioral contract, output format, capability scope, and constraints. Example:

ROLE: triage_agent
DESCRIPTION: Initial contact role that classifies user intent and routes to appropriate handling.
BEHAVIOR: Professional, concise, asks clarifying questions when intent is ambiguous. Never provides substantive answers.
OUTPUT_FORMAT: JSON with fields: {"intent": "<classified_intent>", "confidence": <0.0-1.0>, "routing_target": "<role_name>", "summary": "<one-line summary>"}
CONSTRAINTS: Do not answer questions. Do not make promises. Do not access external tools.

ROLE: technical_support
DESCRIPTION: Handles technical troubleshooting and product questions.
BEHAVIOR: Patient, step-by-step, asks diagnostic questions before suggesting solutions. Cites documentation when available.
OUTPUT_FORMAT: Markdown with sections: Diagnosis, Steps Taken, Recommended Action, References.
CONSTRAINTS: Do not guess about system internals. Do not suggest actions that modify production systems without confirmation.
-->

## ACTIVATION RULES

[ACTIVATION_RULES]

<!-- Define triggers for each role with priority order. Example:

TRIGGER: triage_agent
CONDITION: Session start OR user message contains no clear technical question OR previous role completed and returned control.
PRIORITY: 1 (lowest, default)

TRIGGER: technical_support
CONDITION: User describes a technical problem, error message, or asks a how-to product question.
PRIORITY: 2

TRIGGER: escalation
CONDITION: User requests manager OR user expresses frustration after 2+ unresolved turns OR issue requires human authority.
PRIORITY: 3 (highest)
-->

## TRANSITION RULES

[TRANSITION_RULES]

<!-- Define how roles hand off context and what state resets. Example:

ON_TRANSITION:
- The outgoing role must produce a handoff summary with: active issue, steps taken, unresolved questions, user sentiment.
- The incoming role must acknowledge the handoff summary before proceeding.
- Tool call state resets on every transition.
- User preferences persist across transitions unless explicitly reset.
-->

## DEFAULT ROLE

[DEFAULT_ROLE]

<!-- Specify the role active at session start. Example: triage_agent -->

## ROLE ACTIVATION OUTPUT FORMAT

When activating a new role, prefix your first response with:
[ROLE_ACTIVATED: <role_name>]
[TRIGGER: <trigger_condition_that_fired>]

Then proceed with the role-specific output format.

To adapt this template, start by defining only the roles you genuinely need—each additional role increases the risk of incorrect activation. Write activation triggers as specific, testable conditions rather than vague descriptions. Avoid overlapping triggers that could match the same input; if overlaps exist, assign explicit priorities. Test role transitions with adversarial inputs that sit at trigger boundaries, such as a frustrated user who also has a technical question, to verify that priority rules resolve correctly. For high-stakes deployments, add a [CONFIDENCE_THRESHOLD] rule that routes to a human or fallback role when no trigger exceeds a minimum confidence score. Log every role activation and transition in your application layer so you can audit whether the correct role fired for each user turn.

The Multi-Role Activation Trigger Prompt is not a standalone chat prompt—it is a routing and state-management component that sits between your application's conversation manager and the language model. Its job is to inspect the current conversation state, user input, and active role, then return a structured decision about whether a role transition should occur and which role should activate next. This prompt should be called as a pre-processing step before every model turn in a multi-role system, or at minimum whenever the user's request falls outside the current role's declared capability boundary. The output is a machine-readable JSON decision that your application must parse and enforce, not a user-facing message.

Wire this prompt into your application as a synchronous check before the main generation call. Your application should maintain a session state object containing active_role, role_history (a stack or list of previous roles with timestamps), conversation_summary, and the current user_input. Pass these into the prompt's [SESSION_STATE] and [USER_INPUT] placeholders. The model returns a JSON object with fields like triggered, target_role, handoff_summary, and confidence. Your application must validate this output against a schema before acting on it. If triggered is true and confidence exceeds your threshold (we recommend 0.85 or higher for production), execute the role transition by updating active_role, pushing the old role onto role_history, and injecting the handoff_summary into the new role's system prompt as context. If triggered is false, proceed with the current role. If the JSON fails schema validation, log the failure, retry once with a repair prompt, and if it still fails, fall back to the current role and raise a non-blocking alert for manual review.

Role transition boundaries are high-risk surfaces. A misclassified transition can route a sensitive user request to a role that lacks the appropriate refusal policy or capability constraints. Implement three safety checks in your harness: (1) a hardcoded allowlist of valid role-to-role transitions—if the model proposes a transition not in the allowlist, reject it and log a policy violation; (2) a confirmation step for transitions into roles with elevated permissions (such as roles that can execute tools, access PII, or modify account state)—require explicit user confirmation or a secondary classifier before activating; (3) a transition frequency limiter that prevents rapid role oscillation (more than two transitions within five turns should trigger a stall and fallback to a generalist dispatcher role). Log every transition decision with the model's raw output, the validated decision, the session state before and after, and any overrides your application applied. These logs are essential for debugging role drift and for audit trails in regulated deployments.

For model selection, use a fast, instruction-following model for this routing prompt—GPT-4o-mini, Claude 3.5 Haiku, or a fine-tuned small model are good choices. The routing prompt should be low-latency because it adds a pre-processing step to every turn. Do not use the same model instance that handles the main generation; keep the routing model separate so you can tune its temperature (set to 0 or near-zero for deterministic role selection) and its system prompt independently. If your application uses tool-augmented agents, ensure the routing prompt has access to the current role's capability declaration so it can accurately detect when a user request exceeds the active role's scope. The routing prompt should never have access to tools itself—it is a read-only classifier, not an actor.

Before deploying, build an eval harness that tests role selection accuracy across at least 50 hand-labeled examples covering clear in-role requests, clear out-of-role requests, ambiguous boundary cases, and adversarial inputs designed to trick the router into selecting an inappropriate role. Measure precision and recall per role transition type. Pay special attention to false positives (unnecessary transitions that disrupt the user experience) and false negatives (missed transitions that leave the user stuck with a role that cannot help). Set your confidence threshold based on the precision-recall trade-off your application can tolerate. Run this eval suite as a gate in your CI pipeline whenever the routing prompt, role definitions, or transition allowlist changes.