Multi-Intent Decomposition Prompt

This prompt is for product and platform engineers who need to handle compound user requests that contain multiple distinct tasks. The job is to decompose a single complex input into an ordered list of atomic intents, each with its own confidence score, dependencies, and execution sequence. Use this when a user says something like 'Refund my last order and cancel my subscription' or 'Summarize this document, translate it to French, and email it to the legal team.' The prompt is designed to produce a machine-readable decomposition that a downstream orchestrator can use to decide between parallel execution, sequential execution, or clarification requests.

Do not use this prompt for simple single-intent classification. If your inputs are already atomic, a standard intent classifier with confidence scoring is cheaper and faster. Do not use it when the downstream system cannot handle dependency graphs or ordered execution plans. The prompt assumes you have a defined intent taxonomy or tool catalog to map sub-intents against. Without that, the decomposition will produce intents that cannot be routed. The prompt also assumes you are willing to accept a structured JSON output that requires validation before execution. If your pipeline cannot validate field types, required keys, or dependency integrity, you will get silent failures.

This prompt is most valuable when you are building a routing middleware layer that sits between user input and multiple downstream handlers, tools, or agents. It works best when paired with a validation harness that checks for missing intents, circular dependencies, hallucinated intent labels, and confidence scores below your routing threshold. Before using this prompt in production, define your evaluation criteria: decomposition completeness, intent ordering correctness, dependency accuracy, and confidence calibration against a labeled test set. If any sub-intent falls below your confidence threshold, route it to a clarification prompt or human review queue rather than executing it blindly.

This template is designed to be copied directly into your prompt management system or codebase. It instructs the model to act as a request decomposition engine, breaking down a complex, multi-part user input into discrete, executable intents. The prompt forces the model to identify dependencies between intents, assign a confidence score to each, and propose a logical execution sequence. This structured output is critical for downstream routing logic that must decide whether to process intents in parallel or sequentially.

textCopy
You are a request decomposition engine. Your task is to analyze a compound user input and break it down into an ordered list of atomic, self-contained intents.

INPUT:
[USER_INPUT]

INSTRUCTIONS:
1. Identify every distinct action or information request within the [USER_INPUT].
2. For each intent, determine if it depends on the output of any other intent.
3. Assign a confidence score (0.0 to 1.0) to each sub-intent, representing how certain you are that this is a correct and complete interpretation of the user's goal.
4. Propose an execution sequence. Intents with no dependencies can be grouped for parallel execution. Dependent intents must be ordered sequentially.

OUTPUT_SCHEMA:
{
  "decomposition": [
    {
      "intent_id": "string",
      "description": "A clear, self-contained description of the atomic intent.",
      "confidence": "float (0.0-1.0)",
      "depends_on": ["intent_id"]
    }
  ],
  "execution_plan": {
    "parallel_groups": [
      ["intent_id"]
    ],
    "sequential_steps": ["intent_id"]
  },
  "ambiguity_flags": ["string describing any unresolved ambiguity"]
}

CONSTRAINTS:
- An atomic intent must not contain conjunctions like "and" that merge multiple actions.
- If the input is a single, simple request, return a decomposition with exactly one intent.
- If the input is truly nonsensical or empty, return an empty decomposition array and a descriptive ambiguity flag.

To adapt this template, replace the [USER_INPUT] placeholder with your application's user input variable. You can hardcode additional [CONSTRAINTS] specific to your domain, such as a predefined list of allowed intent categories or a strict rule that intents must map to available API tools. For high-stakes applications, consider adding a [RISK_LEVEL] parameter that adjusts the confidence threshold required before an intent is included in the execution plan. The OUTPUT_SCHEMA is designed for direct parsing; validate the JSON structure in your application code before acting on the execution plan. A common failure mode is the model merging two distinct intents into one; use the ambiguity_flags field and post-processing validation to catch this.

The Multi-Intent Decomposition Prompt is not a standalone classifier; it is a pre-processing stage that sits between user input ingestion and downstream intent routing. In a production harness, the raw user input is first passed to this prompt, which returns a structured decomposition of atomic intents. The application layer then reads the execution_sequence and dependencies fields to decide whether to process sub-intents in parallel or sequentially. A common integration pattern is to place this prompt inside an API endpoint or queue consumer that accepts a compound user request, calls the LLM with the decomposition template, validates the output against a strict JSON schema, and then publishes each atomic intent as a separate message to an internal task queue (e.g., SQS, Kafka, or a workflow engine like Temporal). This keeps the decomposition logic decoupled from the execution logic, allowing independent scaling and failure isolation.

Validation is the most critical harness component. The model output must be validated against a schema that enforces: (1) sub_intents is a non-empty array, (2) each sub-intent has a unique id, a non-empty intent string, a confidence between 0.0 and 1.0, and an optional depends_on array of IDs that must reference other sub-intents in the same decomposition, (3) the execution_sequence is a topologically sorted list of sub-intent IDs consistent with the declared dependencies, and (4) no circular dependencies exist. A post-processing validator should reject any decomposition that fails these checks and trigger a retry with a more explicit error message injected into the prompt context. For high-stakes routing (e.g., financial operations or healthcare triage), add a human review gate when the average confidence across sub-intents falls below a configurable threshold, or when the validator rejects the output more than twice. Log every decomposition attempt—including the raw input, the model output, validation errors, and the final accepted decomposition—for audit and eval dataset construction.

Model choice matters here. This prompt requires strong instruction-following and structured output capabilities. Use a model that supports JSON mode or structured output constraints natively (e.g., GPT-4o with response_format, Claude 3.5 Sonnet with tool-use-as-structured-output, or Gemini 1.5 Pro with controlled generation). Avoid models that frequently drop fields or hallucinate dependencies. For latency-sensitive applications, consider a smaller fine-tuned model that has been trained on decomposition examples from your domain. Wire the prompt into a retry loop with exponential backoff: if validation fails, retry up to three times with the validation error message appended to the prompt as [PREVIOUS_ERROR]. If all retries fail, escalate to a human operator or route the entire compound input to a general-purpose fallback queue. Do not silently drop sub-intents or proceed with a partial decomposition unless your product requirements explicitly allow best-effort processing.