Safe Operating Limit Handoff Prompt

This prompt is for AI reliability engineers and platform teams building autonomous agents that must recognize their own safe operating limits. Use it when an agent encounters a situation it is not authorized, confident, or capable of handling and must escalate to a human operator with complete context. The prompt instructs the model to classify the boundary type, produce a confidence score, cite evidence for the limit being reached, and recommend next steps for the human. This is not a general error handler or a conversational fallback. It is a deliberate stop-and-handoff mechanism for high-stakes agent workflows where continuing autonomously would create unacceptable risk.

Deploy this prompt within an agent's execution loop as a pre-action gate or as an exception handler that triggers when a primary workflow fails a confidence check, a permission check, or a policy evaluation. The prompt requires several inputs to function correctly: the agent's current task and goal, the specific action or decision that triggered the limit, the relevant policy or capability constraint, and recent execution context. The output is a structured handoff payload containing a boundary classification (e.g., authorization_limit, confidence_threshold, capability_gap), a confidence score, cited evidence, and operator recommendations. This output should be validated against a defined schema before being routed to a human review queue. Do not use this prompt for low-stakes informational queries, simple retry logic, or situations where a clarification question to the user would resolve the ambiguity without human intervention.

Avoid using this prompt as a generic 'I don't know' fallback. Its value is in structured, auditable escalation for high-risk agent workflows. Before implementing, ensure you have defined the agent's safe operating envelope, including authorization boundaries, confidence thresholds, and capability limits. Without these definitions, the model will have no criteria against which to evaluate its limits. Wire the validated output into your human review queue system, and log every escalation for audit and pattern analysis. If your agent frequently triggers this handoff, investigate whether the operating envelope is too restrictive or whether the agent is being assigned tasks outside its design scope.

This prompt template is designed to be injected into an agent's system instructions or invoked as a tool call when the agent detects it has reached a safe operating limit. Its primary job is to prevent the agent from guessing, looping, or taking unauthorized action. Instead, it forces the agent to produce a structured handoff object containing the boundary classification, confidence scores, evidence of the limit reached, and recommended next steps for the human operator. The template uses square-bracket placeholders for all dynamic inputs, making it ready to paste into your orchestration layer.

markdownCopy
# SYSTEM PROMPT: Safe Operating Limit Handoff

You are an AI agent operating within a defined set of safety and capability boundaries. Your primary directive is to complete the assigned task within these boundaries. You must continuously monitor your own state, tool outputs, and confidence levels.

## Handoff Trigger
If you detect that you have reached a safe operating limit, you MUST immediately stop all autonomous execution and invoke the `handoff_to_human` tool. Do not attempt to guess, retry indefinitely, or take any action beyond generating the handoff payload.

A safe operating limit is reached when any of the following conditions are met:
- **[BOUNDARY_RULES]**: Specific, enumerated rules that define the edge of the agent's authority (e.g., 'Cannot approve transactions over $[AMOUNT]', 'Cannot modify production database schemas', 'Cannot answer questions about [TOPIC]').
- **Confidence Drop**: Your internal confidence in the correctness of the next step falls below [CONFIDENCE_THRESHOLD]%.
- **Tool Failure Loop**: A required tool has failed [RETRY_COUNT] times with the error pattern [ERROR_PATTERN].
- **Ambiguous Intent**: After [CLARIFICATION_ATTEMPTS] attempts, the user's intent for a high-risk action remains unclear.
- **Guardrail Violation**: The next required step would violate the safety policy: [SAFETY_POLICY_REFERENCE].

## Handoff Payload Generation
When invoking `handoff_to_human`, you must generate a JSON payload that strictly conforms to the following schema. Do not include any text outside the JSON object.

```json
{
  "handoff_type": "safe_operating_limit_reached",
  "boundary_classification": {
    "limit_type": "[LIMIT_TYPE]", // e.g., 'authorization', 'confidence', 'tool_failure', 'ambiguous_intent', 'guardrail_violation'
    "rule_reference": "[BOUNDARY_RULE_ID]",
    "severity": "[SEVERITY]" // 'critical', 'high', 'medium'
  },
  "evidence": {
    "triggering_input": "[USER_INPUT_OR_TOOL_OUTPUT_THAT_TRIGGERED_THE_LIMIT]",
    "agent_state": "[SUMMARY_OF_CURRENT_TASK_AND_PROGRESS]",
    "tool_call_history": [
      // Array of the last [N] tool calls with their inputs and outputs
    ],
    "confidence_score": [CONFIDENCE_SCORE] // A number between 0 and 1
  },
  "handoff_context": {
    "summary_for_operator": "[A_CONCISE_NATURAL_LANGUAGE_SUMMARY_OF_THE_SITUATION]",
    "unresolved_state": "[WHAT_WAS_LEFT_INCOMPLETE]",
    "recommended_next_steps": [
      "[ACTION_1_FOR_HUMAN]",
      "[ACTION_2_FOR_HUMAN]"
    ],
    "rollback_or_mitigation": "[IF_APPLICABLE_STEPS_TO_REVERT_ANY_PARTIAL_CHANGES]"
  },
  "audit_trail": {
    "decision_log": "[RATIONALE_FOR_STOPPING]",
    "model_version": "[MODEL_ID]",
    "prompt_version": "[PROMPT_VERSION]"
  }
}

Final Instruction

Your only output must be the invocation of the handoff_to_human tool with the fully populated JSON payload. Do not add any conversational text, apologies, or explanations outside the tool call.

To adapt this template, replace the square-bracket placeholders with your specific operational rules and thresholds. The [BOUNDARY_RULES] section is the most critical; it should contain a precise, machine-readable list of conditions that define the agent's authority. In a production system, the handoff_to_human tool call should be routed to a human review queue, not just logged. Before deploying, validate that the JSON output conforms to the schema using a strict validator in your application layer. A common failure mode is the model adding conversational text outside the tool call; your harness should be prepared to strip or reject non-JSON output. For high-risk domains like finance or healthcare, this handoff must be treated as a blocking control—the system should not proceed until a human operator acknowledges and resolves the payload.

This prompt is not a standalone chat interaction; it is a control-plane component inside an agent or automation workflow. It should be invoked when the system detects a boundary condition—such as a guardrail violation, a confidence drop below a configured threshold, or an unrecognized edge case—and needs to produce a structured handoff payload for a human operator or an upstream review queue. The prompt's job is to classify the boundary, package the evidence, and recommend next steps, not to decide whether to continue.

Wire the prompt into your application as a synchronous call within an escalation handler. When the agent's runtime detects a limit condition, construct the prompt with the full [CONVERSATION_HISTORY], the [CURRENT_STATE] (including tool call logs and pending actions), and the [LIMIT_TRIGGER] that caused the escalation. The model should return a JSON object matching the [OUTPUT_SCHEMA] with fields for boundary_classification, confidence_score, evidence_of_limit_reached, and recommended_operator_actions. Validate this output immediately: check that boundary_classification matches your internal taxonomy of limit types, that confidence_score is a float between 0 and 1, and that evidence_of_limit_reached contains at least one specific, citation-backed reason. If validation fails, retry once with the validation errors appended to the prompt as [PREVIOUS_OUTPUT_ERRORS]. If the retry also fails, fall back to a templated handoff with raw context and flag the failure for post-mortem analysis.

Model choice matters here. Use a model with strong instruction-following and JSON mode support (e.g., GPT-4o, Claude 3.5 Sonnet) because the output must be machine-readable and schema-conformant. Set temperature to 0 or near-zero to maximize determinism. Log every handoff invocation—including the prompt version, model version, input context hash, and output payload—to your observability stack. This is critical for auditing why the system stopped and for detecting patterns of over-escalation (false positives) or missed escalations (false negatives). For high-risk domains like healthcare or finance, route the handoff payload to a human review queue with an SLA attached, and never allow the agent to resume autonomously after this prompt fires without explicit human re-authorization.