Pending Clarification Queue Prompt

This prompt is for AI assistants that need to track what they still require from the user across multiple conversation turns. It maintains a structured queue of clarification questions the assistant has asked but the user hasn't yet answered, with staleness timers and priority ordering. The core job-to-be-done is preventing dropped questions—the most common production failure mode in chat systems—by giving the assistant a reliable, programmatically consumable memory of outstanding requests. The ideal user is an AI engineer or technical product manager building a task-oriented assistant, copilot, or support agent where the assistant must gather missing information, preferences, or decisions from the user before proceeding with a workflow.

Use this prompt when your assistant asks the user for specific information and must remember those outstanding requests even after the user changes the subject, asks a counter-question, or provides partial answers. It belongs in the middleware layer between conversation history and response generation, feeding into your state management system. It is not a standalone question-answering prompt. It assumes you already have a mechanism for detecting when the assistant has asked a clarification question and when the user has provided an answer. The prompt's output is designed for programmatic consumption—your application code should parse the structured queue and use it to decide whether to re-surface questions, wait for answers, or retire items that have become stale.

Do not use this prompt for simple single-turn Q&A where no state tracking is needed, or for purely social chatbots where dropping a question has no operational consequence. It is also not a replacement for a database-backed state machine when you need transactional guarantees; the prompt augments your state tracking, it doesn't replace it. Avoid using it in high-latency real-time voice loops where the overhead of maintaining and parsing the queue adds unacceptable delay. Finally, this prompt is not designed to detect whether a question was asked in the first place—pair it with a dedicated question-detection prompt or classifier that feeds into this queue management layer.

This prompt template implements a Pending Clarification Queue for multi-turn assistants. It instructs the model to maintain a structured state object tracking every question the assistant has asked that the user has not yet answered. Each entry includes the question text, the turn it was asked, a staleness timer, and a priority score. The prompt also includes logic for retiring questions that the user has implicitly answered through subsequent turns, preventing the queue from growing stale and irrelevant.

textCopy
You are an assistant that maintains a Pending Clarification Queue. This queue tracks every question you have asked the user that remains unanswered. You must update this queue on every turn.

## QUEUE SCHEMA
Maintain a JSON array called `pending_clarifications`. Each entry must have:
- `id`: string, unique identifier for the question
- `question`: string, the exact question you asked the user
- `asked_at_turn`: integer, the conversation turn number when you asked
- `staleness_turns`: integer, number of turns since the question was asked without an answer
- `priority`: "blocking" | "high" | "medium" | "low", based on whether the answer is required to proceed
- `status`: "pending" | "implicitly_answered" | "retired"
- `implicit_answer_evidence`: string | null, if status is "implicitly_answered", quote the user text that answered it
- `retirement_reason`: string | null, if status is "retired", explain why (e.g., "topic changed", "user declined to answer", "question no longer relevant")

## BEHAVIOR RULES
1. **Add**: When you ask the user a clarification question, add it to the queue with status "pending".
2. **Resolve Explicit**: When the user directly answers a pending question, remove it from the queue.
3. **Detect Implicit**: After each user turn, scan all "pending" questions. If the user's response contains information that answers a pending question without addressing it directly, mark it "implicitly_answered" and populate `implicit_answer_evidence` with the relevant quote. Do not remove it; keep it for audit.
4. **Retire Stale**: If a question has `staleness_turns` > [STALENESS_THRESHOLD] and the conversation topic has clearly shifted, mark it "retired" with a reason. Do not re-ask retired questions unless the user returns to that topic.
5. **Re-surface**: On each turn, if there are "pending" questions with priority "blocking" or "high", you may re-surface the highest-priority one naturally in your response. Do not re-surface more than one question per turn. Do not re-surface if the user is mid-thought or clearly focused on a different urgent topic.
6. **Increment Staleness**: At the start of each turn, increment `staleness_turns` by 1 for all "pending" questions.
7. **Output the Queue**: At the end of every assistant response, output the full `pending_clarifications` array inside a `<pending_clarifications>` XML tag. This is your state output, not part of the user-facing message.

## CONSTRAINTS
- [CONSTRAINTS]: Any additional behavioral constraints, such as tone rules, domain-specific terminology, or compliance requirements.

## CURRENT STATE
- Current turn number: [CURRENT_TURN]
- Previous pending_clarifications: [PREVIOUS_QUEUE_STATE]
- Conversation history: [CONVERSATION_HISTORY]
- User message: [USER_INPUT]

Adaptation notes: Replace [STALENESS_THRESHOLD] with a concrete number based on your session length (3-5 turns is typical for support; 2-3 for real-time copilots). Replace [CONSTRAINTS] with domain-specific rules, such as 'never re-surface questions about billing during a technical troubleshooting flow.' The [PREVIOUS_QUEUE_STATE] placeholder should receive the parsed JSON from the last turn's <pending_clarifications> output. If this is the first turn, pass an empty array. Wire the output of this prompt into a state management layer that parses the XML tag, validates the JSON schema, and feeds it back as [PREVIOUS_QUEUE_STATE] on the next turn. For high-stakes domains like healthcare or finance, add a human review step before retiring questions marked 'implicitly_answered' to prevent incorrect assumptions about user intent.

The Pending Clarification Queue Prompt is not a standalone prompt; it is a state-management component that must be wired into a broader conversation loop. The prompt takes the current conversation transcript and the existing clarification queue as input, then returns an updated queue. Your application is responsible for persisting this queue object across turns, injecting it into the prompt context on each invocation, and acting on the queue's contents before generating the next assistant response. The queue should be treated as a structured data object (JSON) that lives alongside other session state, not as free text that gets summarized and lost.

The implementation loop follows a clear sequence. Before generating the assistant's next message, call this prompt with the full transcript and the current queue. The prompt returns an updated queue with new questions added, answered questions retired, and stale questions flagged. After receiving the updated queue, your application should: (1) validate the output schema—every queue item must have an id, question_text, status, turn_asked, and staleness_score; (2) check for duplicate questions using a simple embedding similarity or keyword overlap check against existing queue items; (3) apply a staleness threshold (e.g., retire questions with staleness_score > 0.8 or turns_unanswered > 5); and (4) inject the top-priority unresolved questions into the assistant's system prompt or context window so the assistant knows what it still needs from the user. Do not rely on the model to remember the queue across turns without explicit injection—context windows are lossy, and the queue is your source of truth.

For production deployments, add logging at each step: log the queue before and after the prompt call, log any validation failures, and log retirement decisions. This audit trail is essential for debugging dropped questions, which is the most common failure mode. Set up an eval harness that tests the prompt against curated transcripts with known clarification needs, measuring precision (did it catch real unanswered questions?), recall (did it miss any?), and false positives (did it flag rhetorical questions or already-answered items?). Run these evals on every prompt change. If the assistant operates in a domain where missed clarifications carry compliance or safety risk, route queue items above a severity threshold to a human review dashboard before the assistant acts on them. Finally, model choice matters: use a model with strong instruction-following and structured output capabilities (GPT-4o, Claude 3.5 Sonnet, or equivalent) because the task requires precise state tracking and schema adherence. Smaller or older models frequently drop items or produce malformed queue objects.