User-Specific Multi-Hop Query Planning Prompt

This prompt is for advanced RAG developers building multi-step retrieval agents where a single query cannot gather all necessary evidence. Its job is to plan a sequence of retrieval queries, constraining each step by the user's permissions and knowledge requirements. Use it when a user's question demands chained reasoning across documents, and each hop must respect what the user is authorized to see. This is not for simple fact lookup or single-hop Q&A. It assumes you already have a retrieval engine, a permission model, and a way to execute the planned queries in order.

The ideal user is an AI engineer or technical lead who has already instrumented their retrieval pipeline with user identity, role scopes, and access control lists. The prompt requires you to provide a user profile with explicit permissions, the original complex question, and a description of the available document collections. The output is a structured query plan with dependencies, where each step specifies the retrieval query, the required permission scope, and the expected intermediate evidence. You must validate that every planned query falls within the user's authorization boundary before execution; a single over-permissioned hop can leak sensitive data. Implement a hard validation layer that rejects any query step whose scope exceeds the provided user permissions, and log the rejection for audit.

Do not use this prompt for single-hop factual questions, simple keyword searches, or scenarios where a single well-scoped retrieval call can satisfy the user's intent. It is also inappropriate when the user's permissions are flat and uniform across all document collections, because the permission-aware planning adds complexity without benefit. Before adopting this prompt, ensure you have a reliable way to execute the planned queries sequentially and feed intermediate results back into the next retrieval step. If your system cannot handle stateful, multi-turn retrieval with dependency tracking, start by building that execution harness before introducing permission-aware planning.

This prompt instructs the model to act as a retrieval planner that decomposes a complex user question into a sequence of dependent retrieval steps. Each step is constrained by the user's specific permissions, ensuring that no query in the plan attempts to access data outside the user's authorized scope. The template is designed to be dropped into an agentic RAG system where a planner module must produce a structured, executable plan before any retrieval calls are made.

Below is the copy-ready prompt template. It uses square-bracket placeholders for all dynamic inputs. The [USER_QUESTION] is the original multi-part query. [USER_ACCESS_PROFILE] is a structured description of the user's permissions, roles, and data scopes (e.g., 'Can access: project Alpha, Beta; Denied: financial reports'). [AVAILABLE_RETRIEVAL_TOOLS] is a list of tool signatures the planner can use, such as vector_search(query, filters), keyword_search(query, filters), or get_document(id). [PLAN_OUTPUT_SCHEMA] defines the exact JSON structure for the plan, including fields for step_id, depends_on, query, tool, filters, and justification. [CONSTRAINTS] can include rules like 'Maximum 5 steps' or 'No speculative queries about salary data.' [EXAMPLES] should contain one or two few-shot demonstrations of a user question, access profile, and the correct query plan output.

textCopy
You are a retrieval planning agent. Your task is to decompose a complex user question into a sequence of retrieval queries that can be executed step-by-step. Each query must be strictly scoped to the user's access permissions.

**User Question:**
[USER_QUESTION]

**User Access Profile:**
[USER_ACCESS_PROFILE]

**Available Retrieval Tools:**
[AVAILABLE_RETRIEVAL_TOOLS]

**Constraints:**
[CONSTRAINTS]

**Examples of Correct Plans:**
[EXAMPLES]

Generate a multi-hop query plan that answers the user's question. For each step, specify the query, the tool to use, any required filters derived from the access profile, and which previous steps it depends on. Ensure no step requests data outside the user's authorized scope. If the question cannot be answered within the user's permissions, output a plan that explains the limitation instead of attempting unauthorized retrieval.

**Output Plan:**
[PLAN_OUTPUT_SCHEMA]

To adapt this template, start by defining your [PLAN_OUTPUT_SCHEMA] as a strict JSON schema that your execution engine can parse. The [USER_ACCESS_PROFILE] should be generated programmatically from your auth system, not typed by the user. For high-stakes deployments, add a post-generation validation step that checks every query and filter in the plan against the original access profile before execution. If a step fails this check, either reject the entire plan and log an anomaly, or route it for human review. Begin testing with simple two-hop questions and a single permission boundary before scaling to complex plans.

This prompt is not a standalone module; it is the planning step in a multi-step retrieval agent. The application must call the LLM with this prompt, parse the structured query plan, validate each step against the user's permission profile, execute the steps in dependency order, and feed intermediate results into subsequent retrieval calls. The harness is responsible for enforcing that no retrieval step exceeds the user's authorized document scopes, even if the model hallucinates a disallowed filter. Treat the model's output as a proposal, not an execution command.

Implement a validate-plan-authorize-execute loop. After receiving the JSON plan, run a deterministic validator that checks: (1) every step's scope or filter field is a subset of the user's entitlements; (2) dependency references resolve to valid step IDs; (3) the plan does not exceed a configurable max_steps limit (default 5). Reject the plan and re-prompt with the violation details if validation fails. For execution, use a retrieval function that applies the user's access control list (ACL) as a mandatory pre-filter on every call, regardless of what the plan specifies. Log the proposed plan, the validated plan, any rejections, and the final retrieved documents for auditability. For high-risk domains, insert a human approval step before executing plans that touch sensitive data partitions.

Model choice matters here. Use a model with strong instruction-following and JSON mode support (e.g., GPT-4o, Claude 3.5 Sonnet) because the output must be machine-parseable and structurally consistent. Set temperature=0 or very low to minimize plan variation. Implement a retry with backoff if the output fails JSON schema validation or if the plan validator rejects the proposal more than twice. After two rejections, fall back to a single-hop retrieval with the user's full ACL applied and log the escalation. Never execute a partially validated plan. The next step after successful execution is to pass the retrieved evidence to a synthesis prompt that answers the original question, citing sources and respecting the user's permission boundaries.