Assumption-Based Stop Condition Prompt Template

This prompt is for engineering teams building autonomous agents that must operate safely with incomplete information. The core job-to-be-done is converting a set of explicit planning assumptions into executable stop rules that cause the agent to halt execution and escalate to a human operator when those assumptions are violated. The ideal user is an AI engineer or technical product manager who has already decomposed a task into steps and surfaced the assumptions each step depends on—likely using a companion prompt like the Assumption Inventory Generation or Pre-Flight Assumption Check template. You need a structured list of assumptions with IDs, categories, and confidence scores before this prompt can produce useful stop conditions.

Do not use this prompt when the agent's task is low-risk, fully reversible, or operates in a closed environment where assumption violations can be handled by a fallback retry loop. This prompt is specifically for high-stakes workflows—database migrations, financial transactions, clinical data processing, infrastructure changes—where continuing execution on a violated assumption causes damage that is expensive or impossible to unwind. If your agent already has a robust error-handling and replanning module that can safely recover from unexpected states, a hard stop condition may add unnecessary latency and operator burden. Reserve this for irreversible or high-consequence actions where the cost of a false negative (failing to stop) far outweighs the cost of a false positive (stopping unnecessarily).

Before using this prompt, ensure you have: (1) a complete assumption inventory with unique IDs, (2) current confidence scores for each assumption, (3) a defined escalation path with human reviewer availability, and (4) agreement from your operations team on acceptable stop latency. The output of this prompt should feed directly into your agent's execution loop as a guard clause checked before each irreversible step. Pair this with the Uncertainty Escalation Trigger Prompt Template if you need finer-grained control over when to escalate versus when to stop entirely. For auditability, log every stop event with the triggering assumption ID, the evidence that caused the violation, and the human decision that followed.

This template is the core instruction set for an autonomous agent that must decide when to stop execution and escalate rather than continue with degraded confidence. It forces the model to evaluate its own assumptions against current evidence before each irreversible or high-cost step. The prompt is designed to be dropped into an agent's planning or execution loop, with placeholders that your application must populate at runtime. The output is a structured stop/go decision with explicit trigger conditions, not a free-text recommendation.

textCopy
You are an execution monitor for an autonomous agent. Your job is to evaluate whether the agent should continue executing its current plan or stop and escalate based on assumption violations, confidence drops, or evidence contradictions.

## Current Plan Step
[PLAN_STEP]

## Active Assumptions
[ACTIVE_ASSUMPTIONS]

## Recent Evidence
[RECENT_EVIDENCE]

## Stop Condition Rules
[STOP_CONDITION_RULES]

## Irreversibility Assessment
[IRREVERSIBILITY_ASSESSMENT]

## Output Schema
Return a JSON object with exactly these fields:
{
  "decision": "CONTINUE" | "STOP_AND_ESCALATE",
  "triggered_conditions": [
    {
      "condition_id": "string",
      "condition_type": "ASSUMPTION_VIOLATION" | "CONFIDENCE_DROP" | "EVIDENCE_CONTRADICTION" | "IRREVERSIBILITY_THRESHOLD",
      "description": "string explaining what triggered",
      "violated_assumption_id": "string | null",
      "current_confidence": 0.0,
      "threshold_confidence": 0.0
    }
  ],
  "rationale": "string explaining the decision",
  "escalation_context": {
    "summary": "string summarizing what the human needs to know",
    "blocking_issues": ["string"],
    "recommended_questions": ["string"]
  },
  "continuation_conditions": ["string describing what would allow continuation"]
}

## Constraints
- If any assumption in [ACTIVE_ASSUMPTIONS] is contradicted by [RECENT_EVIDENCE], you MUST return STOP_AND_ESCALATE.
- If confidence for any critical assumption drops below its threshold in [STOP_CONDITION_RULES], you MUST return STOP_AND_ESCALATE.
- If [IRREVERSIBILITY_ASSESSMENT] indicates the next action cannot be undone and any assumption is below its confidence threshold, you MUST return STOP_AND_ESCALATE.
- Do not invent evidence. Only use what is provided in [RECENT_EVIDENCE].
- If no stop conditions are triggered, return CONTINUE with an empty triggered_conditions array.

To adapt this template, replace each square-bracket placeholder with data from your agent runtime. [PLAN_STEP] should contain the specific step the agent is about to execute, including its inputs and expected outputs. [ACTIVE_ASSUMPTIONS] must be a structured list of assumption objects with IDs, descriptions, and current confidence scores. [RECENT_EVIDENCE] should include the latest observations, tool outputs, or sensor readings relevant to the active assumptions. [STOP_CONDITION_RULES] defines the confidence thresholds and violation rules specific to your domain. [IRREVERSIBILITY_ASSESSMENT] should be a boolean or structured assessment of whether the next action can be rolled back. If your agent framework doesn't produce these inputs natively, you'll need to pair this prompt with the Assumption Inventory Generation and Pre-Flight Assumption Check templates to populate the placeholders reliably. For high-risk domains, always log the full prompt and response for audit, and consider requiring human confirmation before the agent acts on a CONTINUE decision when irreversibility is flagged.

The Assumption-Based Stop Condition prompt is not a standalone chat interaction; it is a runtime safety component that sits between the agent's planning module and its execution loop. The harness must invoke this prompt whenever the agent's internal state changes in a way that could invalidate prior assumptions—typically after a tool call returns, when new evidence is ingested, or when a step completes with unexpected output. The prompt expects a structured snapshot of active assumptions, recent evidence, and the current plan step, and it returns a stop/go decision with trigger rationale. The harness should treat a stop decision as a hard interrupt that prevents the next step from executing and routes control to the escalation handler.

Wire the prompt into the agent loop as a synchronous guard function called check_stop_conditions(). This function should assemble the required inputs: the assumption inventory (with IDs, statements, and current confidence scores), the most recent evidence payloads (tool outputs, retrieved documents, user clarifications), and the next planned action (including its reversibility classification). The prompt returns a structured JSON object with fields decision (enum: proceed, stop, request_clarification), triggered_rules (array of assumption IDs that violated thresholds), and rationale (a concise explanation). Validate this output against a strict schema before acting on it. If the model returns malformed JSON or an unrecognized decision, the harness should default to stop and log the failure—never default to proceed on a parse error. For high-risk domains such as healthcare or finance, route all stop decisions to a human review queue with the full assumption trace and evidence package attached.

Log every invocation of this prompt with the input snapshot, the raw model response, the parsed decision, and the harness action taken. This audit trail is essential for tuning stop-condition sensitivity and diagnosing both premature stopping (the agent halts when it should have continued) and failure-to-stop (the agent proceeds past a violated assumption). Build an eval harness that replays logged scenarios against prompt changes to detect regressions. When deploying to production, consider using a faster, cheaper model for this guard prompt if latency is critical, but validate that the smaller model does not miss stop conditions that a frontier model would catch. The stop-condition prompt is a safety boundary; its reliability must be measured and monitored like any other production safeguard.