Multi-Role Output Disambiguation Prompt

This prompt is for engineering teams building compound AI systems where multiple roles—such as an analyst, critic, executor, and summarizer—contribute to a single output stream. Without explicit role tagging, downstream consumers cannot reliably route, render, or log which role produced which segment. The core job-to-be-done is creating a parseable contract between your model's output and your application layer, ensuring that every piece of content carries unambiguous provenance metadata.

The ideal user is a backend engineer or AI architect who already has a multi-role orchestrator, a UI that color-codes responses by role, or a logging pipeline that requires per-role audit trails. You should use this prompt when your system needs to separate contributions before the next processing step—for example, when a critic's feedback must be extracted and fed into a revision loop, or when an executor's tool call must be isolated from a summarizer's natural language commentary. The prompt wraps every output segment with a [ROLE: role_name] header and a [/ROLE: role_name] footer, creating a deterministic boundary that your parser can rely on without fragile heuristics.

Do not use this prompt for single-role assistants where disambiguation adds unnecessary token overhead. If your system has only one persona—a support bot, a code reviewer, or a generic chat assistant—adding role tags wastes context window space and introduces parsing complexity with no benefit. Similarly, avoid this pattern when your downstream system already has a reliable way to segment outputs, such as separate API calls per role or structured tool-use responses that carry their own identity. The prompt is a deliberate engineering choice for multi-role streams, not a default best practice.

The following prompt template is designed to be pasted directly into your system prompt or developer message. It instructs the model to act as a multi-role system where each role contributes to a single output stream. The core mechanism is a mandatory role-identification tag that precedes every segment of generated text. This allows downstream consumers—such as UI renderers, log processors, or API response parsers—to reliably route, style, or filter content by role without relying on brittle heuristics or post-hoc classification. Replace every square-bracket placeholder with your specific role definitions, output rules, and constraints before use.

textCopy
You are a multi-role AI system. You will respond using the following roles as needed: [ROLE_LIST].

## Role Definitions
[ROLE_DEFINITIONS]

## Output Protocol
- Every segment of your response MUST begin with a role tag on its own line in the exact format: `[ROLE: <role_name>]`.
- A segment is any contiguous block of text produced by a single role. If you switch roles, start a new segment with a new role tag.
- Do not combine output from multiple roles into a single segment.
- Do not add role tags mid-paragraph. A role tag always starts a new block.
- If you are unsure which role should respond, use the role: [DEFAULT_ROLE].

## Role Activation Rules
[ROLE_ACTIVATION_RULES]

## Output Constraints
[OUTPUT_CONSTRAINTS]

## Examples
[EXAMPLES]

## Current Task
User input: [USER_INPUT]
Context: [CONTEXT]

To adapt this template, start by defining your role list and each role's persona, tone, and domain of responsibility inside [ROLE_DEFINITIONS]. For example, a customer support system might define analyst, empathetic_responder, and supervisor roles. Next, populate [ROLE_ACTIVATION_RULES] with explicit triggers: 'Use the analyst role when the user asks a factual question about their account. Use the empathetic_responder role when the user expresses frustration.' The [OUTPUT_CONSTRAINTS] placeholder should contain any global formatting rules, such as 'All role segments must use plain text; no markdown unless the role definition explicitly permits it.' Finally, provide at least two concrete [EXAMPLES] showing a user input and the correctly tagged multi-role response. Before deploying, validate that your downstream parser can handle edge cases: a role tag appearing at the very start of the response, a response containing only one role, and a response where the model switches roles multiple times in a single turn. For high-stakes applications where incorrect role tagging could route sensitive information to the wrong consumer, add a post-processing validation step that rejects any output missing the expected role tags and triggers a retry or human review.

This prompt is designed to sit between a multi-role AI system and its downstream consumers—UIs, parsers, logging pipelines, and routing logic. Its primary job is to annotate every output segment with a role_id and segment_boundary marker so that consuming code can reliably split a single model response into per-role payloads. Without this disambiguation layer, a support agent's empathetic message and a diagnostic agent's JSON error code can blend into an unparseable blob. The harness must treat the model's output as a structured stream of annotated segments, not as a single prose response.

Wire the prompt into your application by placing it as the final formatting instruction before the model returns a user-facing or system-facing response. In a typical orchestration flow: (1) upstream roles generate their content, (2) a coordinator assembles the multi-role output, and (3) this disambiguation prompt wraps the assembled content with role tags and boundary markers. On the application side, implement a post-processing parser that splits the response on the defined [SEGMENT_BOUNDARY] token, extracts each role_id, and routes the segment payload to the correct handler. Validate every segment: if a role_id is missing, unrecognized, or duplicated in an unexpected way, log the raw output and either retry with a stricter prompt or escalate to a human reviewer. For high-stakes domains like healthcare or finance, add a human approval gate that displays the disambiguated segments side-by-side before they reach end users or downstream APIs.

Choose a model that reliably follows structured output instructions—GPT-4o, Claude 3.5 Sonnet, and Gemini 1.5 Pro are strong candidates. Avoid smaller or older models that tend to merge segments or drop role tags under long-context pressure. Implement retry logic with a maximum of two attempts: if the parser detects malformed segments, feed the raw output and the specific parse error back into the model with a correction instruction. Log every disambiguation attempt, including the raw model response, parse success/failure, segment count, and role distribution. These logs become your primary debugging tool when a downstream consumer receives misrouted content. For production observability, emit metrics on segment boundary detection accuracy, role-tagging consistency, and parse failure rate so your team can detect prompt drift before users report broken outputs.