Pending Action Queue Extraction Prompt

Task-oriented assistants fail silently when they drop commitments. A user asks for a follow-up email, a refund check, or a document review, and three turns later the assistant has forgotten it. This prompt extracts a deduplicated, prioritized list of pending actions, deferred tasks, and unanswered questions from the full conversation history. It is designed for chat and copilot systems where the assistant must track commitments across turns and surface them before they are lost. Use this prompt when you need a structured action queue that can be committed to external state, displayed to a human operator, or fed into a downstream execution loop.

The ideal user is an AI engineer or product developer building a multi-turn assistant that must not lose track of obligations. Required context includes the full conversation history, a clear definition of what constitutes an actionable commitment in your domain, and an output schema that your application can parse. The prompt works best when the assistant has been instructed to acknowledge tasks explicitly, giving the extractor clear signals to work with. You should wire the extracted queue into your application state so that completed items are removed and new items are captured on each turn. Validate the output against a known schema before committing it, and log extraction failures for review.

Do not use this prompt for real-time task execution or tool calling. It extracts what is pending, not what to do next. It is not a replacement for a task manager, a workflow engine, or a tool-use planner. If your assistant needs to execute actions immediately, use a function-calling or agent planning prompt instead. This prompt is also not suitable for sessions where commitments are never explicitly stated—it cannot infer obligations the user never expressed. For high-stakes domains such as healthcare or finance, always require human review of the extracted queue before any action is taken. The next step after reading this section is to review the prompt template and adapt the output schema to your application's specific action taxonomy.

This prompt template is designed to be appended to the end of a full conversation history. Its job is to scan every turn—both user and assistant—and extract a structured list of tasks, deferred actions, and unanswered questions that the assistant is responsible for. The output is a deduplicated, prioritized queue that your application can use to drive follow-up workflows, display a user-facing task list, or validate that no commitments were dropped. The prompt includes placeholders for your domain-specific action categories, prioritization rules, and output schema. Replace each square-bracket placeholder with values that match your product's task taxonomy and risk tolerance.

textCopy
You are an assistant that extracts a pending action queue from the full conversation history above.

Your task:
1. Scan every user and assistant turn in the conversation history.
2. Identify all explicit and implicit commitments, deferred tasks, unanswered questions, and follow-up actions that the assistant is responsible for.
3. Exclude actions that have been explicitly completed, resolved, or canceled in later turns.
4. Deduplicate semantically equivalent actions, keeping the most recent or specific version.
5. Assign each action a priority from [PRIORITY_LEVELS].
6. Assign each action a category from [ACTION_CATEGORIES].
7. For each action, include a brief evidence span quoting the turn where the commitment originated.

[CONSTRAINTS]
- Do not invent actions that are not grounded in the conversation.
- If no pending actions exist, return an empty queue.
- If the conversation is ambiguous about whether an action is complete, mark it as [UNCERTAIN_STATUS] and include a clarification note.
- Do not include actions that the user explicitly declined or said they would handle themselves.

[OUTPUT_SCHEMA]
Return a JSON object with this exact structure:
{
  "pending_actions": [
    {
      "id": "unique-action-id",
      "description": "Concise action description",
      "priority": "[PRIORITY_LEVEL]",
      "category": "[ACTION_CATEGORY]",
      "status": "pending|in_progress|blocked|uncertain",
      "origin_turn": "Brief quote or turn reference showing where this action was created",
      "dependencies": ["id-of-blocking-action"],
      "clarification_needed": "Question to resolve if status is uncertain, otherwise null"
    }
  ],
  "completed_actions": [
    {
      "id": "unique-action-id",
      "description": "Action description",
      "resolution_turn": "Brief quote or turn reference showing completion"
    }
  ],
  "extraction_notes": ["Any caveats about ambiguity, missing context, or assumptions made"]
}

[PRIORITY_LEVELS]
- critical: Must be resolved in this session before any other work
- high: Should be addressed next
- medium: Address when higher-priority items are cleared
- low: Nice-to-have, can be deferred

[ACTION_CATEGORIES]
- follow_up_question: A question the assistant needs to ask the user
- external_research: Information the assistant needs to look up or retrieve
- system_action: An action the assistant needs to perform in an external system
- summary_or_handoff: A summary or handoff document the assistant needs to produce
- verification: A fact or claim the assistant needs to verify

[RISK_LEVEL]
- If any action involves financial, legal, medical, or safety decisions, mark it as high_risk: true and require human approval before execution.

To adapt this prompt for your application, replace the [PRIORITY_LEVELS] and [ACTION_CATEGORIES] placeholders with your domain-specific taxonomies. If your system uses a different output schema, replace the [OUTPUT_SCHEMA] block with your own JSON structure, but keep the core fields: a unique action ID, a description, a status, and an evidence reference. The [CONSTRAINTS] section should be tightened for your risk tolerance—for example, in regulated domains, add a constraint that any action touching customer data must be flagged for human review. The [UNCERTAIN_STATUS] placeholder should be set to a status value your downstream system can handle, such as needs_clarification or pending_review. Before deploying, run this prompt against a golden dataset of conversations with known pending actions and measure precision, recall, and deduplication accuracy. Pay special attention to conversations where actions are implied rather than explicitly stated, as these are the most common source of false negatives.

The Pending Action Queue Extraction prompt is not a standalone feature—it is a state reconciliation step that must run reliably at session boundaries, on a timer, or before the assistant generates its next response. The core risk is drift: the model may fail to remove completed tasks, duplicate existing items, or hallucinate commitments the user never made. The implementation harness must treat the extracted queue as a proposed update to a source-of-truth action list, not as the authoritative state itself. This means every extraction result passes through a validation layer before it is committed to the application's action store.

Wire the prompt into your application as a pre-generation hook that fires after each user turn or after every N turns, depending on your latency budget and context window pressure. Pass the full conversation history (or a pruned, high-salience subset) as [CONVERSATION_HISTORY] and the current action queue as [EXISTING_QUEUE]. The model returns a JSON object with new_tasks, completed_tasks, carried_forward_tasks, and unresolved_questions arrays. Before accepting the output, run three validation checks: (1) schema validation—ensure every task object has required fields (id, description, priority, source_turn); (2) deduplication—compare new task descriptions against the existing queue using embedding similarity or fuzzy matching to prevent near-duplicate entries; (3) source grounding—verify that each source_turn reference exists in the conversation history and that the quoted text actually implies a commitment. If validation fails, retry the prompt once with the validation errors injected as [PREVIOUS_ERRORS]. If it fails twice, escalate to a human review queue or log the raw extraction for offline debugging.

For model choice, use a model with strong instruction-following and JSON mode support—GPT-4o, Claude 3.5 Sonnet, or equivalent. Set temperature=0 or very low (0.1) to minimize creative drift in task descriptions. If your application uses tool-calling, expose the extraction as a tool with a strict schema rather than relying on unstructured output parsing. Log every extraction result, including the raw model output, validation pass/fail status, and the final committed queue diff. This audit trail is essential for debugging dropped commitments and for demonstrating state integrity to compliance reviewers. Avoid running this prompt on every single turn in high-frequency chat applications—batch it or trigger it on detected topic shifts, session boundaries, or explicit user confirmation of task completion to keep latency and cost under control.