Stale Context Detection and Recovery Prompt

This prompt is a critical safety component for platform engineers building multi-agent orchestration systems. Its primary job is to act as a circuit breaker between agents, preventing a downstream agent from acting on context that has been invalidated by an upstream failure. The ideal user is an orchestration engine, a handoff middleware service, or a reliability workflow that programmatically invokes this prompt before passing state to the next agent in a dependency chain. The required context includes the original handoff payload, the upstream agent's failure reason (e.g., timeout, tool error, exception), and the expected freshness parameters (e.g., max staleness in seconds, required fields).

You should wire this prompt into the on_failure or on_timeout hook of your agent execution graph. Before the orchestrator routes work to Agent_B, it must call this prompt with the state Agent_A produced and the error Agent_A threw. The prompt's structured output—a staleness assessment, a safe_to_proceed boolean, and a context-reconstruction request—becomes the control signal. If safe_to_proceed is false, the orchestrator must not forward the context and should instead route to a fallback agent, a human review queue, or a dedicated recovery agent using the provided reconstruction request. This is not a passive logging step; it is an active gating mechanism.

Do not use this prompt as a general-purpose agent health check or a replacement for standard agent-level timeouts and retries. It is specifically designed for the handoff boundary where corrupted state can propagate. Avoid using it for real-time, latency-sensitive streaming workflows where the assessment overhead would violate a user-facing SLA. The next step after integrating this prompt is to pair it with the 'Fallback Agent Context Injection Prompt' to ensure any recovery agent receives a clean, explicitly bounded context package, not the original corrupted state.

This prompt is the core instruction set you will inject into your orchestration layer when an agent receives context from a failed or timed-out upstream agent. Its job is not to complete the original task, but to perform a safety gate check: assess whether the received state is stale, determine if it is safe to proceed with degraded information, and if so, request exactly what is needed to reconstruct a viable working context. The prompt is designed to be stateless and idempotent; it should be called immediately after a handoff failure is detected, before any downstream work begins.

textCopy
You are a Stale Context Detector and Recovery Agent. Your sole responsibility is to evaluate the context received from a failed upstream agent and decide whether it is safe for a downstream agent to proceed.

## INPUT
[UPSTREAM_AGENT_ID]: The identifier of the agent that failed.
[FAILURE_REASON]: The error code, timeout message, or exception from the upstream agent.
[RECEIVED_CONTEXT]: The full state object or message payload handed off by the failed agent.
[ORIGINAL_USER_INTENT]: The user's initial request before any agent processing began.
[DOWNSTREAM_TASK]: The specific task the next agent is expected to perform.
[STALENESS_THRESHOLD_SECONDS]: Maximum age of context before it is considered stale.

## TASK
1.  **Staleness Assessment**: Determine if the [RECEIVED_CONTEXT] is stale based on the [FAILURE_REASON] and [STALENESS_THRESHOLD_SECONDS]. Check for missing critical fields, outdated timestamps, or partial results that conflict with the [ORIGINAL_USER_INTENT].
2.  **Safe-to-Proceed Determination**: Decide if the [DOWNSTREAM_TASK] can be completed safely using only the [RECEIVED_CONTEXT]. If the context is incomplete but the missing information is non-critical for the specific downstream task, it may be safe to proceed with a degraded flag.
3.  **Context-Reconstruction Request**: If it is NOT safe to proceed, generate a structured request for the missing information. This request must be answerable by a human operator or a retry of the upstream agent.

## OUTPUT_SCHEMA
You must respond with a single JSON object conforming to this schema:
{
  "staleness_assessment": {
    "is_stale": boolean,
    "confidence": float (0.0 to 1.0),
    "reasons": [string, ...]
  },
  "safe_to_proceed": boolean,
  "degraded_mode": boolean,
  "recovery_action": "proceed" | "abort_and_escalate" | "reconstruct_context",
  "context_reconstruction_request": {
    "missing_fields": [string, ...],
    "specific_questions": [string, ...],
    "suggested_retry_payload": object | null
  },
  "handoff_summary_for_human": string
}

## CONSTRAINTS
- Never fabricate missing data to make the context appear complete.
- If [RECEIVED_CONTEXT] contains contradictory information, flag it as stale and unsafe.
- The `handoff_summary_for_human` must be a concise, jargon-free explanation of what failed and what is needed next.
- If `safe_to_proceed` is true but `degraded_mode` is also true, explicitly list which capabilities will be unavailable to the downstream agent.

To adapt this template, replace the square-bracket placeholders at runtime from your agent orchestration framework's error handler. The [RECEIVED_CONTEXT] should be the raw payload from the failed agent, not a pre-parsed summary. The [DOWNSTREAM_TASK] should be a verbatim copy of the task instruction the next agent was supposed to receive. For high-risk domains, always route the handoff_summary_for_human to an on-call channel when recovery_action is abort_and_escalate. Validate the model's output against the JSON schema before allowing any downstream agent to consume the safe_to_proceed boolean; a parse failure should be treated as an implicit abort_and_escalate.

Integrate this prompt as a pre-execution guard in your agent orchestration layer. Before a downstream agent consumes context from an upstream dependency, check the upstream agent's exit status. If the status indicates failure, timeout, or partial_completion, invoke this prompt with the stale context and the upstream agent's error metadata. Do not invoke it on every agent call—only on known failure signals. The prompt adds latency and token cost, so reserve it for paths where stale context would cause cascading errors or silent data corruption.

Parse the JSON output and branch on the safe_to_proceed field. If true, pass the assessed_context to the downstream agent and log the staleness_score and risk_factors to your agent trace store. If false, route the recovery_request to the specified recovery agent or escalate to a human operator via your incident management system. Validation checks to implement in the harness: confirm staleness_score is a float between 0.0 and 1.0; verify safe_to_proceed is a strict boolean; ensure risk_factors is a non-empty array when safe_to_proceed is false; and validate that recovery_request.target_agent matches a known agent ID in your registry. Reject malformed outputs and retry once with a stricter temperature setting before escalating.

Model choice and logging: Use a fast, instruction-following model (e.g., Claude 3.5 Haiku, GPT-4o-mini) for this guard—it's a classification and structured generation task, not a reasoning-heavy one. Log the full staleness assessment, including upstream_agent_id, failure_type, context_age_seconds, staleness_score, and the branch decision, to your agent trace store for postmortem analysis. This trace data is essential for tuning your staleness thresholds over time and identifying which upstream agents produce the most stale-context events. Avoid: using this prompt as a substitute for proper agent health checks or timeout configurations—it is a recovery mechanism, not a prevention tool.