Staged Autonomy for Customer-Facing Chatbots Prompt

Use this prompt when your product team is designing or updating the operational boundaries for a customer-facing chatbot that must operate under staged autonomy. The prompt produces a structured capability policy that defines what the AI can do autonomously at each stage, what requires human approval, and what triggers escalation or reversion. It is designed for teams that need a single source of truth for chatbot behavior across development, staging, and production environments, especially when regulatory constraints or customer-impact risks demand documented guardrails. This prompt is ideal for AI product leads, risk managers, and engineering leads who are implementing progressive autonomy and need a clear, auditable policy before writing any application code.

The policy generated by this prompt should be treated as a living document that gates real product behavior. You should wire its output into your application's decision layer so that the chatbot's capabilities are programmatically constrained by the current stage. For example, a Stage 1 policy might allow the bot to answer FAQs autonomously but require human approval for any account changes, while Stage 3 might permit autonomous refunds up to a defined dollar amount. The prompt forces you to specify these boundaries explicitly, including the exact escalation language, the data required for a human review queue, and the reversion triggers if error rates spike. Do not use this prompt for internal-only tools with no customer exposure, for chatbots that will never progress beyond a single autonomy stage, or for systems where all actions are already hardcoded in application logic rather than governed by AI-decisioned policy.

Before using this prompt, gather your existing risk assessments, regulatory requirements, and any prior incident reports that should inform the guardrails. The prompt works best when you can provide concrete action categories (e.g., 'account updates,' 'billing disputes,' 'PII access') and clear organizational roles for approval. After generating the initial policy, validate it against a set of known edge cases—such as a customer in distress, a minor requesting data deletion, or a surge in misrouted intents—to ensure the escalation paths hold. The next step is to feed this policy into your implementation harness, where stage enforcement, logging, and human review queues will be built.

This prompt template encodes a progressive autonomy policy directly into your orchestration layer. It instructs the model to classify the user's request into a capability stage, determine whether the action requires human approval, and generate a response or escalation payload accordingly. The template is designed to be adapted to your specific product stages, risk tolerances, and tool definitions. Before pasting, you must define your stages, the actions permitted at each stage, and the exact format of the escalation payload your review queue expects.

codeCopy
SYSTEM:
You are a customer-facing AI assistant operating under a Staged Autonomy Policy. Your authority is limited by your current stage. You must classify every user request into a capability stage and act only within that stage's permissions.

## CAPABILITY STAGES
[STAGE_DEFINITIONS]

## PERMITTED ACTIONS PER STAGE
[ACTION_PERMISSIONS_MAP]

## ESCALATION RULES
- If a request requires an action above your current stage, you must not attempt it.
- Generate a structured escalation payload and stop.
- If user intent is ambiguous, request clarification before classifying the stage.
- If you detect a guardrail violation, escalate immediately regardless of stage.

## RESPONSE FORMAT
When the action is within your stage:
- Provide the direct response or tool call as permitted.
- Precede any irreversible action with a confirmation summary.

When escalation is required, output ONLY the following JSON:
{
  "decision": "escalate",
  "escalation_reason": "STAGE_EXCEEDED | AMBIGUOUS_INTENT | GUARDRAIL_VIOLATION | CONFIDENCE_LOW",
  "requested_action": "[description of what the user asked for]",
  "required_stage": "[stage name required for this action]",
  "current_stage": "[your current stage]",
  "context_summary": "[brief summary of relevant conversation context]",
  "severity": "ROUTINE | PRIORITY | CRITICAL"
}

## CONSTRAINTS
[DOMAIN_SPECIFIC_CONSTRAINTS]

## RISK LEVEL
Current risk level: [RISK_LEVEL]
If risk level is ELEVATED or CRITICAL, all non-informational actions require escalation.

USER:
[USER_INPUT]

CONTEXT:
[CONVERSATION_CONTEXT]

To adapt this template, replace each square-bracket placeholder with concrete values from your product policy. [STAGE_DEFINITIONS] should list your stages (e.g., 'Stage 1: Informational Only', 'Stage 2: Account Lookup', 'Stage 3: Account Modification') with clear boundaries. [ACTION_PERMISSIONS_MAP] must explicitly map each action your chatbot can take to the minimum stage required. [DOMAIN_SPECIFIC_CONSTRAINTS] is where you inject regulatory rules, such as 'Never expose PII in escalation payloads' or 'Payment actions always require Stage 4 and explicit confirmation.' The [RISK_LEVEL] variable should be set dynamically by your application based on the user's authentication state, action history, or a separate risk-scoring prompt. After adapting, run this prompt against a golden test set of user inputs that span every stage and escalation reason to verify the model correctly classifies the stage and respects the escalation boundaries before any production traffic reaches it.

The staged autonomy prompt is not a standalone artifact; it is a policy engine that must be integrated into the chatbot's decision loop. The prompt should be invoked whenever the system transitions between stages, evaluates a gate condition, or encounters an action that falls outside the current stage's permitted scope. In a production harness, this means the prompt sits behind a stateful orchestration layer that tracks the current autonomy stage, the history of human approvals, and the performance metrics that gate progression.

Wire the prompt into a decision service that receives the current stage, the proposed action, the user's context, and any relevant performance data. The service should call the LLM with the prompt template, parse the structured output (a JSON policy decision), and then enforce it in application code. Do not rely on the model's text output to gate actions directly. Instead, use the parsed decision to update the system's autonomy state, log the transition, and either permit, block, or escalate the action. For high-risk domains like finance or healthcare, add a mandatory human review step for any stage promotion or for actions classified above a configurable risk threshold, regardless of the model's output.

Implement retries with exponential backoff for transient model failures, but cap retries at three attempts. If the model returns an unparseable output, log the raw response and fall back to the most restrictive stage (full human approval) while alerting the on-call channel. Use a model that supports structured output (JSON mode or function calling) to reduce parsing errors. Store every transition in an append-only audit log with the prompt version, model ID, input context, raw output, parsed decision, and the human reviewer's identity if approval was required. This log is your primary evidence for governance reviews and for tuning the prompt's gate criteria over time.

Before deploying, build a suite of eval cases that cover: a clean promotion through all stages, a reversion triggered by a spike in error rate, an edge case where the user's request is ambiguous, and a high-risk action that must be escalated regardless of stage. Run these evals in CI on every prompt change. In production, monitor the rate of stage promotions, reversions, and escalations. A sudden increase in reversions or escalations often signals a prompt regression or a shift in user behavior that requires investigation. Never allow the system to skip stages or self-promote without a human-approved gate evaluation.