Agentic Query Plan Generation Prompt

This prompt is for agent builders who need to convert a complex, multi-faceted user objective into a dynamic, stepwise research plan. It is designed for systems where the agent has access to multiple tools—such as search, database query, code execution, or internal APIs—and must decide which tool to use, what query to send, and what evidence to expect at each step. The ideal user is an AI engineer or technical decision maker building an autonomous or semi-autonomous agent that cannot resolve a user's request in a single retrieval round. The required context includes a clear user objective, a defined set of available tools with their capabilities, and an understanding of the evidence types needed to satisfy the objective.

Use this prompt when a single retrieval round is insufficient and the agent must orchestrate a sequence of information-gathering actions. It is appropriate for multi-hop research tasks, comparative analyses requiring data from disparate sources, diagnostic workflows that must rule out causes sequentially, or any objective where the retrieval strategy must adapt based on intermediate findings. The prompt includes a built-in plan validation check that verifies each step's query is answerable by its assigned tool, and a replanning trigger that activates when initial steps return insufficient or contradictory results. This makes it suitable for production systems where the cost of a bad plan is high and the agent must self-correct.

Do not use this prompt for simple factual lookups, single-hop Q&A, or workflows where the retrieval strategy is static and known in advance. If the user's question can be answered by a single well-formed search query, a standard RAG prompt with query rewriting is more efficient and less error-prone. Avoid this prompt when the tool set is a single vector database with no functional variation between queries, as the planning overhead adds latency without improving results. Also avoid it in latency-critical applications where the planning step itself introduces unacceptable delay, unless you implement plan caching for repeated objective types. For high-risk domains such as healthcare or legal, always route the generated plan through a human reviewer before execution, and ensure each step's evidence is logged for auditability.

This prompt template is the core of the Agentic Query Plan Generation workflow. It instructs the model to act as a research planner, decomposing a complex objective into a sequence of discrete, executable steps. Each step must declare its own query, the tool it targets, and the evidence it expects to find. The prompt includes a built-in validation step and a replanning trigger, making it suitable for use inside an agent loop where retrieval results can be fed back for plan adjustment.

textCopy
You are an expert research planner. Your task is to create a dynamic, stepwise research plan to achieve a complex objective. You have access to a set of tools, each with a specific capability. Your plan must be executable by an agent that can use these tools one step at a time.

**Objective:** [OBJECTIVE]

**Available Tools:**
[TOOLS]

**Instructions:**
1.  **Decompose the Objective:** Break down the objective into a sequence of discrete, independently executable steps. Each step should gather a specific piece of evidence needed to answer the main question.
2.  **Define Each Step:** For every step, provide the following in a strict JSON format:
    *   `step_id`: A unique integer for the step, starting from 1.
    *   `description`: A brief, human-readable explanation of what this step aims to accomplish.
    *   `query`: The exact string query to be executed by the target tool.
    *   `target_tool`: The name of the tool from the available list that is best suited for this query.
    *   `expected_evidence`: A clear description of the type of information this step should return if successful.
    *   `depends_on`: A list of `step_id`s that must be completed before this step can begin. Use an empty list `[]` if there are no dependencies.
3.  **Plan Validation:** After generating the plan, add a final step (`step_id: "validation"`) that is not a query. This step must contain a `validation_check` field with a boolean question: "Does this plan, if executed successfully, gather all necessary evidence to fully answer the objective?" and a `replanning_trigger` field with a string instruction: "If any step returns insufficient or irrelevant results, identify the evidence gap and generate a new plan to fill it, starting from the last successful step."

**Output Format:**
Return your entire response as a single, valid JSON object with a key `research_plan` containing an array of step objects. Do not include any text outside the JSON.

```json
{
  "research_plan": [
    {
      "step_id": 1,
      "description": "...",
      "query": "...",
      "target_tool": "...",
      "expected_evidence": "...",
      "depends_on": []
    },
    ...
    {
      "step_id": "validation",
      "validation_check": "...",
      "replanning_trigger": "..."
    }
  ]
}

To adapt this template, replace the [OBJECTIVE] and [TOOLS] placeholders. The [TOOLS] input should be a clear description of each tool's name and function, for example: 1. search_knowledge_base(query: str) -> list[Document]: Retrieves internal documents. 2. web_search(query: str) -> list[Result]: Searches the public web. The strict JSON output contract is critical for a downstream agent harness to parse and execute the plan. The validation step is not optional; it forces the model to self-critique the plan's completeness before execution begins, and the replanning trigger provides a clear, programmatic entry point for the agent to loop back if a step fails. When implementing, ensure your parser can handle the validation step as a special object that does not contain a query field.

The Agentic Query Plan Generation Prompt is designed to be called by an orchestrator agent at the start of a complex research task. The orchestrator should pass the user's objective, a list of available tools with their descriptions and input schemas, and any known constraints into the prompt's [OBJECTIVE], [AVAILABLE_TOOLS], and [CONSTRAINTS] placeholders. The model returns a structured JSON plan containing an ordered list of steps, each specifying a tool_name, query, and expected_evidence_type. This plan becomes the execution loop's work queue. Do not treat this prompt as a one-shot answer generator; its output is a machine-readable plan, not a final response to the user.

The implementation harness must parse the JSON output into a plan object and validate it before execution begins. At minimum, validate that every tool_name in the plan exists in the [AVAILABLE_TOOLS] list, that no step depends on a step ID that does not exist, and that the plan is not empty. If validation fails, retry the prompt once with the validation error appended to the [CONSTRAINTS] field. After two failures, fall back to a simpler single-step retrieval or escalate to a human reviewer. During execution, the harness should iterate through steps in dependency order, calling each tool with the specified query and capturing the result. After each step, compare the returned evidence against the expected_evidence_type field. If the evidence is insufficient or off-target, trigger the replanning path: append the step's result and a note about the gap to the conversation context and call the prompt again to generate a revised plan for the remaining steps. Log every plan version, tool call, and replanning event for observability.

Model choice matters here. Use a model with strong instruction-following and JSON output capabilities, such as Claude 3.5 Sonnet or GPT-4o, and set response_format to json_object or use the model's structured output API with the plan schema. The plan schema should include fields for plan_id, steps (array of objects with step_id, tool_name, query, depends_on, expected_evidence_type), and a stop_condition describing when the plan is complete. Implement a maximum step limit (e.g., 10 steps) and a maximum replanning count (e.g., 2 replans) to prevent runaway loops. For high-stakes domains, insert a human approval gate after plan generation but before tool execution, showing the reviewer the proposed steps and allowing them to edit or reject the plan. Never execute tools that modify external state without explicit confirmation. The harness should also track which evidence sources were used and attach them to the final synthesized answer for downstream citation and audit.