Multi-Turn Chat Demonstration Prompt Template

This prompt template is for developers building conversational agents, copilots, or multi-turn API integrations where the model must produce a sequence of user and assistant turns with consistent role markers, optional tool calls, and state annotations. Use it when you need to generate synthetic conversation demonstrations for few-shot prompting, evaluation datasets, or to teach a model a specific multi-turn interaction pattern. This is not a prompt for running a live chat session. It is a meta-prompt that generates demonstration data you embed inside other prompts. It assumes you already have a target interaction pattern in mind and need the model to produce well-formatted examples that downstream systems can parse reliably.

The ideal user is an AI engineer or prompt architect who needs to programmatically generate training or evaluation data for a conversational system. You should have a clear specification of the desired turn structure, including how tool calls are interleaved, how state transitions are annotated, and what role markers your production parser expects. The prompt requires you to provide a target interaction pattern description, the number of turns, and any specific tool schemas or state variables that must appear. Without this context, the generated demonstrations will be generic and may not match your production format, leading to parser failures or model confusion when the examples are used in downstream prompts.

Do not use this prompt when you need a single-turn input-output pair, when you are generating data for a non-conversational task like classification or extraction, or when your production system uses a custom wire format that differs significantly from standard chat markup. This prompt is also inappropriate for generating live system responses—it produces static demonstration data, not runtime behavior. If your goal is to test a live agent's behavior, use an evaluation harness that sends real requests to the agent and captures its responses. If you need to teach refusal boundaries or safety policies through examples, pair this prompt with the Negative Example Formatting for Refusal Teaching prompt to ensure your demonstrations include appropriate boundary cases. After generating demonstrations, always validate them with a turn-boundary detection eval and a schema conformance check before embedding them in production prompts.

This template produces a multi-turn conversation demonstration that teaches the model consistent turn formatting, tool call interleaving, and state transition annotation. Use it when you need the model to internalize a specific interaction pattern—such as a support agent escalating to a human, a coding assistant calling a file-read tool, or a research agent updating its plan after new evidence arrives. The template enforces explicit role markers, optional tool call blocks, and optional state annotations so the model learns to separate user input, assistant reasoning, tool results, and state updates without ambiguity. Do not use this template when a single-turn instruction or a simple input-output pair would suffice; multi-turn demonstrations are expensive in tokens and should be reserved for patterns where turn ordering and state tracking are critical.

Below is the copy-ready template. Replace each square-bracket placeholder with concrete values for your use case. The [TOOL_CALL] and [STATE] lines are optional—remove them from any turn where they do not apply. Keep the delimiter conventions exactly as shown: --- separates turns, role markers are bolded, and tool calls use the TOOL >> prefix. Inconsistent delimiter formatting is the most common cause of schema drift and unexpected model behavior in multi-turn prompts.

textCopy
---
**User:** [USER_MESSAGE_1]

---
**Assistant:** [ASSISTANT_RESPONSE_1]
[TOOL_CALL]
TOOL >> [TOOL_NAME]([TOOL_ARGUMENTS])
[/TOOL_CALL]
[STATE]
STATE >> [STATE_KEY]: [STATE_VALUE]
[/STATE]

---
**Tool:** [TOOL_OUTPUT_1]

---
**Assistant:** [ASSISTANT_RESPONSE_2]
[STATE]
STATE >> [STATE_KEY]: [STATE_VALUE]
[/STATE]

---
**User:** [USER_MESSAGE_2]

---
**Assistant:** [ASSISTANT_RESPONSE_3]

To adapt this template for your application, start by defining the exact role markers your system uses. If your chat API uses user, assistant, and tool roles, map those directly. If you have additional roles such as system or function, add them with the same formatting pattern. For tool calls, replace [TOOL_NAME] with the actual function name and [TOOL_ARGUMENTS] with a JSON string or key-value representation that matches your function-calling schema. The [STATE] block is optional but valuable for teaching the model to track session-level variables such as escalation_required: true, plan_step: 3, or user_authenticated: false. Before shipping, validate that your delimiter sequence does not appear in user or tool content—if it can, switch to a less common delimiter or add escaping logic. For high-risk workflows such as healthcare or finance, add a human-review step that checks whether state transitions in the demonstration match your business rules before the prompt enters production.

The multi-turn chat demonstration prompt is not a standalone chat endpoint—it is a prompt generator that produces formatted example sequences for use inside other system prompts. The implementation harness must treat this prompt as a pre-processing step that runs before the main conversational agent receives its final instructions. The typical integration pattern is: (1) collect the target behavior description, tool definitions, and output schema; (2) call this prompt to generate a multi-turn demonstration block; (3) inject the generated demonstration into the system prompt of the downstream conversational agent; (4) validate that the assembled prompt parses correctly before deployment.

Validation and assembly checks are the most important part of the harness. Before injecting generated demonstrations into a production system prompt, run automated checks for: turn boundary detection (every user turn must have a corresponding assistant or tool response), role marker consistency (no mixed or malformed role prefixes), tool call argument schema conformance (validate against the provided tool definitions), and context contamination (ensure entities or facts from one example turn do not leak into unrelated turns). A lightweight validation script should parse the generated demonstration block, extract each turn, and assert these properties. If validation fails, retry the generation call with a more explicit error message appended to the input, or fall back to a manually curated demonstration set.

Model choice and latency considerations matter here. This prompt is typically run once per system prompt update—not per user request—so latency tolerance is higher. Use a capable model (GPT-4o, Claude 3.5 Sonnet, or equivalent) for generation quality. Cache the generated demonstration block and version it alongside the system prompt. When tool definitions or behavior requirements change, regenerate and re-validate. For high-risk conversational agents (healthcare, finance, legal), add a human review gate before the generated demonstrations are deployed: a domain expert should verify that the example turns do not teach unsafe patterns, over-refusal, or incorrect escalation behavior. Log every generated demonstration version with its validation results and reviewer sign-off for audit trails.

Integration with RAG and tool-calling agents requires extra care. If the downstream agent uses retrieval or function calling, the generated demonstrations must include realistic tool call interleaving and source citation patterns. The harness should accept a [TOOLS] placeholder containing the actual function schemas and a [CONTEXT] placeholder with sample retrieved passages. After generation, validate that every simulated tool call in the demonstration matches an actual function signature and that citation markers reference the provided context passages. When the agent's tool set changes, regenerate the demonstrations immediately—stale tool call examples are a leading cause of production agent failures.