Human Override Request Prompt with Agent Rationale

This prompt is designed for a specific high-stakes moment in a multi-agent or human-in-the-loop system: a human reviewer has determined that an agent's autonomous decision or recommendation must be reversed or modified. The job-to-be-done is not merely to log a correction, but to create a structured, auditable record that captures the agent's original decision, its full reasoning chain, and the precise override being applied. The ideal user is a subject-matter expert, compliance officer, or operations lead operating within a review queue, compliance workflow, or any system where agent decisions carry operational, financial, or regulatory weight. The prompt assumes the agent has already acted or recommended a course of action that is now being challenged.

You should use this prompt when the override action must be traceable to the agent's original rationale to satisfy audit, governance, or continuous improvement requirements. For example, in a financial compliance workflow, an agent might flag a transaction as 'low risk' and allow it to proceed. If a human reviewer later identifies a missing sanctions flag, this prompt structures the override to include the agent's original risk classification, the evidence it considered, the reviewer's counter-evidence, and the final corrected action. The output becomes a permanent part of the decision record, not a transient chat message. The prompt is essential when the reason for the override is as important as the override itself, such as when downstream systems, model fine-tuning datasets, or regulatory auditors will later need to understand why a human intervened.

Do not use this prompt for general handoff summaries, initial approval requests for pending actions, or simple error logging. It is not designed for agents asking for clarification before acting, nor for agents handing off incomplete tasks. This prompt is specifically for the post-action override scenario. If you need an agent to request permission before acting, use an Approval Request Prompt with Risk Justification instead. If you need to summarize an agent's work for a human to continue, use an Agent-to-Human Handoff Summary Prompt. Using this prompt in the wrong context will produce an output that implies an override has occurred when it hasn't, creating a false audit trail and potentially masking the true state of the workflow. Before implementing, confirm that your system has access to the agent's original decision payload and reasoning trace; without these inputs, the prompt cannot fulfill its core function of faithfully representing the agent's rationale.

This template is designed to be wired into an agent execution harness at the point where a human reviewer has flagged an agent decision for override. Instead of forcing the reviewer to reconstruct context from raw logs, the prompt forces the agent to produce a structured, self-contained override request that includes its original decision, the evidence and reasoning that led to it, and the precise override instruction received from the human. The output serves as both an action record and an audit artifact. Replace each square-bracket placeholder with data from your agent trace, decision log, and human review interface before sending the prompt.

textCopy
SYSTEM: You are an agent operating in a human-in-the-loop workflow. Your task is to produce a structured override request when a human reviewer has decided to override one of your previous decisions. You must faithfully represent your original reasoning without defensiveness or distortion.

USER:
I need to document an override request for audit and execution purposes.

ORIGINAL DECISION:
[DECISION_ID]
[DECISION_TIMESTAMP]
[DECISION_SUMMARY]

ORIGINAL REASONING CHAIN:
[REASONING_STEPS]

EVIDENCE CONSIDERED:
[EVIDENCE_LIST_WITH_SOURCES]

CONFIDENCE AT DECISION TIME:
[CONFIDENCE_SCORE_AND_RATIONALE]

OVERRIDE REQUESTED BY:
[REVIEWER_ID]
[REVIEW_TIMESTAMP]

OVERRIDE INSTRUCTION:
[OVERRIDE_DESCRIPTION]

OVERRIDE RATIONALE FROM REVIEWER:
[REVIEWER_RATIONALE]

OUTPUT_SCHEMA:
{
  "override_request": {
    "request_id": "string",
    "original_decision": {
      "decision_id": "string",
      "timestamp": "ISO8601",
      "summary": "string",
      "reasoning_chain": [
        {
          "step_number": "integer",
          "step_description": "string",
          "evidence_cited": ["string"],
          "intermediate_conclusion": "string"
        }
      ],
      "evidence_considered": [
        {
          "evidence_id": "string",
          "source": "string",
          "excerpt": "string",
          "relevance": "string"
        }
      ],
      "confidence": {
        "score": "float 0.0-1.0",
        "rationale": "string"
      },
      "alternatives_rejected": [
        {
          "alternative": "string",
          "rejection_reason": "string"
        }
      ]
    },
    "override": {
      "reviewer_id": "string",
      "timestamp": "ISO8601",
      "instruction": "string",
      "reviewer_rationale": "string"
    },
    "agent_acknowledgment": {
      "understood_override": "boolean",
      "impact_on_original_reasoning": "string",
      "new_action_plan": "string"
    }
  }
}

CONSTRAINTS:
- Do not alter, minimize, or reframe your original reasoning to make the override seem obvious in hindsight.
- Include all evidence you considered, even evidence that pointed away from your original decision.
- If the reviewer's rationale identifies a gap in your reasoning, acknowledge it explicitly in the acknowledgment section.
- If you disagree with the override, state your disagreement professionally in the acknowledgment while committing to execute the override as instructed.
- All evidence excerpts must be verbatim from the original source, not paraphrased.
- The confidence score must reflect your confidence at the time of the original decision, not after seeing the override.

Adaptation notes: The ORIGINAL REASONING CHAIN placeholder should be populated from your agent's trace, not reconstructed from memory. If your agent framework captures reasoning steps as structured objects, map them directly into the reasoning_chain array. The EVIDENCE_CONSIDERED list must include every piece of evidence the agent evaluated, including evidence it ultimately discounted—omitting contrary evidence is a common failure mode that makes override records unreliable for audit. If the reviewer did not provide a rationale, set REVIEWER_RATIONALE to an empty string and add a constraint requiring the agent to note the missing rationale in its acknowledgment. For high-risk domains such as healthcare, finance, or legal, add a [RISK_LEVEL] placeholder and a constraint requiring the agent to flag whether the override increases or decreases risk relative to the original decision.

What to do next: After copying this template, integrate it into your human review interface so that when a reviewer clicks "Override," the system automatically populates the placeholders from the agent trace and reviewer input. Then run the prompt and validate the output against the schema before writing the override record to your audit log. What to avoid: Do not use this prompt without first verifying that the agent's reasoning trace is complete—if your agent framework truncates or summarizes reasoning steps, the override record will be incomplete and may fail audit review.

The Human Override Request prompt is not a standalone chat interaction—it is a structured handoff component inside a larger agent execution loop. In practice, this prompt fires when an agent has made a decision, a human reviewer flags it for override, and the system must produce a faithful, auditable record of what the agent originally decided, why, and what the human is changing. The implementation harness must enforce that the agent's rationale is captured before the override is accepted, not reconstructed after the fact. This means the agent's decision trace—including its reasoning chain, evidence considered, and confidence score—must be stored as a structured object at decision time, then passed into this prompt as [AGENT_RATIONALE] alongside the [OVERRIDE_REQUEST] from the human reviewer.

Wire this prompt into your application as a synchronous step in an approval or review pipeline. The typical flow: (1) Agent executes a task and emits a decision payload containing decision_id, decision_summary, reasoning_chain, evidence_citations, confidence_score, and proposed_action. (2) A human reviewer inspects the decision and submits an override request with override_reason, corrected_action, and reviewer_id. (3) The harness assembles the prompt with [AGENT_RATIONALE] populated from the stored decision payload and [OVERRIDE_REQUEST] from the reviewer's input. (4) The model produces a structured override record that faithfully represents the agent's original reasoning alongside the human's correction. (5) The output is validated against [OUTPUT_SCHEMA] before being written to an audit log. Do not allow the override to execute until the structured record is persisted. For high-risk domains, insert a second human confirmation gate after the override record is generated but before the corrected action is applied.

Validation is critical here because the primary failure mode is misrepresentation: the model might distort the agent's original reasoning to make the override look more justified, or it might omit key evidence the agent relied on. Implement a post-generation evaluation step that checks: (a) the agent_original_decision field in the output matches the stored decision payload exactly in substance, (b) all evidence_cited entries in the output appear in the original agent trace, and (c) the override_rationale does not introduce claims the human reviewer did not make. Use a lightweight LLM-as-judge eval with a rubric that penalizes hallucinated justifications and rewards faithful summarization. Log every override event with decision_id, reviewer_id, timestamp, original_decision, override_request, and the final structured output for auditability. For compliance workflows, these records must be immutable and queryable by decision ID or reviewer.

Model choice matters: use a model with strong instruction-following and low hallucination rates for this prompt, since the cost of misrepresenting an agent's reasoning in an override context can be high (incorrect actions, compliance violations, eroded trust). GPT-4o, Claude 3.5 Sonnet, or equivalent frontier models are appropriate. Avoid smaller or older models that may paraphrase the agent's reasoning loosely. Set temperature low (0.0–0.2) to maximize factual consistency. If the override workflow is part of a regulated process, do not rely solely on the model output—require the human reviewer to explicitly confirm that the generated override record accurately reflects both the agent's original decision and their correction before the record is finalized. The prompt template itself should include a [RISK_LEVEL] parameter that gates whether a second human review is required: for high risk, the harness must block execution until confirmation is received; for low risk, the override can proceed after the structured record is persisted.

Common integration pitfalls to avoid: (1) Passing the agent's raw log or chat transcript as [AGENT_RATIONALE] instead of a structured decision payload—this causes the model to summarize loosely rather than faithfully represent the reasoning. Always extract and structure the agent's decision before invoking this prompt. (2) Allowing the human reviewer to submit free-text overrides without capturing reviewer_id and timestamp—this breaks audit trails. Enforce these fields in the override submission form. (3) Skipping the post-generation validation step and writing the model output directly to the audit log—this risks persisting misrepresented records. Always validate before persisting. (4) Using this prompt for real-time override of safety-critical systems without a human-in-the-loop confirmation gate—the prompt structures the record, it does not authorize the action. The harness must separate record generation from action execution.