Timeout Recovery Prompt for Long-Running Agent Steps

This prompt is for agent runtime developers and platform engineers who need a deterministic, programmatic decision when a long-running agent step exceeds its latency budget. The job-to-be-done is not to generate a user-facing apology or a generic error message. It is to produce a structured recovery action—accept partial results, retry with a reduced scope, or escalate—based on the concrete output and state that existed at the moment of timeout. The ideal user is integrating this prompt into an orchestrator's error-handling loop, where the model's response is parsed by a state machine, not read by an end user.

Use this prompt when a step has a hard deadline and you need to decide what to do with the incomplete work. This is common in multi-turn tool use, code execution sandboxes, browser agents, and long-running data processing pipelines. The prompt requires the original goal, the partial output captured before the timeout, the step's dependency graph, and the remaining global token or time budget as inputs. Do not use this prompt for simple API calls that can be retried idempotently with exponential backoff; those are better handled by a standard retry library. Do not use it when the step has no observable partial output, as the model will have no evidence to ground its decision and may hallucinate a recovery plan.

The primary risk is that the model will overestimate the usefulness of partial results and recommend proceeding with dangerously incomplete data. To mitigate this, always pair this prompt with a postcondition validation step that checks the accepted partial output against a schema or a set of required fields before it flows to downstream steps. For high-risk domains such as financial transactions or healthcare data processing, the escalation path should route to a human operator with the full partial output and the model's recovery recommendation attached as a non-binding suggestion. The next section provides the copy-ready prompt template you can adapt and wire into your agent harness.

This template is designed to be inserted into your agent's error-handling middleware. When a step times out, the agent runtime should capture the step's objective, the partial output (if any), the elapsed time, and the remaining plan context. This prompt then forces a structured decision: accept the partial work, retry with a reduced scope, or escalate to a human or a parent orchestrator. The goal is to prevent the agent from silently hanging or burning tokens on a task that will never complete within its constraints.

textCopy
You are a timeout recovery controller for an autonomous agent. A step has exceeded its maximum allowed execution time. Your job is to analyze the available evidence and output a strict JSON decision. Do not continue the original task. Do not fabricate missing results.

[PLAN_CONTEXT]

[STEP_OBJECTIVE]

[PARTIAL_OUTPUT]

[ELAPSED_TIME_MS]

[TIMEOUT_BUDGET_MS]

[RETRY_COUNT]

[MAX_RETRIES]

[DOWNSTREAM_DEPENDENCIES]

[TOOLS_AVAILABLE]

[CONSTRAINTS]

Analyze the situation and output a single JSON object with the following schema:

{
  "decision": "accept_partial" | "retry_reduced_scope" | "escalate",
  "confidence": 0.0-1.0,
  "rationale": "string explaining the decision with reference to specific evidence",
  "reduced_scope": {
    "new_objective": "string (only if decision is retry_reduced_scope)",
    "new_timeout_ms": number (only if decision is retry_reduced_scope)
  },
  "partial_result_summary": "string describing what was completed before timeout (only if decision is accept_partial)",
  "escalation_reason": "string (only if decision is escalate)",
  "downstream_impact": ["list of affected downstream steps"],
  "missing_information": ["list of what we still don't know"]
}

Rules:
- If [PARTIAL_OUTPUT] is empty or contains only an error, you cannot accept_partial.
- If [RETRY_COUNT] >= [MAX_RETRIES], you cannot retry_reduced_scope.
- If [DOWNSTREAM_DEPENDENCIES] includes critical path steps, escalate if confidence is below 0.7.
- A reduced scope retry must request less work than the original [STEP_OBJECTIVE].
- Never invent data to fill gaps in [PARTIAL_OUTPUT].

To adapt this template, replace each square-bracket placeholder with data from your agent runtime. [PLAN_CONTEXT] should include the overall goal and completed steps. [PARTIAL_OUTPUT] is whatever the model or tool returned before the timeout fired—this could be a truncated JSON object, a partial text stream, or an empty string. The [DOWNSTREAM_DEPENDENCIES] field is critical: if the timed-out step is a prerequisite for a high-risk action, the prompt is instructed to escalate rather than silently degrade. Before deploying, test this prompt against three scenarios: a step that produced 80% of the expected output, a step that produced nothing, and a step that timed out on its final retry. Validate that the JSON output strictly conforms to the schema and that the decision rules are followed. For high-stakes workflows, route escalate decisions to a human review queue with the full trace attached.

The timeout recovery prompt is not a standalone utility—it is a decision node inside an agent execution loop. Wire it into your agent runtime so that when a step exceeds its latency budget, the runtime captures the partial output, elapsed time, and remaining plan context, then invokes this prompt to decide the next action. The prompt expects structured inputs: the original step objective, the partial result (if any), the timeout threshold, the elapsed duration, the remaining token budget, and the downstream steps that depend on this step's output. Without these inputs, the model cannot reliably distinguish between a step that produced useful partial work and one that produced nothing salvageable.

Build a validation layer around the prompt's output before acting on it. The prompt returns a structured decision—accept_partial, retry_reduced_scope, or escalate—along with a rationale and, for retry decisions, a modified step specification with reduced constraints. Validate that the decision is one of the three allowed values, that a retry decision includes a concrete scope reduction (not just 'try again'), and that an escalate decision includes a specific reason a human or orchestrator can act on. If validation fails, default to escalation with the raw partial output attached. Log every timeout event with the prompt's input, output, validation result, and final action taken—these logs become your tuning dataset for adjusting timeout thresholds and scope-reduction strategies over time.

For production reliability, implement a circuit breaker around the recovery prompt itself. If the model call for recovery decision-making times out or returns malformed output, do not loop. Fall back to a hardcoded policy: accept partial results if they pass a minimum completeness check (e.g., at least one required field populated), otherwise escalate. Test this harness by simulating timeouts at different completion percentages—25%, 50%, 90%—and verifying that the system correctly distinguishes between salvageable partial work and unrecoverable failures. The most common production failure mode is accepting partial results that look structurally valid but are semantically empty; add a post-decision check that partial outputs contain substantive content, not just placeholder text or empty arrays.