Goal Abandonment Decision Prompt

This prompt is the final gate in an agent's execution lifecycle. It is designed for a single, high-stakes job: forcing a structured, auditable decision when an agent has exhausted every configured recovery path, retry strategy, and fallback for a given objective and still cannot complete it. The ideal user is an AI/ML engineer or technical operator building a supervised autonomy system—such as a coding agent, a multi-step data pipeline, or a customer support automation—where silent failure or infinite loops are unacceptable. The required context is a complete execution trace, the original objective, a list of exhausted recovery attempts, and any partial artifacts generated so far. Without this context, the prompt cannot produce a reliable abandonment recommendation.

Use this prompt when the agent's runtime has already tried and failed to self-correct. This means the system has already executed retry recovery prompts, tool call error handling, and dynamic replanning steps. The trigger is not a single failed API call or a malformed JSON output; it is the moment when the agent's orchestrator determines that all programmed resilience strategies have returned unsuccessful results for the same objective. At this point, the prompt evaluates three concrete paths: formally abandon the goal with a structured rationale, produce a partial deliverable from successfully completed sub-tasks, or escalate for human re-scoping with a clear explanation of what is blocked and why. The output must be machine-readable to trigger downstream workflows, such as moving a ticket to a human queue or archiving a project state.

Do not use this prompt for transient errors, steps that can be retried, or situations where a simple replanning prompt would suffice. If the agent can still attempt a different tool, re-prompt the user for clarification, or wait for an external condition, it has not yet reached the abandonment decision point. Premature use of this prompt will lead to unnecessary escalations and abandoned work that could have been recovered. The key operational check before invoking this prompt is: 'Have all configured recovery paths been attempted and logged for this specific objective?' If the answer is no, route the failure back to the appropriate recovery handler. If the answer is yes, this prompt is the correct next step to ensure a clean, auditable termination of the effort.

The following prompt template is designed to be pasted directly into your agent's decision module. It forces structured reasoning about goal abandonment by requiring the model to evaluate recovery history, remaining options, artifact preservation, and stakeholder impact before making a recommendation. Replace every square-bracket placeholder with runtime state before sending this to the model. The template assumes you have already exhausted configured retry paths and are now at a terminal decision point.

textCopy
You are an agent decision module responsible for evaluating whether to abandon a goal that cannot be completed after exhausting all recovery paths.

# OBJECTIVE
Determine whether the current goal should be formally abandoned, partially delivered, or escalated for re-scoping. Produce a structured recommendation with rationale and artifact preservation instructions.

# CURRENT STATE
- Goal ID: [GOAL_ID]
- Original Objective: [ORIGINAL_OBJECTIVE]
- Success Criteria: [SUCCESS_CRITERIA]
- Current Step: [CURRENT_STEP_ID]
- Total Steps Planned: [TOTAL_STEPS]
- Steps Completed: [COMPLETED_STEP_IDS]
- Steps Failed: [FAILED_STEP_IDS]
- Recovery Attempts Made: [RECOVERY_ATTEMPT_COUNT]
- Recovery Strategies Tried: [RECOVERY_STRATEGIES_LIST]
- Last Error Message: [LAST_ERROR_MESSAGE]
- Elapsed Execution Time: [ELAPSED_TIME]
- Token Budget Consumed: [TOKEN_BUDGET_CONSUMED]
- Remaining Token Budget: [REMAINING_TOKEN_BUDGET]

# AVAILABLE ARTIFACTS
[ARTIFACTS_INVENTORY]

# CONSTRAINTS
- Deadline: [DEADLINE_TIMESTAMP]
- Maximum Recovery Attempts: [MAX_RECOVERY_ATTEMPTS]
- Risk Level: [RISK_LEVEL]
- Authorization Required for Abandonment: [AUTHORIZATION_REQUIRED]
- Stakeholders to Notify: [STAKEHOLDER_LIST]

# OUTPUT SCHEMA
Return a valid JSON object with exactly this structure:
{
  "decision": "ABANDON" | "PARTIAL_DELIVER" | "ESCALATE_FOR_RESCOPE",
  "confidence": 0.0-1.0,
  "rationale": "string explaining the decision with reference to recovery history and remaining options",
  "partial_artifacts_preserved": ["list of artifact IDs to save"],
  "abandonment_reason_category": "UNRECOVERABLE_ERROR" | "BUDGET_EXHAUSTED" | "DEADLINE_EXCEEDED" | "DEPENDENCY_FAILURE" | "OBJECTIVE_INVALIDATED" | "OTHER",
  "stakeholder_summary": "one-paragraph summary suitable for operator or stakeholder notification",
  "recommended_follow_up": "string describing next action: archive, notify, escalate, or re-scope",
  "lessons_logged": ["list of failure patterns or observations for post-mortem"]
}

# DECISION RULES
1. Recommend ABANDON only when all recovery paths are exhausted AND no partial deliverable has value.
2. Recommend PARTIAL_DELIVER when completed steps produced usable artifacts even if the full goal is unreachable.
3. Recommend ESCALATE_FOR_RESCOPE when the original objective may still be achievable with modified constraints, additional resources, or human intervention.
4. Never recommend retry. This decision point assumes retries are already exhausted.
5. If authorization is required for abandonment, flag this in the recommended_follow_up field.

# EVALUATION CRITERIA
- Was the failure caused by an unrecoverable external dependency?
- Do completed steps have standalone value?
- Would additional budget or time meaningfully change the outcome?
- Has the original objective been invalidated by new information?
- What is the cost of continued execution versus abandonment?

Adapt this template by adjusting the decision rules to match your organization's abandonment policies. If your agent framework uses different recovery exhaustion signals, replace the recovery-related placeholders with your own state representation. The output schema is deliberately flat to simplify parsing in downstream orchestration code. Add fields if your workflow requires additional metadata such as compliance flags, cost center codes, or audit trail references.

Before deploying this prompt, validate that your runtime state injection correctly populates all placeholders. Missing state causes the model to hallucinate recovery history or skip critical constraints. Test with at least three scenarios: a clear abandonment case, a partial delivery case, and an escalation case. For high-risk domains, route the model's output through a human review step before executing the abandonment action.

The Goal Abandonment Decision Prompt is not a standalone chat interaction—it is a decision node inside an agent execution loop. It should be invoked only after the agent's recovery and replanning paths have been exhausted. The typical call site is inside an error-handling or fallback strategy module that tracks retry counts, replanning attempts, and tool call failure histories. Before calling this prompt, the harness must assemble a structured context object containing: the original goal specification, a summary of all attempted recovery steps, the current plan state, any partial artifacts produced, and the configured abandonment policy (e.g., maximum retries, cost thresholds, or time budgets). This context becomes the [EXECUTION_TRACE] and [ABANDONMENT_POLICY] inputs to the prompt template.

The harness should enforce a strict invocation gate. Do not call the abandonment prompt on the first failure, or even the first replanning cycle. A counter or state machine should track how many distinct recovery paths have been attempted. For example, if the agent has tried three different tool-based approaches, two replanning iterations, and one human clarification request without progress, the harness increments an exhaustion_counter. Only when exhaustion_counter >= ABANDONMENT_THRESHOLD (a configurable integer, typically 3-5) does the harness invoke this prompt. This prevents premature abandonment and ensures the prompt receives a rich failure history rather than a single error message. Log the counter value, the trigger event, and a hash of the execution trace before calling the model for auditability.

The model's output must pass a structural validator before any downstream action is taken. The expected output schema includes: decision (enum: abandon, partial_deliver, escalate), rationale (string), partial_artifacts (array of artifact IDs and descriptions), preservation_instructions (object with storage paths or handoff notes), and confidence (float 0-1). If the validator rejects the output—due to a missing decision field, an unrecognized enum value, or a partial_deliver decision with an empty partial_artifacts array—retry the prompt once with the validation error appended to the [CONSTRAINTS] input. If the retry also fails validation, default to escalate and log the double-failure for operator review. Never execute an abandonment action without a validated decision object.

For high-stakes workflows—such as financial transactions, clinical documentation, or legal filings—the harness must route escalate and partial_deliver decisions to a human review queue. Even abandon decisions should be logged with the full prompt context and model output for post-hoc audit. The review queue integration should include: the original goal, the exhaustion counter value, the abandonment prompt output, and a one-click option for the reviewer to approve, reject, or modify the decision. If the reviewer rejects the abandonment, the harness should re-invoke the planning module with the reviewer's notes as additional constraints, not simply retry the same failed execution path.

Model choice matters here. This prompt requires strong instruction-following and structured output reliability, not creative reasoning. Use a model with proven JSON mode or structured output support (e.g., GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro with response schema). Set temperature=0 or a very low value (0.1 maximum) to reduce variance in the abandonment decision. If using a model without native structured output, append a strict JSON-only instruction to the [OUTPUT_SCHEMA] block and run a post-generation JSON parser with schema validation. Avoid using this prompt with small or instruction-weak models that are prone to hallucinating recovery paths instead of honestly assessing exhaustion.

Finally, treat the abandonment prompt output as a durable decision record, not a transient event. Write the validated decision, rationale, and artifact preservation instructions to an append-only execution log or audit table. This log becomes the source of truth for post-mortem analysis, cost attribution, and workflow improvement. If the agent later resumes from a checkpoint, the harness should check this log before re-attempting any previously abandoned goal—nothing wastes more tokens than an agent that abandons and then silently restarts the same objective.