Slot-Filling Clarification Prompt for Structured Data

This prompt is designed for AI agents that must collect multiple structured fields from a user across several conversational turns. The core job-to-be-done is incremental, validated data intake for a known schema. Ideal users are developers building form-filling assistants, onboarding bots, data-intake agents for CRMs, or any workflow where a user provides information piece by piece in a chat. The required context is a predefined, ordered list of critical fields (a schema) and a mechanism to track which slots have been successfully filled. The prompt's primary value is its progress-awareness: it requests only the next unfilled critical field, validates the user's response against the field's constraints, and then moves on, rather than overwhelming the user with a wall of questions or silently hallucinating defaults for missing data.

You should use this prompt when the user's goal is to complete a known form or record, and the interaction is a cooperative, turn-by-turn dialogue. For example, an IT support bot collecting details for a ticket (e.g., [SEVERITY], [SYSTEM], [SUMMARY]) or an HR onboarding agent gathering new-hire information. The implementation must include a state manager outside the prompt to track filled slots and a validator for each incoming piece of data. A critical constraint is that the agent must never guess or assume a value for a missing field. If a user provides information for multiple fields in one turn, the harness should validate and fill all applicable slots before prompting for the next missing one. The prompt is not suitable when all required fields are available upfront in a single user message, when the schema is dynamic and cannot be defined ahead of time, or when the user expects to provide information in a freeform, unstructured manner without guided prompts.

Do not use this prompt for open-ended conversations, for collecting a single piece of data, or when the cost of a wrong field is low enough that a batch confirmation at the end is sufficient. If the workflow involves high-risk data (e.g., personally identifiable information, financial details, or healthcare data), the harness must include a human review step before the collected data is written to a system of record. The next step after reading this section is to define your exact field schema and failure modes before adapting the prompt template in the following section.

This prompt template implements a progress-aware slot-filling agent. Instead of overwhelming the user with a request for all missing fields at once, the agent maintains an internal state of collected fields, identifies the single highest-priority unfilled slot, and asks a targeted clarification question. This reduces user friction, prevents partial submissions, and ensures that the agent never hallucinates default values for required fields. The template uses square-bracket placeholders that you replace with your specific schema, field priorities, and output format before deployment.

textCopy
You are a structured data collection agent. Your job is to collect the required fields defined in [SCHEMA_DEFINITION] from the user through a series of targeted questions. You must never invent, guess, or assume values for any field.

## Current State
- Fields already collected: [COLLECTED_FIELDS_JSON]
- Fields still needed: [REMAINING_FIELDS_LIST]
- Conversation history summary: [CONVERSATION_SUMMARY]

## Behavior Rules
1. Identify the single highest-priority unfilled field from [REMAINING_FIELDS_LIST] according to the priority order in [FIELD_PRIORITY_ORDER].
2. Ask the user for exactly that field. Your response must contain:
   - A brief acknowledgment of what has been collected so far.
   - The specific question for the next field.
   - A concrete example of a valid value.
   - A one-sentence explanation of why this field is needed.
3. If the user provides a value that does not match the expected type or constraints in [SCHEMA_DEFINITION], respond with the validation error and ask again with the example.
4. If the user asks to skip a non-critical field (marked `required: false` in [SCHEMA_DEFINITION]), mark it as skipped and move to the next field.
5. If the user asks to skip a critical field (marked `required: true`), explain that the field is required and cannot be skipped, then re-ask with the reason.
6. If the user provides multiple field values in one message, accept all valid ones, update [COLLECTED_FIELDS_JSON], and ask for the next unfilled field.
7. When all required fields are collected, output a summary of all collected fields in [OUTPUT_FORMAT] and ask the user to confirm before proceeding.
8. If the user indicates they want to stop or cancel, output the partially collected fields in [OUTPUT_FORMAT] with a `status: cancelled` flag and stop asking questions.

## Constraints
- Never ask for more than one field at a time.
- Never fabricate field values.
- If the user's input is ambiguous for the current field, ask a clarifying sub-question before accepting the value.
- Respect the validation rules in [SCHEMA_DEFINITION] for each field.

Adaptation guidance: Replace [SCHEMA_DEFINITION] with your full field schema including field names, types, required flags, validation rules, and descriptions. Replace [COLLECTED_FIELDS_JSON] with the current state object from your application's session store. Replace [REMAINING_FIELDS_LIST] with the computed list of unfilled fields. Replace [FIELD_PRIORITY_ORDER] with an ordered list of field names indicating which fields to collect first. Replace [CONVERSATION_SUMMARY] with a brief summary of prior turns. Replace [OUTPUT_FORMAT] with your desired output schema, such as a JSON structure or a formatted text block. Wire the prompt into your application so that [COLLECTED_FIELDS_JSON] and [REMAINING_FIELDS_LIST] are updated after every user turn and fed back into the system prompt on the next invocation. Validate every collected value against your schema in application code before marking it as collected. If the agent produces a final summary, route it to a confirmation step or a human review queue before any downstream action is taken.

The slot-filling clarification prompt is not a standalone chat message; it is a stateful component inside a structured data collection loop. The application must maintain a session state object that tracks which slots are filled, which are missing, and which are critical versus optional. Before each call to the model, the harness assembles the prompt by injecting the current state: the list of filled slots with their values, the list of remaining required slots with their descriptions, and any optional slots the user may choose to provide. The model receives this context and returns a targeted clarification question for the next missing critical field—never a request for all fields at once. The harness then parses the model's output, validates that it asks for exactly one missing field, and presents that question to the user.

Validation and state updates are the core of the harness. After the user responds to a clarification question, the application must extract the provided value and update the session state. A strict validator should confirm that the user's response actually addresses the field that was requested—not a different field, and not a refusal to answer. If the user provides a value for a different slot, the harness should accept it and update that slot as well, but it must still re-evaluate which field is the next missing critical slot. If the user's response is empty, a refusal, or an 'I don't know,' the harness should mark that slot as explicitly declined (not missing) and move to the next required field. This prevents infinite loops where the model repeatedly asks for the same information. The harness should also enforce a maximum clarification round limit (e.g., 5 rounds) after which it terminates the collection and returns whatever partial data has been gathered, along with a warning about incomplete fields.

Early termination and escalation must be handled explicitly. The prompt template includes a [TERMINATION_CONDITIONS] placeholder where you inject rules such as: if the user says 'cancel,' 'stop,' or 'never mind,' the agent must immediately stop asking questions and return a summary of collected data. The harness should scan user responses for these termination signals before forwarding them to the model. When termination is detected, the harness bypasses the model entirely and returns the partial state with a terminated: true flag. For high-stakes data collection (e.g., healthcare intake, financial onboarding, legal forms), the harness should also log every clarification round—the question asked, the user's raw response, the extracted value, and the validator result—to an audit trail. This log enables human review if the collected data is later found to be incomplete or incorrect. Do not rely on the model to enforce termination or audit logging; these are application-layer responsibilities.

Model choice and retry logic matter for reliability. This prompt works well with instruction-following models (GPT-4, Claude 3.5, Gemini 1.5 Pro) but can drift with smaller models that may ask for multiple fields at once or hallucinate slot descriptions. Implement a structural validator that checks the model's output before showing it to the user: the output must contain exactly one question, must reference a field that is actually in the missing-slots list, and must not ask for fields already filled. If validation fails, retry once with an error message injected into the prompt context (e.g., 'Your previous response asked for multiple fields. Ask for only the next missing field.'). If the retry also fails, fall back to a template-based question generated directly from the slot schema, bypassing the model. This ensures the collection loop never stalls on a model formatting error. For production systems, consider caching the prompt prefix with the slot schema and state structure to reduce token costs across repeated calls in the same session.