Missing Dependency Detection Prompt for Agent Tasks

This prompt is for agent builders orchestrating multi-step tool sequences where one step's output is a required input for a subsequent step. The job-to-be-done is preventing silent, cascading failures that occur when an agent attempts to execute a tool call with a null, undefined, or malformed reference to a previous step's result. The ideal user is an AI reliability engineer or platform developer who is wiring together a directed acyclic graph (DAG) of tool calls—such as search_document → summarize_document → send_summary—and needs a programmatic gate that inspects the runtime state before the next node executes. You need the upstream task definitions, their expected output schemas, and the current execution state available as context for this prompt to work.

Do not use this prompt when the dependency chain is purely sequential and linear with no branching or conditional logic; a simple null check in application code is cheaper and more reliable. Do not use it for real-time, latency-sensitive loops where an extra model round-trip is unacceptable. This prompt is also the wrong tool for validating the semantic quality of upstream outputs—it checks for structural presence and type validity, not whether the summary was good. If you need to verify that a prior step produced a correct result, pair this with a separate evaluation prompt or a structured output validator. The prompt is designed to be used as a pre-execution hook, called right before the agent invokes a tool, not as a post-hoc debugging aid.

After integrating this prompt, your next step is to wire its structured output into your agent's control loop. The prompt returns a blocking boolean and a list of missing_dependencies. Your executor should check blocking before proceeding; if true, log the gap report and either halt the workflow, trigger a retry of the upstream task, or escalate to a human review queue with the full dependency-gap context. Avoid the temptation to let the model 'guess' the missing value—this prompt's entire purpose is to enforce a hard stop. For high-stakes workflows where a missed dependency could cause a financial transaction, a data deletion, or a customer-facing message, always route the gap report to a human reviewer rather than attempting an automatic repair.

The following prompt template is designed to be inserted before a critical agent step that depends on outputs from one or more upstream tasks. It forces the model to act as a gate: it inspects the provided upstream outputs, compares them against a declared dependency specification, and either clears the step for execution or produces a structured blocking report. The template uses square-bracket placeholders so you can adapt it to your specific task graph, tool contracts, and risk tolerance without rewriting the core logic.

textCopy
You are a dependency verification gate for an agent workflow. Your job is to inspect the outputs of upstream tasks and determine whether the current step has all required inputs to proceed safely.

## UPSTREAM TASK OUTPUTS
[UPSTREAM_OUTPUTS]

## DEPENDENCY SPECIFICATION
For each dependency, the specification defines:
- `source_task`: which upstream task should produce the value
- `required_field`: the exact field or key that must be present
- `expected_type`: the expected data type (string, number, boolean, array, object)
- `validation_rule`: a rule the value must satisfy (e.g., non-empty, > 0, valid URL, matches pattern)
- `blocking`: true if absence or invalidity must halt execution; false if it is a warning only

[DEPENDENCY_SPECIFICATION]

## CURRENT STEP CONTEXT
- Step name: [CURRENT_STEP_NAME]
- Step description: [CURRENT_STEP_DESCRIPTION]
- Risk level: [RISK_LEVEL]  // one of: low, medium, high, critical

## INSTRUCTIONS
1. For each dependency in the specification, locate the corresponding output in UPSTREAM_TASK_OUTPUTS.
2. Check whether the required field exists, is non-null, and satisfies the expected_type and validation_rule.
3. If a dependency is missing or invalid and `blocking` is true, mark it as a BLOCKING gap.
4. If a dependency is missing or invalid and `blocking` is false, mark it as a WARNING gap.
5. If all blocking dependencies are satisfied, respond with PROCEED and include a summary of warnings (if any).
6. If any blocking dependency is unsatisfied, respond with HALT and include a structured dependency-gap report.

## OUTPUT SCHEMA
Respond with a single JSON object matching this schema:
{
  "decision": "PROCEED" | "HALT",
  "dependency_gaps": [
    {
      "source_task": "string",
      "required_field": "string",
      "expected_type": "string",
      "validation_rule": "string",
      "actual_value": "string | null",
      "failure_reason": "MISSING" | "NULL" | "TYPE_MISMATCH" | "VALIDATION_FAILED",
      "severity": "BLOCKING" | "WARNING",
      "recommended_action": "string"
    }
  ],
  "summary": "string",
  "warnings": ["string"]
}

## CONSTRAINTS
- Do not fabricate missing values or guess at upstream outputs.
- If an upstream output is ambiguous or partially present, treat the dependency as unsatisfied and explain why.
- For RISK_LEVEL critical, treat all warnings as blocking unless explicitly overridden in the dependency specification.
- Never proceed if you cannot confidently verify a blocking dependency.

To adapt this template, replace the square-bracket placeholders with your actual data. [UPSTREAM_OUTPUTS] should contain the serialized outputs from prior tasks—typically JSON objects keyed by task name. [DEPENDENCY_SPECIFICATION] is the contract that defines what each step needs; generate this from your task graph or keep it as a version-controlled configuration file. [CURRENT_STEP_NAME] and [CURRENT_STEP_DESCRIPTION] provide context that helps the model write better recommended_action strings in the gap report. [RISK_LEVEL] adjusts the gating behavior: at critical, the model treats every unsatisfied dependency as a hard block. Before deploying, run this prompt against a golden set of known-good and known-bad upstream outputs to verify that the model correctly distinguishes PROCEED from HALT and that the gap report fields are populated accurately.

This prompt is designed to sit between an upstream task and a downstream task in an agent execution graph. It should be invoked before the downstream task attempts to consume any upstream output. The orchestration layer must supply the prompt with the upstream task's actual output, the downstream task's declared input schema, and the execution plan context. The prompt is stateless—it does not remember prior invocations—so the harness must inject all required context on each call.

Wire the prompt into your agent framework as a precondition check function. After each upstream task completes, serialize its output into the [UPSTREAM_OUTPUT] placeholder and pass the downstream task's required input schema into [REQUIRED_INPUT_SCHEMA]. The [EXECUTION_PLAN_CONTEXT] placeholder should include the task name, step number, and a one-line description of what the downstream task intends to do. On the response side, parse the structured JSON output and inspect the blocking field. If blocking is true, halt the agent's execution graph and route the dependency_gap_report to the configured escalation path—typically a human review queue, a structured retry with backfill logic, or a task re-planning step. If blocking is false, allow execution to proceed but log the warnings array for observability.

For production reliability, implement a validation layer on the prompt's output before acting on it. Confirm that the JSON parses correctly, that every entry in missing_dependencies includes a non-empty field_name, expected_source, and gap_description, and that the blocking boolean is present. If validation fails, retry the prompt once with the same inputs and a stronger instruction to produce valid JSON. If the retry also fails, escalate to a human operator with the raw model output and the validation error. Choose a model with strong JSON-mode support (GPT-4o, Claude 3.5 Sonnet, or equivalent) and set temperature=0 to minimize variance in dependency classification. Log every invocation—inputs, outputs, validation results, and escalation decisions—so that false-positive halts can be audited and the prompt's dependency detection rules can be tuned over time. Avoid using this prompt for real-time user-facing flows where latency budgets are under 500ms; the dependency check adds a full model round-trip and should be reserved for asynchronous agent pipelines where correctness outweighs speed.