Slot-Filling Coreference Prompt for Task-Oriented Dialogue

This prompt is for task-oriented assistant developers who need to resolve user references to previously mentioned slot values and produce an updated dialogue state. Use it when your system tracks structured slots—such as departure city, destination, date, or product SKU—and users refer back to those values with phrases like 'change that to Friday' or 'make it the earlier one.' The prompt resolves the reference, fills the correct slot, and validates type consistency to prevent cross-slot contamination. It is designed for systems where the set of slots is known in advance, the dialogue state is explicitly represented as a structured object, and the primary challenge is mapping anaphoric or elliptical user utterances back to the correct slot-value pairs.

Do not use this prompt for open-ended chat without a defined slot schema, or when the user's reference is entirely new information rather than a reference to an existing slot value. If your system does not maintain a structured dialogue state, you should first implement a state tracking mechanism before attempting coreference resolution. Similarly, if the user introduces a new entity that has never been mentioned, this prompt is not the right tool—use a slot extraction or entity recognition prompt instead. Avoid this prompt when the dialogue history is too long for the model's context window without summarization, as the resolver may hallucinate referents from truncated history. For high-stakes domains such as healthcare scheduling or financial transactions, always pair this prompt with a human-approval step before committing the resolved state to a system of record.

Before deploying this prompt, ensure you have a well-defined slot schema with type constraints, a reliable mechanism for passing the last N turns of dialogue history, and a validation layer that checks the resolved output against your schema. The prompt works best when combined with a regression test suite containing examples of cross-slot contamination, number disagreement, and temporal reference ambiguity. If your use case involves resolving references to entities in retrieved documents rather than dialogue history, use the Reference Resolution with RAG Context Prompt Template instead. For voice or ASR transcripts with disfluent references, prefer the Voice Transcript Reference Resolution Prompt, which includes robustness handling for false starts and recognition errors.

This prompt template is designed to be wired directly into your dialogue management pipeline. Its job is to take the latest user utterance, the current dialogue state, and your application's slot schema, then return a precise, validated update. The model is instructed to resolve any anaphoric or implicit references (e.g., 'change it to Tuesday') against the dialogue history before writing to the correct slot. This prevents the most common production failure mode in slot-filling: updating the wrong field or corrupting the state with an unresolved value.

textCopy
SYSTEM:
You are a state-updating module for a task-oriented dialogue system. Your only job is to resolve references in the latest user utterance and update the dialogue state.

You will receive:
1. A SLOT SCHEMA defining valid slots, their types, and constraints.
2. The CURRENT DIALOGUE STATE with previously filled slots.
3. The LAST ASSISTANT UTTERANCE for context.
4. The LATEST USER UTTERANCE to process.

Your task:
1. Identify if the user's utterance contains a reference to a slot value (explicitly or via anaphora/ellipsis).
2. Resolve the reference using the dialogue history. If the reference is ambiguous, do not guess; set the value to null and set a clarification flag.
3. Determine which single slot in the SLOT SCHEMA should be updated.
4. Validate that the resolved value matches the slot's type and constraints.
5. Output a strict JSON patch object. Do not output any other slot values.

--- SLOT SCHEMA ---
[SLOT_SCHEMA]

--- CURRENT DIALOGUE STATE ---
[CURRENT_STATE]

--- LAST ASSISTANT UTTERANCE ---
[ASSISTANT_UTTERANCE]

--- LATEST USER UTTERANCE ---
[USER_UTTERANCE]

--- OUTPUT INSTRUCTIONS ---
Return a single JSON object with these exact keys:
{
  "slot_to_update": "string (the exact slot name from the schema)",
  "resolved_value": "<value> | null",
  "requires_clarification": boolean,
  "clarification_question": "string | null",
  "reference_resolution_notes": "string (brief explanation of how the reference was resolved)"
}

Do not wrap the JSON in markdown. Do not include any text outside the JSON object.

To adapt this template, replace the square-bracket placeholders with your application's live data. [SLOT_SCHEMA] should be a JSON object defining your slots, their types (e.g., date, string, enum), and any constraints (e.g., "date": "future_only"). [CURRENT_STATE] is the current key-value map of filled slots. [ASSISTANT_UTTERANCE] and [USER_UTTERANCE] are the raw strings from the last two turns. The output contract is intentionally narrow: a single slot update. This prevents the model from hallucinating changes to other fields. If you need to update multiple slots from a single utterance, you should either chain multiple calls to this prompt or use a more complex agentic loop, but be aware that multi-slot updates significantly increase the risk of state corruption.

Before deploying, you must build a thin validation layer around this prompt's output. First, confirm that slot_to_update is a valid key in your [SLOT_SCHEMA]. Second, validate that resolved_value conforms to the type and constraints defined for that slot. If validation fails, do not merge the patch into your dialogue state. Instead, log the failure and either retry with a more explicit error message or escalate to a human agent. For high-stakes domains like healthcare scheduling or financial transactions, always set a requires_clarification threshold and route any ambiguous resolution to a human review queue before state mutation occurs.

This prompt is designed to sit inside a stateful dialogue manager, not as a standalone call. The typical integration point is after each user turn, before the downstream NLU or action dispatcher runs. The application should maintain a structured dialogue state object (slots with types, values, and last-updated timestamps) and pass it alongside the current user utterance and the last N turns of conversation history. The prompt returns a patch object—only the slots that need updating—which the application merges into the existing state. This design keeps the prompt focused and avoids re-transmitting the full state on every call, which reduces token cost and prevents the model from accidentally overwriting slots it should not touch.

Validation is the critical gate here. Before merging the model's output, run a strict schema check: every returned slot key must exist in the predefined slot schema, every value must match the declared type (string, date, enum, integer, boolean), and no slot should receive a value that contradicts a previously confirmed value unless the user explicitly corrected it. Implement a cross-slot contamination check that flags cases where the model places a value into the wrong slot—for example, putting a date into a currency slot or a person's name into a location slot. If validation fails, do not merge the patch. Instead, log the failure with the raw model output and the validation error, then retry with the same prompt but append the validation error message as a [CONSTRAINT] block. Limit retries to two attempts. If both fail, escalate to a human reviewer with the original utterance, the dialogue state, and both failed outputs. For high-stakes domains like healthcare or finance, consider requiring human approval on any slot update where the model's confidence is below a threshold or where the slot value changes a previously confirmed field.

Model choice matters for this task. Use a model with strong instruction-following and structured output capabilities—GPT-4o, Claude 3.5 Sonnet, or Gemini 2.0 Flash are good starting points. Avoid smaller or older models that struggle with multi-entity tracking across turns. Set temperature low (0.0–0.2) to reduce variance in slot assignment. If your application has strict latency requirements, consider caching the system prompt prefix and using a model router that sends simple, single-slot updates to a faster model and complex multi-entity resolutions to a more capable model. Log every resolution attempt with the input utterance, the prior state, the model's raw output, the validation result, and whether it was merged or escalated. This audit trail is essential for debugging coreference failures and for demonstrating compliance in regulated deployments. The most common production failure mode is the model silently resolving a pronoun to the wrong entity of the same type—your eval suite should include test cases with multiple entities sharing a type (e.g., two dates, two locations) to catch this before it reaches users.