Plan Deviation Detection Prompt

This prompt is designed for an execution monitoring harness that compares a recorded agent trace against a predefined reference plan. Its primary job is to detect structural and behavioral deviations—such as skipped steps, reordered actions, unplanned additions, or altered output targets—and produce a structured, machine-readable report. The ideal user is an AI engineer or platform operator building a supervised autonomy system where an orchestrator needs to programmatically decide whether to pause, replan, or escalate based on plan fidelity. You should use this prompt when you already have a complete or in-progress execution trace and a canonical plan artifact, and you need a deterministic classification of divergence before taking corrective action.

This prompt is not a replanning, retry, or correction mechanism. It does not modify the agent's behavior or fix the plan; it strictly performs differential analysis. Deploy it as a post-step or post-completion validation gate within a larger control loop. For example, after an agent completes a subtask, pipe the step description, expected output schema, and actual tool call log into this prompt to get a severity rating (CRITICAL, MAJOR, MINOR, NONE) and a boolean plan_sync_required flag. In high-risk domains like healthcare or finance, the output of this prompt should never directly trigger an automated rollback. Instead, route CRITICAL deviations to a human review queue and use the structured report as the handoff artifact. Ensure your harness validates the output against a strict JSON schema before acting on the plan_sync_required recommendation.

Do not use this prompt when you lack a formal, machine-readable plan to compare against. If the agent's plan is implicit, generated on the fly without structured recording, or stored only in conversational history, the deviation detection will be unreliable and produce false positives. Similarly, avoid using this prompt for real-time intervention on latency-sensitive paths; the comparison logic is thorough and may add unacceptable overhead for sub-second decision loops. Before wiring this into production, run a batch of evaluation cases with known deviations (skipped steps, injected actions, reordered sequences) to calibrate your severity thresholds and confirm that the output schema matches your downstream handler's expectations.

The prompt below is designed to be injected into your agent monitoring harness at runtime. It expects the original execution plan and the actual execution trace as structured inputs, and it returns a deviation report with severity ratings and a plan-sync recommendation. Use square-bracket placeholders for all dynamic values; your application layer should replace these before sending the request to the model.

textCopy
You are an execution monitor for an autonomous agent system. Your job is to compare the agent's actual behavior against its original execution plan and detect deviations.

## INPUTS

### Original Plan
[ORIGINAL_PLAN]

### Actual Execution Trace
[EXECUTION_TRACE]

## TASK

Analyze the execution trace against the original plan and identify all deviations. For each deviation, classify it into one of these categories:
- SKIPPED_STEP: A planned step was never executed.
- REORDERED_STEP: Steps were executed in a different order than planned.
- ADDED_STEP: The agent performed an action not present in the original plan.
- MODIFIED_OUTPUT: A step produced output that differs from the expected target.
- TIMING_DEVIATION: A step exceeded its expected duration or started late.
- DEPENDENCY_VIOLATION: A step was executed before its prerequisites were satisfied.

For each deviation, provide:
- deviation_id: A unique identifier for this deviation.
- category: One of the categories above.
- planned_step_id: The ID of the affected step from the original plan, or null if not applicable.
- actual_action: What the agent actually did.
- expected_action: What the plan specified.
- evidence: A direct quote or reference from the execution trace that supports this finding.
- severity: One of LOW, MEDIUM, HIGH, CRITICAL based on the impact on overall goal completion.
- downstream_impact: Which subsequent steps or outputs are affected by this deviation.

After listing all deviations, produce a plan-sync recommendation from these options:
- CONTINUE: Deviations are minor; the plan remains valid.
- REVISE_PLAN: The plan needs updating but execution can continue.
- REPLAN_FROM_CURRENT: Significant deviations require regenerating the plan from the current state.
- ABORT_AND_ESCALATE: The deviations make the original goal unreachable; escalate to a human operator.

## OUTPUT SCHEMA

Return a JSON object with this structure:
{
  "analysis_id": string,
  "timestamp": string (ISO 8601),
  "total_deviations": integer,
  "deviations": [
    {
      "deviation_id": string,
      "category": "SKIPPED_STEP" | "REORDERED_STEP" | "ADDED_STEP" | "MODIFIED_OUTPUT" | "TIMING_DEVIATION" | "DEPENDENCY_VIOLATION",
      "planned_step_id": string | null,
      "actual_action": string,
      "expected_action": string,
      "evidence": string,
      "severity": "LOW" | "MEDIUM" | "HIGH" | "CRITICAL",
      "downstream_impact": string
    }
  ],
  "plan_sync_recommendation": "CONTINUE" | "REVISE_PLAN" | "REPLAN_FROM_CURRENT" | "ABORT_AND_ESCALATE",
  "recommendation_rationale": string,
  "unresolved_risks": [string]
}

## CONSTRAINTS

- Only report deviations you can support with evidence from the execution trace.
- If no deviations are found, return an empty deviations array and a CONTINUE recommendation.
- Do not invent deviations to fill the report.
- If the execution trace is incomplete or ambiguous, note this in unresolved_risks.
- Assign CRITICAL severity only when the deviation makes the original goal unreachable.
- If the plan is [RISK_LEVEL] HIGH or CRITICAL, flag any deviation of MEDIUM severity or above for human review.

This template separates the monitoring logic from the application harness. The [ORIGINAL_PLAN] and [EXECUTION_TRACE] placeholders should be populated with structured JSON or formatted text that includes step IDs, expected outputs, and timestamps. The [RISK_LEVEL] placeholder allows you to adjust the escalation threshold dynamically based on the workflow's risk profile. Before deploying, validate that your plan and trace schemas include the fields this prompt references—missing step IDs or timestamps will produce unreliable deviation reports.

After integrating this prompt, wire the output through a JSON schema validator before acting on the recommendation. For HIGH or CRITICAL severity deviations, route the report to a human review queue rather than allowing automated replanning. Log every deviation report alongside the plan version and trace ID so you can audit detection accuracy over time and tune severity thresholds.

The Plan Deviation Detection Prompt is not a standalone chat interaction—it is a monitoring component that sits inside an agent execution loop or a sidecar observer process. The harness should invoke this prompt after every significant agent action or at configurable checkpoints (every N steps, after tool calls that modify state, or when a step's output diverges from expected schema). The prompt expects two structured inputs: the original plan (a list of steps with IDs, descriptions, expected outputs, and dependencies) and the execution trace (a chronological log of actions taken, tool calls made, outputs produced, and any errors encountered). The harness is responsible for assembling these inputs from the agent's plan store and trace buffer before each invocation.

Wire the prompt into a post-action hook that fires after the agent's execution step completes but before the next step is authorized. The hook should: (1) extract the current plan snapshot and the latest trace segment since the last deviation check, (2) populate the [ORIGINAL_PLAN] and [EXECUTION_TRACE] placeholders with structured JSON, (3) call the model with a strict JSON output schema that includes deviations (array of deviation objects with step_id, deviation_type, severity, evidence, and plan_sync_recommendation), (4) validate the response against that schema, and (5) route the result. If severity is critical or high, pause the agent and queue the deviation for human review or an automated replanning module. If severity is medium, log the deviation and continue with a warning flag. If low or none, continue execution without interruption. Use a model with strong structured-output support (GPT-4o, Claude 3.5 Sonnet, or equivalent) and set temperature=0 to minimize variance in severity classification.

Build validation and retry logic around the model's output. After receiving the deviation report, validate that every step_id in the deviations array exists in the original plan and that deviation_type is one of the allowed enum values: skipped_step, reordered_execution, unplanned_action, output_target_changed, dependency_violation, or scope_creep. If validation fails, retry once with the validation error message appended to the prompt as a [CONSTRAINTS] note. If the retry also fails, escalate to a human operator with the raw trace and plan attached. Log every deviation check—including the plan version, trace segment, model response, and routing decision—to an audit store so that downstream post-mortem and plan-archiving workflows can reconstruct what the monitor saw and why it acted.

For production deployments, consider running the deviation detector as an asynchronous sidecar rather than blocking the main agent loop on every check. The sidecar consumes a stream of plan-and-trace snapshots, runs detection, and publishes deviation events to a decision channel that the agent runtime subscribes to. This decouples detection latency from agent step latency and allows batching multiple checks when the agent is moving quickly. Set a watchdog timer: if the deviation detector has not produced a result within a configured window (e.g., 30 seconds), assume a monitoring failure and either pause the agent or fall back to a lightweight heuristic check that flags any step with a missing expected output. The heuristic check is not a replacement for the prompt but a safety net that prevents silent monitoring gaps.