Pronoun Resolution Prompt Template

This prompt is designed for a single, high-leverage task: transforming a user's follow-up question that contains an ambiguous pronoun into a self-contained, fully resolved utterance. The core job-to-be-done is to substitute a pronoun like 'it', 'they', or 'its' with the correct antecedent from the dialogue history. For example, if a user previously asked about 'order #12345' and follows up with 'What is its status?', this prompt should output 'What is the status of order #12345?'. The ideal user is a chat assistant builder or AI engineer who needs to sanitize user turns before they reach downstream systems like NLU classifiers, RAG retrieval pipelines, or tool-calling functions that require explicit entity mentions to operate correctly. This is a pre-processing step that makes multi-turn conversation possible without forcing users to repeat entity names in every message.

To use this prompt effectively, you must provide the full dialogue history as [CONTEXT] and the current user turn as [INPUT]. The prompt is optimized for short-to-medium conversation histories, typically under 10 turns, where the antecedent is a named entity, a product, a ticket ID, or a similarly concrete referent from the immediately preceding turns. It works best when the dialogue is between a single user and an assistant, and the pronoun has a clear, unambiguous antecedent in the text. The output should be a single string: the resolved utterance. You can wire this into your application as a lightweight pre-call transformation, running it before any retrieval, classification, or tool-selection step. For production systems, you should validate the output by checking that the resolved entity actually appears in the dialogue history and that the pronoun's gender and number agree with the substituted antecedent.

Do not use this prompt for long-document coreference resolution, where the antecedent might be paragraphs or pages away and requires a dedicated coreference model. It is also not suitable for cross-session entity linking, where a user refers to an entity from a conversation that happened days ago and is stored in a CRM or knowledge base. For that, you need a retrieval-augmented entity linker, not a pronoun resolver. Additionally, avoid using this prompt to resolve references to visual elements in a UI, such as 'click the red button', where the antecedent is a pixel region, not a text span. If the dialogue history contains multiple plausible antecedents for a pronoun, this prompt may resolve incorrectly or with low confidence. In such cases, you should pair it with a clarification question generator or an unresolved reference flagging system to avoid guessing in high-stakes domains like healthcare or finance. The next step after understanding this use case is to copy the prompt template, adapt the placeholders to your dialogue format, and run it against a golden test set of ambiguous turns to measure resolution accuracy before integrating it into your pipeline.

This template is designed to be dropped directly into your application's prompt assembly pipeline. It instructs the model to analyze the current user utterance against a provided dialogue history, identify any ambiguous pronouns, and return a fully resolved utterance. The core logic forces the model to ground its resolution in the provided history and to signal when resolution is impossible, preventing silent failures in production.

textCopy
You are a precise reference resolution engine. Your task is to resolve ambiguous pronouns in the [CURRENT_UTTERANCE] by identifying their correct antecedents from the [DIALOGUE_HISTORY].

### CONSTRAINTS
- [CONSTRAINTS]

### DIALOGUE HISTORY
[DIALOGUE_HISTORY]

### CURRENT UTTERANCE
[CURRENT_UTTERANCE]

### RESOLUTION RULES
1. Identify all personal pronouns (he, she, they, it), possessive pronouns (his, her, their, its), and demonstrative pronouns (this, that, these, those) in the [CURRENT_UTTERANCE].
2. For each pronoun, find the most recent, grammatically compatible entity in the [DIALOGUE_HISTORY]. Prioritize entities that match in number (singular/plural) and, where known, gender.
3. If a pronoun cannot be confidently resolved to a single entity in the history, do not guess. Flag it as 'UNRESOLVED'.
4. Replace each pronoun in the [CURRENT_UTTERANCE] with its resolved entity name in square brackets, e.g., '[the red Honda Civic]'. Keep the rest of the utterance unchanged.

### OUTPUT FORMAT
Return a valid JSON object with the following keys:
{
  "resolved_utterance": "The final utterance with pronouns replaced by bracketed antecedents.",
  "unresolved_references": ["list of pronouns that could not be resolved"],
  "resolution_map": [{"pronoun": "it", "antecedent": "the red Honda Civic", "turn_index": 2}]
}

To adapt this template, replace the placeholders with your application's data. [DIALOGUE_HISTORY] should be a serialized list of prior turns, ideally with speaker labels and turn indices. [CURRENT_UTTERANCE] is the raw user input. Use [CONSTRAINTS] to inject domain-specific rules, such as 'Only resolve references to product SKUs' or 'Prioritize entities mentioned in the last 3 turns.' The resolution_map in the output is critical for logging and debugging; it creates an auditable link between the model's decision and the evidence in the history. Before deploying, test this prompt with a golden dataset that includes cases of gender mismatch, entity-type confusion, and unresolvable references to ensure the model respects the 'do not guess' rule.

The pronoun resolution prompt is not a standalone component. It sits inside a larger dialogue pipeline, typically between the turn intake layer and the downstream NLU or agent. The prompt receives the current user utterance and a structured representation of the prior dialogue turns, then returns a resolved utterance with pronouns replaced by their correct antecedents. This resolved output becomes the input to intent classification, entity extraction, tool calls, or response generation. Treating resolution as a discrete, testable step prevents downstream components from silently operating on ambiguous input.

Wire the prompt into your application with a pre-processing stage that assembles the dialogue history into a compact format. Pass only the last N turns (typically 3-5) plus any entity map your system already maintains. Avoid dumping raw JSON blobs into the prompt; instead, format history as numbered speaker-tagged lines: User: I need the Q3 report. Assistant: Here it is. User: Can you email it to finance?. The prompt's [DIALOGUE_HISTORY] placeholder should receive this formatted string. For the [CURRENT_UTTERANCE] placeholder, pass the raw user input exactly as received. If your system already tracks entities with unique IDs, include an [ENTITY_MAP] section mapping entity names to their canonical identifiers, which helps the model disambiguate when multiple entities share a type.

After the model returns a resolved utterance, run validation checks before passing it downstream. First, verify that every pronoun in the original utterance has been replaced or explicitly flagged as unresolvable. Second, check that the resolved referent matches the gender, number, and entity type of the antecedent in your dialogue state. For example, if the user said 'send it to her' and your state shows the antecedent for 'it' is a document and 'her' is a contact named Sarah, the resolved output must reflect those types. A lightweight validator can compare the model's output against your state store and flag mismatches for human review or a retry loop. In high-stakes domains such as healthcare or finance, require human approval when the model's confidence score falls below a threshold or when the validator detects a type mismatch.

For retry logic, implement a two-stage approach. If the validator rejects the output, construct a retry prompt that includes the original input, the rejected output, and the specific validation error (e.g., 'Resolved referent for "it" does not match the entity type in state: expected Document, got Contact'). This gives the model targeted feedback to correct its mistake. Limit retries to two attempts; if both fail, escalate to a clarification question directed at the user rather than guessing. Log every resolution attempt, including the original utterance, the dialogue history snapshot, the model's output, the validator result, and any retry attempts. These logs are essential for debugging resolution failures and for building a golden dataset to improve the prompt over time.

Choose your model and latency budget based on the criticality of the downstream task. For real-time chat, a smaller, faster model (such as Claude Haiku or GPT-4o-mini) is usually sufficient for pronoun resolution, as the task is well-scoped and does not require deep reasoning. Reserve larger models for cases where the validator has flagged a complex or ambiguous reference. If your system uses Retrieval-Augmented Generation, be aware that pronouns may refer to entities in retrieved documents rather than dialogue history. In that case, extend the prompt's [CONTEXT] placeholder to include relevant retrieved chunks, and add an [OUTPUT_SCHEMA] field that requires the model to cite whether the antecedent came from dialogue history or a retrieved document. This prevents silent misattribution when a user says 'what about the deadline it mentions' and 'it' refers to a contract clause in a retrieved PDF rather than anything previously discussed.

Finally, avoid wiring this prompt directly into a state-mutating path without safeguards. The resolved utterance should update your dialogue state only after validation passes. If your system maintains a structured belief state (slots, intents, entity grid), apply the resolved references as a patch to that state and run a consistency check before committing. A common failure mode is allowing an incorrectly resolved pronoun to overwrite a correct entity in state, which then cascades into every subsequent turn. By treating the resolution step as a read-only transformation with a validated write gate, you prevent a single bad resolution from corrupting the entire session.