Task Uniqueness Scoring Prompt for Agent Orchestrators

This prompt is designed for orchestration engineers building priority queues and task routers in multi-agent systems. Its job is to score an incoming task against a registry of active workstreams to determine semantic uniqueness. The output is a calibrated confidence score that drives routing decisions: assign the task to an existing workstream if it is a duplicate, or create a new workstream if it is unique. Use this prompt when your system needs to prevent duplicate agent work, reduce wasted compute, and avoid reconciliation debt caused by multiple agents unknowingly tackling the same problem.

This prompt assumes you already have a structured registry of active workstreams with canonical fingerprints and that you can supply both the incoming task and the active workstream context at inference time. The registry should include workstream IDs, intent descriptions, entity references, and constraint summaries. Without this structured context, the model cannot perform a meaningful comparison. The prompt works best when workstreams have clear, non-overlapping boundaries and when incoming tasks are well-formed enough to extract a semantic fingerprint. If your workstreams are poorly scoped or your tasks are ambiguous fragments, the confidence scores will be unreliable and should not be used for automated routing.

Do not use this prompt as a general-purpose similarity scorer, a content deduplication engine for documents, or a replacement for deterministic idempotency keys on side-effect-producing operations. It is not designed for real-time sub-millisecond routing decisions where latency budgets are tight; model inference adds non-trivial overhead. For high-throughput systems, consider using this prompt to calibrate a faster embedding-based classifier rather than calling it on every task. Always pair the confidence score with a threshold that triggers human review for borderline cases, especially when routing errors could cause missed deadlines, double-processing of financial transactions, or conflicting state mutations.

This prompt is the core instruction you will paste into your orchestration layer. It is designed to be stateless: it receives a snapshot of the active workstream and a candidate task, then returns a structured uniqueness assessment. All dynamic values are represented as square-bracket placeholders that your application must replace at runtime. The prompt enforces a strict JSON output contract so that downstream routing logic can parse the result without ambiguity.

codeCopy
You are a task deduplication scorer for an agent orchestration system. Your job is to compare a candidate task against a list of active tasks and determine whether the candidate is semantically unique or a duplicate of existing work.

## INPUT
[CANDIDATE_TASK]
[ACTIVE_TASKS]

## TASK DEFINITION
- CANDIDATE_TASK: A single task object with fields `id`, `description`, `intent`, `entities`, and `constraints`.
- ACTIVE_TASKS: A JSON array of task objects currently in progress, each with the same schema as CANDIDATE_TASK.

## SCORING RULES
1. Compare the candidate task's `intent`, `entities`, and `constraints` against each active task.
2. A task is a duplicate if it would produce substantially the same outcome, even if the wording differs.
3. Consider partial overlap: if the candidate task is a subset of an active task, flag it as a duplicate.
4. If the candidate task is broader than an active task but fully contains it, flag it as a superset (still a duplicate for routing purposes).
5. Ignore differences in phrasing, synonyms, or surface-level formatting.
6. If no active tasks are semantically equivalent, the task is unique.

## OUTPUT SCHEMA
Return ONLY a valid JSON object with this exact structure:
{
  "uniqueness_score": <float between 0.0 and 1.0, where 1.0 is completely unique and 0.0 is an exact duplicate>,
  "is_duplicate": <boolean>,
  "matched_task_id": <string or null>,
  "overlap_type": <"exact" | "subset" | "superset" | "partial" | "none">,
  "rationale": <string explaining the decision in one sentence>
}

## CONSTRAINTS
- Do not return any text outside the JSON object.
- If no active tasks exist, return uniqueness_score 1.0, is_duplicate false, matched_task_id null, overlap_type "none".
- If multiple active tasks match, select the one with the highest semantic overlap.
- The rationale must reference specific intent, entity, or constraint overlap.

To adapt this template, replace [CANDIDATE_TASK] with a serialized task object and [ACTIVE_TASKS] with a JSON array of in-flight tasks from your workstream registry. If your task schema differs, update the field names in the SCORING RULES section to match your domain model. For high-throughput systems, consider pre-filtering [ACTIVE_TASKS] to only include tasks from the same tenant, session, or time window before passing them into the prompt. Always validate the output JSON against the schema before routing—if the model returns malformed JSON, retry once with a stricter format reminder, then escalate to a human reviewer if the retry also fails.

This prompt is designed to be called synchronously by an orchestrator or task router before a new task is assigned to an agent. The orchestrator should maintain an in-memory or database-backed registry of active workstreams, each represented by a structured fingerprint containing intent, entities, and constraints. When a new task arrives, the orchestrator constructs the prompt by populating the [INCOMING_TASK] and [ACTIVE_WORKSTREAMS] placeholders. The [ACTIVE_WORKSTREAMS] list should be filtered to include only workstreams that are semantically close enough to be potential duplicates—passing every active workstream for a large fleet will blow out the context window and increase latency. A lightweight pre-filter using embedding cosine similarity or keyword overlap against the task fingerprint is recommended before invoking the LLM.

The model response must be parsed as JSON and validated against a strict schema: a uniqueness_score (float, 0.0–1.0), a confidence field (float, 0.0–1.0), a most_similar_workstream_id (string or null), and a rationale (string). If the JSON parse fails or required fields are missing, the orchestrator should retry once with a repair prompt that includes the raw output and the expected schema. If the retry also fails, the task should be routed to a human review queue with the raw output attached. Do not silently default to "unique" or "duplicate" on parse failure—this creates a risk of either duplicate execution or dropped tasks.

For routing decisions, implement a two-threshold system. If uniqueness_score is above 0.8 and confidence is above 0.7, the task is considered novel and can be dispatched to an available agent. If uniqueness_score is below 0.3 and confidence is above 0.7, the task is a likely duplicate and should be blocked or merged with the existing workstream. Scores between 0.3 and 0.8, or any score with confidence below 0.7, should trigger a human-in-the-loop review. Log every scoring result—including the prompt, response, thresholds applied, and routing decision—to enable calibration against human-labeled duplicates over time. This log becomes your eval dataset for tuning thresholds and detecting drift in the model's scoring behavior.

Model choice matters here. Use a model with strong semantic comparison capabilities and reliable JSON output (e.g., GPT-4o, Claude 3.5 Sonnet). Avoid smaller or older models that may produce inconsistent scores or hallucinate workstream IDs. Set temperature=0 to maximize score stability across repeated calls. If your orchestrator processes high task volumes, consider batching multiple incoming tasks into a single prompt to amortize latency, but keep the batch size small (3–5 tasks) to avoid degrading comparison quality. Finally, implement a TTL on workstream fingerprints in the active registry—stale workstreams that haven't been updated in a configurable window should be evicted to prevent false duplicate matches against completed or abandoned tasks.