Slot-Filling Clarification Prompt for Task Agents

This playbook is for developers building task-oriented assistants that must collect a specific set of structured parameters from a user across multiple conversation turns. The ideal job-to-be-done is a deterministic, state-aware dialogue where the assistant acts as a form-filling engine, not an open-ended chatbot. Use this when your assistant needs to gather 3 to 15 required slots—such as meeting details, ticket fields, or device configuration parameters—and you need the system to reliably track which slots are filled, which are missing, and which one to ask for next, without re-prompting for information the user has already provided.

The prompt is designed for a specific architectural pattern: a state machine managed in the application layer that feeds a structured state object into the prompt on every turn. The model's only job is to reason about that state and produce a deterministic JSON output containing the next action. This is not a prompt for handling casual chit-chat, answering general knowledge questions, or managing a conversation with an unbounded set of intents. It is a poor fit for workflows where the required parameters are unknown at the start of the session or where the user's goal shifts fluidly. In those cases, a more flexible intent-routing architecture with dynamic tool selection is a better choice.

Before implementing this, ensure you have a defined schema for your task's required slots, including their types, priorities, and validation rules. The prompt's value is in its strict adherence to a state machine; it will not invent slots or infer user intent beyond the provided schema. If your use case involves high-risk actions like financial transactions or medical scheduling, you must add a human review step before executing the final task. The prompt itself will not make safety judgments. Proceed to the next section to copy the prompt template and wire it into your state management logic.

This prompt template is designed to be inserted into your system message for a task-oriented agent. It assumes your application harness maintains a structured state object of [CURRENT_SLOTS] and a [REQUIRED_SLOTS] schema. The prompt instructs the model to act as a state machine: it must check which required slots are still missing, select the single highest-priority missing slot, and generate one targeted clarification question. It must not re-ask for slots that are already filled and must validate any new information the user provides against the expected type and constraints for that slot.

textCopy
You are a task agent responsible for collecting required information from the user to complete a task. You operate on a strict slot-filling protocol. Do not proceed to task execution until all required slots are filled and validated.

CURRENT KNOWN SLOTS:
[CURRENT_SLOTS]

REQUIRED SLOT SCHEMA:
[REQUIRED_SLOTS]

SLOT-FILLING PROTOCOL:
1. **Check for completeness:** Compare `[CURRENT_SLOTS]` against `[REQUIRED_SLOTS]`. If all required slots have valid, non-null values, respond with `[COMPLETION_CONFIRMATION]` and stop the slot-filling loop.
2. **Identify missing slots:** Create a list of slots that are missing or have invalid values according to the schema.
3. **Prioritize:** Select the single highest-priority missing slot. Priority is defined by the `priority` field in `[REQUIRED_SLOTS]` (lower number = higher priority).
4. **Validate new input:** If the user's last message provides a value for a missing slot, validate it against the `type` and `constraints` in `[REQUIRED_SLOTS]`. If valid, update the slot. If invalid, do not update the slot and instead ask for the value again, explaining the constraint.
5. **Ask one question:** Generate a single, clear, and concise question asking for the value of the highest-priority missing slot. Do not ask about multiple slots at once. Do not re-ask for slots that are already filled.
6. **Handle ambiguity:** If the user's input is ambiguous for a slot, ask a targeted disambiguation question specific to that slot before moving on.

CONSTRAINTS:
[CONSTRAINTS]

EXAMPLES:
[EXAMPLES]

To adapt this template, replace the placeholders with your application's runtime state. [CURRENT_SLOTS] should be a JSON or YAML object of filled key-value pairs. [REQUIRED_SLOTS] should be a schema defining each slot's type, priority, and constraints. The [CONSTRAINTS] block is where you inject domain-specific rules, such as 'never ask for a user's password' or 'confirm the email address format.' The [EXAMPLES] block is critical for teaching the model the desired tone and format of the clarification question. Without examples, the model may default to verbose, multi-part questions that violate the single-question rule. After the agent signals completion via [COMPLETION_CONFIRMATION], your application harness should hand control to the execution phase of your workflow.

The slot-filling clarification prompt is not a standalone chatbot; it is a stateful component inside a larger task agent loop. The application must maintain a structured session state object that tracks required slots, their current values, fill status, and the history of clarification questions asked. Before each call to the LLM, the harness serializes this state into the [CURRENT_STATE] placeholder, including only the slots that are still missing or have been partially filled. After the model responds, the harness parses the structured output to update the state, not to display the response directly to the user unless the model explicitly returns a clarification_question.

The core implementation loop follows a strict pattern: hydrate state → assemble prompt → call model → validate output → update state → decide next action. If the model returns a filled_slot with a value, the harness must validate that value against the slot's constraints (type, enum membership, regex pattern, or business rule) before accepting it. If validation fails, the harness should re-invoke the prompt with the validation error injected into [PREVIOUS_ERRORS] rather than silently discarding the bad fill. This prevents the model from repeating the same invalid extraction pattern. For high-stakes domains like healthcare or finance, insert a human review gate after slot validation but before the slot is committed to the downstream system of record.

Retry logic must be bounded. A common failure mode is the model returning a clarification_question for a slot it already asked about in a prior turn, creating a frustrating loop. The harness should track asked_slots in session state and, if the model proposes a clarification for a previously asked slot, either escalate to a human agent or force the model to proceed with a best-guess assumption by setting [FORCE_ASSUMPTION] to true in the next prompt call. Implement a maximum of two clarification attempts per slot before falling back to a default or escalating. Log every state transition, validation result, and retry decision to your observability platform for debugging slot-filling loops in production.

Model choice matters here. This prompt requires strong instruction-following and structured output capabilities. Prefer models with native JSON mode or function-calling support (e.g., GPT-4o, Claude 3.5 Sonnet) and use their built-in structured output features to enforce the [OUTPUT_SCHEMA] rather than relying solely on prompt instructions. For local or open-weight models, pair this prompt with a schema validation library like instructor or outlines to guarantee parseable JSON. Never pass raw model output directly to your state update logic without schema validation—malformed JSON or hallucinated slot names will corrupt session state and produce broken user experiences.