Sequential Chaining Prompt with Intermediate Results

This prompt is for integration developers and agent infrastructure engineers who need to produce a sequenced execution plan where tool calls depend on each other's outputs. Use it when you have a set of tools with known input-output contracts and need the model to generate a valid execution order with explicit field-level data mapping between steps. The core job-to-be-done is translating a high-level objective and a tool registry into a machine-readable execution graph that your orchestration engine can directly consume. This prompt does not execute the tools; it produces the plan that your orchestration engine will execute. It assumes you already know which tools are needed and are now solving for ordering and data flow.

Apply this prompt when you are building multi-step pipelines where the output of Tool A is a required input for Tool B, and you need the model to reason about field compatibility, type coercion, and missing intermediate values. It is particularly useful when your tool set includes operations like search_customer(query) -> customer_id, get_orders(customer_id) -> [order_ids], and get_order_details(order_id) -> details, where the data flow is linear but the field mapping must be explicit. Do not use this prompt for simple single-tool selection tasks, for deciding whether to call a tool at all, or for parallel-only execution plans with no dependencies. Those scenarios are better served by the tool selection and parallel orchestration prompts in this pillar. This prompt also assumes your tools are idempotent or that you have external guardrails for side-effect isolation; it does not generate rollback logic or transactional boundaries.

Before using this prompt, you must have a complete tool manifest with declared input schemas, output schemas, and semantic descriptions. The prompt will fail silently or produce hallucinated field mappings if the tool contracts are ambiguous. Always validate the generated plan against your actual tool schemas before execution. For high-risk workflows involving state mutations, financial transactions, or clinical data, insert a human approval gate between plan generation and plan execution. The next section provides the copy-ready prompt template you can adapt with your own tools and constraints.

This prompt template is designed for integration developers who need a model to generate a reliable, multi-step execution plan where each step consumes the output of a previous one. Instead of merely listing tool calls, the model is forced to define the data flow: which specific fields from one tool's response are required as arguments for the next. This reduces the primary failure mode in sequential chaining—passing incompatible or missing data between steps—by making the mapping explicit and reviewable before any code executes.

textCopy
You are an execution planner for a multi-step tool pipeline. Your task is to produce a strictly sequenced plan where each tool call after the first depends on the output of a preceding call.

## TASK DESCRIPTION
[TASK_DESCRIPTION]

## AVAILABLE TOOLS
[TOOLS]

## CONSTRAINTS
- You must produce a JSON execution plan.
- Each step must declare its dependencies explicitly.
- For every dependent step, specify a field-level mapping: which output field from a prior step is used as which input argument.
- If a required input cannot be sourced from any prior output, flag it as [MISSING_DEPENDENCY] and do not fabricate a value.
- If the task can be partially satisfied with available tools, produce a partial plan and flag the unsatisfied parts.
- Do not call tools in parallel unless you can prove they share no data dependencies.

## OUTPUT SCHEMA
{
  "plan": [
    {
      "step_id": "string",
      "tool_name": "string",
      "arguments": {},
      "depends_on": [
        {
          "step_id": "string",
          "mapping": {
            "target_argument": "source_output_field"
          }
        }
      ],
      "expected_output_schema": {}
    }
  ],
  "unresolved_dependencies": [
    {
      "step_id": "string",
      "missing_argument": "string"
    }
  ]
}

## EXAMPLES
[EXAMPLES]

## RISK LEVEL
[RISK_LEVEL]

To adapt this template, replace the square-bracket placeholders with your specific context. [TASK_DESCRIPTION] should contain the user's high-level goal. [TOOLS] must be a complete JSON schema array defining each function's name, description, and parameters. The [EXAMPLES] placeholder is critical for teaching the model the expected mapping granularity; include at least one few-shot example showing a correct field-level mapping and one showing a correctly flagged missing dependency. Set [RISK_LEVEL] to high if the pipeline includes state-changing writes, which should trigger a human review step before execution. After pasting, validate that the model's output strictly conforms to the OUTPUT_SCHEMA using a JSON schema validator before feeding the plan into your execution engine.

Before integrating this prompt into your application, build a lightweight validation harness that checks for common structural failures: missing depends_on arrays for non-initial steps, circular dependencies, and arguments that reference non-existent output fields from prior steps. For high-risk pipelines, insert a confirmation gate that renders the generated plan for a human operator to approve before any tool is invoked. When a plan contains unresolved_dependencies, route it to a clarification prompt that asks the user for the missing information rather than executing a partial plan with guessed values.

The sequential chaining prompt produces a structured execution plan, not a final answer. Your application must parse this plan, execute each tool call in the specified order, feed intermediate outputs into subsequent inputs, and handle failures at any step. Treat the prompt output as a machine-readable directive, not a suggestion. The plan includes explicit data mappings between steps—your harness must enforce those mappings by extracting the declared fields from each tool response and injecting them into the next call's arguments. If a step produces an unexpected shape, stop the chain rather than guessing.

Implement a stateful execution loop that reads the model's JSON plan and maintains a context accumulator. For each step, validate that all required input fields from prior steps are present and correctly typed before calling the tool. Use a schema validator (such as Pydantic or Zod) to check each intermediate output against the expected fields declared in the plan's data mapping. If validation fails, log the mismatch, capture the raw output, and either retry with a repair prompt or escalate to a human reviewer. For high-risk workflows—financial transactions, clinical data, legal filings—insert a confirmation gate between steps where a human must approve the accumulated state before the next tool call executes. Log every step's input, output, latency, and validation result to an observability backend for debugging and audit.

Choose a model with strong structured output support and reliable tool-call argument generation. GPT-4o, Claude 3.5 Sonnet, and Gemini 1.5 Pro are suitable defaults. Set temperature=0 or near-zero to maximize plan determinism. Implement a retry budget per step: if a tool call fails due to a transient error, retry up to three times with exponential backoff. If a step fails due to a validation error, feed the error message and raw output into a repair prompt that attempts to fix the malformed result before retrying. If the repair fails or the step exhausts its retry budget, abort the chain, preserve partial progress, and route to a human-in-the-loop queue. Never silently skip a failed step or fabricate missing intermediate data—the chain's integrity depends on every output being real and verified.