Sequential Context Propagation Prompt for Multi-Tool Flows

This prompt is for integration developers and agent infrastructure engineers who need to pass structured state through a chain of dependent tool calls. Instead of dumping raw tool outputs into the next call, this prompt produces a context mapping specification that defines exactly which fields from each tool output flow into subsequent tool inputs, what transformations apply, what default values to use when fields are missing, and how much of the context window each step consumes. Use this when you have three or more tools that must execute in a strict sequence because later tools depend on earlier results, and you need the mapping to be auditable, debuggable, and budget-aware.

The ideal user is building a production agent or integration pipeline where tool call ordering is non-negotiable—for example, a customer support agent that must first look up an account, then retrieve recent orders, then check inventory for those orders, and finally generate a response. Each step consumes fields from the previous step's output. Without an explicit mapping specification, the model may hallucinate field names, pass entire raw payloads that blow the context window, or silently drop required fields. This prompt forces the model to produce a machine-readable mapping that your orchestrator can validate before execution begins. Do not use this prompt when you have only one or two tools, when tools are fully independent and can run in parallel, or when your orchestrator already has a hardcoded field-mapping layer. In those cases, a simpler parallel-execution prompt or a static mapping configuration is more appropriate and cheaper to run.

The prompt also includes context window budget tracking, which is critical for long chains. Each step's mapping specification declares how many tokens of the previous output are retained and passed forward. This lets you catch budget overruns at plan time rather than mid-execution when the model loses context. The output is designed to be consumed by an execution engine that reads the mapping, extracts the specified fields, applies transformations, and injects only the required context into each subsequent tool call. Before adopting this prompt, confirm that your orchestrator can consume a structured mapping specification and enforce field-level context injection. If your system passes entire message histories between calls, this prompt will add overhead without benefit. Start with a three-tool chain where you can manually verify the mapping correctness, then expand to longer sequences once the validation loop is stable.

This prompt template is designed to be inserted into a multi-turn agent loop after a set of tool calls has been executed. Its job is to produce a precise context mapping specification: for each pending tool call in a sequence, it identifies which fields from previous tool outputs should flow into the current tool's arguments, how those values should be transformed, and what defaults apply when upstream data is missing. The output is a machine-readable specification that your orchestrator can use to construct the next tool call payload without hallucinating dependencies or dropping required context.

codeCopy
You are a context propagation planner for a multi-tool execution engine. Your task is to produce a context mapping specification that determines how outputs from previously executed tool calls flow into the inputs of the next tool call in a sequence.

# PREVIOUS TOOL OUTPUTS
[PREVIOUS_OUTPUTS]

# PENDING TOOL CALL
Tool Name: [TOOL_NAME]
Tool Description: [TOOL_DESCRIPTION]
Tool Parameter Schema:
[TOOL_SCHEMA]

# EXECUTION CONTEXT
Overall Task: [TASK_DESCRIPTION]
User Identity: [USER_CONTEXT]
Session Data: [SESSION_CONTEXT]

# CONSTRAINTS
- Context Window Budget Remaining: [TOKEN_BUDGET] tokens
- Maximum fields per mapping: [MAX_FIELDS]
- Required fields that MUST be populated: [REQUIRED_FIELDS]
- Forbidden data sources (do not reference): [FORBIDDEN_SOURCES]
- Risk Level: [RISK_LEVEL]

# OUTPUT SCHEMA
Return a JSON object with the following structure:
{
  "tool_name": "string",
  "mappings": [
    {
      "target_parameter": "string (parameter name in pending tool schema)",
      "source": {
        "tool_call_id": "string (id of previous tool call)",
        "output_path": "string (JSONPath or dot-notation to field)"
      },
      "transformation": "string (none | extract | format | map | filter | aggregate | compute)",
      "transformation_rule": "string (human-readable rule, or null if none)",
      "default_value": "any (value to use if source is missing or null)",
      "required": true/false
    }
  ],
  "unresolved_parameters": ["string (parameters with no available source)"],
  "context_window_used": "number (estimated tokens consumed by mapped values)",
  "warnings": ["string (missing data, type mismatches, budget overruns)"],
  "propagation_notes": "string (explanation of mapping decisions)"
}

# RULES
1. Only map fields that exist in [PREVIOUS_OUTPUTS]. Do not invent data.
2. If a required field has no available source, list it in unresolved_parameters and set its default_value to null.
3. For transformation "extract", specify which substring or element to pull.
4. For transformation "map", specify the value mapping table (e.g., "open" -> "active").
5. For transformation "aggregate", specify the aggregation function (sum, count, concat, merge).
6. If context_window_used exceeds [TOKEN_BUDGET], include a warning and suggest field pruning.
7. If [RISK_LEVEL] is "high", add a human_review_required flag to any mapping involving financial, PII, or state-mutating data.
8. Do not propagate fields from [FORBIDDEN_SOURCES].
9. If a source field contains a list and the target expects a scalar, specify the selection rule in transformation_rule.
10. Preserve data types. If a type mismatch exists, note it in warnings and apply a safe coercion rule.

To adapt this template, replace each square-bracket placeholder with values from your execution context. [PREVIOUS_OUTPUTS] should contain the full JSON response bodies from all completed tool calls, keyed by tool call ID. [TOOL_SCHEMA] should be the exact JSON Schema or function definition for the pending tool. The [TOKEN_BUDGET] field is critical for long sequences—track cumulative context usage across steps and reduce the budget for later calls. For high-risk workflows, set [RISK_LEVEL] to "high" and ensure your orchestrator respects the human_review_required flag before executing the next tool call. Test this prompt with at least three scenarios: a clean sequence where all dependencies resolve, a sequence with missing upstream data, and a sequence that exceeds the token budget.

This prompt is designed to be called between tool execution steps in an agent loop, not as a one-shot planner. After a tool returns its output, the agent runtime should construct a new prompt call that includes the previous tool's output, the original user goal, and the list of remaining tools. The model's job is to produce a context mapping specification—a structured JSON object that defines exactly which fields from the prior output should be injected into the next tool's input, along with any transformation rules and default values. This mapping is then applied by the application layer before the next tool is invoked. Do not pass raw tool outputs directly to the next tool; the mapping specification is the contract that prevents stale, oversized, or incorrectly shaped context from propagating through the chain.

Wiring the loop: Your agent executor should maintain a context_budget counter (in tokens or characters) and a propagation_log array. Before each tool call, invoke this prompt with [PREVIOUS_TOOL_OUTPUT], [NEXT_TOOL_SCHEMA], [CONTEXT_BUDGET_REMAINING], and [USER_GOAL]. Parse the returned JSON mapping specification and validate it against the next tool's input schema before execution. If validation fails, retry the prompt once with the validation error included in [CONSTRAINTS]. If the mapping exceeds the remaining context budget, the prompt should return a budget_exceeded flag with a prioritized subset of fields; your harness must honor this and truncate accordingly. Log every mapping decision to the propagation_log for debugging and audit. For high-stakes workflows (finance, healthcare, legal), insert a human review gate when the mapping confidence score falls below 0.85 or when the prompt flags a needs_clarification status.

Model choice and failure modes: Use a model with strong structured output support (GPT-4o, Claude 3.5 Sonnet, or equivalent) and enable JSON mode or structured outputs. The most common production failure is the model hallucinating field names that don't exist in the next tool's schema—always validate the mapping against the actual tool input schema before execution. A secondary failure mode is the model propagating too much context, blowing the context window for later steps; the context_budget_remaining parameter is your primary defense. If the prompt returns a mapping that fails schema validation after one retry, abort the chain and escalate to a human operator with the full propagation_log. Do not silently drop fields or guess transformations in the application layer—the model's mapping is the auditable decision record.