Deadline Miss Prediction Notification Prompt

This prompt is designed for SLA-bound agent workflows where missing a deadline carries operational or contractual consequences. It compares the agent's current progress rate against the remaining steps and the time remaining until a hard deadline. The output is a structured risk assessment that includes a projected completion time, a confidence interval, and a recommended mitigation action. Use this prompt inside a plan monitoring module that fires at configurable intervals or at predefined progress checkpoints.

The ideal user is an agent runtime operator or a developer building an autonomous workflow engine. The prompt requires the following context to be useful: a clearly defined deadline timestamp, a list of completed steps with timestamps, a list of remaining steps, and the current time. Without this structured progress data, the model cannot calculate a meaningful rate or projection. The prompt is most effective when progress can be measured in discrete, countable steps—such as tool calls, data processing chunks, or document reviews—rather than continuous or subjective tasks.

Do not use this prompt when the workflow has no deadline constraint, when progress cannot be measured in discrete steps, or when the cost of a false positive alert is higher than the cost of a late completion. It is also unsuitable for workflows where the agent's pace is intentionally variable due to human-in-the-loop delays or external API rate limits that the model cannot observe. In those cases, a simple heartbeat or checkpoint notification prompt is a better fit. If the deadline is a soft target rather than a contractual obligation, consider using a lower-severity progress summary prompt instead to avoid alert fatigue.

This template is the core of the Deadline Miss Prediction Notification Prompt. It is designed to be injected into your agent's monitoring loop when a progress checkpoint is reached or a time-based trigger fires. The prompt forces the model to compare actual progress against the plan, compute a projected completion time with a confidence interval, and produce a structured risk assessment. Replace every square-bracket placeholder with live data from your agent runtime before sending the request.

textCopy
You are an execution monitor for an SLA-bound agent workflow. Your task is to analyze the current execution progress against the deadline and produce a structured risk assessment.

## WORKFLOW CONTEXT
- Original Objective: [OBJECTIVE]
- Total Planned Steps: [TOTAL_STEPS]
- Deadline (UTC): [DEADLINE_TIMESTAMP]
- Current Time (UTC): [CURRENT_TIMESTAMP]
- SLA Requirement: [SLA_DESCRIPTION]

## EXECUTION STATE
- Completed Steps: [COMPLETED_STEP_IDS]
- In-Progress Step: [CURRENT_STEP_ID]
- Remaining Steps: [REMAINING_STEP_IDS]
- Steps Completed in Last [WINDOW_DURATION]: [RECENT_COMPLETION_COUNT]
- Average Step Duration (last 5 steps): [AVG_STEP_DURATION_SECONDS] seconds
- Blocked Dependencies: [BLOCKED_DEPENDENCIES]
- Recent Errors or Retries: [ERROR_SUMMARY]

## CONSTRAINTS
- Do not assume steps will speed up without evidence.
- If any remaining step has a known variable duration, widen the confidence interval.
- If blocked dependencies exist, treat them as unresolvable within the deadline unless explicitly marked as resolvable.
- Express all times in UTC.

## OUTPUT_SCHEMA
Return a single JSON object with the following structure:
{
  "risk_level": "on_track" | "at_risk" | "likely_miss" | "critical_miss",
  "projected_completion_time_utc": "ISO-8601 timestamp or null if incalculable",
  "confidence_interval_lower_utc": "ISO-8601 timestamp",
  "confidence_interval_upper_utc": "ISO-8601 timestamp",
  "confidence_level": 0.0-1.0,
  "buffer_remaining_seconds": integer,
  "bottleneck_step_ids": ["step_id"],
  "risk_factors": ["description of each factor"],
  "mitigation_recommendations": ["actionable recommendation"],
  "should_escalate": true/false,
  "escalation_reason": "string or null"
}

Adaptation guidance: The [WINDOW_DURATION] placeholder should match your monitoring cadence (e.g., 5 minutes). The [AVG_STEP_DURATION_SECONDS] should be computed from actual runtime data, not plan estimates. If your workflow has parallel steps, add a parallel_execution_groups field to the EXECUTION STATE section. For high-stakes SLAs, wire the should_escalate boolean directly into your notification pipeline and require human acknowledgment before the agent continues. Always validate the output JSON against the schema before acting on the risk level—schema-compliant but logically inconsistent outputs (e.g., risk_level: on_track with a negative buffer_remaining_seconds) are a known failure mode that should trigger a retry or fallback.

The deadline miss prediction prompt is designed to run as a scheduled evaluation step within an agent execution loop, not as a one-off chat interaction. It should be invoked at configurable intervals (e.g., every N steps, every M minutes, or at predefined progress checkpoints) by the agent orchestrator. The prompt requires the orchestrator to inject the current plan state, progress metrics, and deadline constraints into the [PLAN_STATE], [PROGRESS_SNAPSHOT], and [DEADLINE_CONSTRAINTS] placeholders before each invocation. Because the output drives operational decisions—pausing execution, reallocating resources, or escalating to a human operator—the harness must validate the structured output before acting on it.

Integration pattern: Wire this prompt as a tool or function call within your agent runtime. The orchestrator should: (1) assemble the current execution context into the input variables, (2) call the model with the prompt template and a strict JSON output schema, (3) validate the response against the expected schema fields (risk_level, projected_completion_time, confidence_interval_lower, confidence_interval_upper, miss_probability, mitigation_recommendations), (4) log the full prediction payload to your observability stack with a timestamp and execution trace ID, and (5) route the output based on risk_level. For high risk predictions, trigger an immediate notification to the operations queue or on-call channel. For medium risk, flag the execution for review but allow it to continue. For low risk, log and continue without interruption. Model choice: Use a model with strong reasoning capabilities (GPT-4o, Claude 3.5 Sonnet, or equivalent) because the prompt requires numerical estimation, trend analysis, and calibrated uncertainty expression. Smaller or faster models may produce plausible-looking but miscalibrated probability estimates.

Validation and safety checks: Before the prediction reaches any downstream system, validate that miss_probability is a float between 0.0 and 1.0, that projected_completion_time is a valid ISO 8601 timestamp in the future, and that confidence_interval_lower is strictly less than confidence_interval_upper. Reject and retry any response that fails schema validation. Implement a stale-prediction guard: if the prediction was generated more than N minutes ago (configurable per workflow), discard it and re-invoke the prompt with fresh state. For SLA-bound workflows where a missed deadline carries financial or compliance consequences, add a human-in-the-loop gate on all high risk predictions—do not allow automated mitigation actions (like canceling downstream steps or reallocating resources) without operator approval. Log every prediction, the action taken, and any human override for auditability.

What to avoid: Do not invoke this prompt on every single step of a high-frequency agent loop; the token cost and latency will erode the very deadline margin you are trying to protect. Instead, tie invocation to progress milestones (25%, 50%, 75% completion) or time-based intervals proportional to the total deadline window. Do not treat the model's miss_probability as a calibrated statistical estimate without empirical validation—run backtests against historical execution traces to measure whether predicted probabilities align with actual miss rates, and adjust your risk thresholds accordingly. Finally, ensure the prompt's output is always paired with the execution trace that produced it; a risk prediction without the underlying progress data is impossible to debug or improve.