Agent Human Handoff Audit Prompt Template

This prompt is designed for governance engineers, compliance officers, and operations leads who are responsible for maintaining an auditable record of autonomous agent behavior. Its primary job is to convert raw, often unstructured data from an agent-to-human escalation event into a standardized, structured audit entry. This artifact serves as proof that the escalation was justified, the human operator received sufficient context to act, and the resolution was properly documented. It is a post-hoc governance tool, not a real-time operational component, and should be integrated into batch processing pipelines, compliance review workflows, or incident post-mortem analysis.

The ideal user has access to the raw materials of a handoff: the agent's original task, the escalation trigger reason, the exact context payload sent to the human, and the human's final resolution notes. The prompt requires these inputs to be assembled into a single structured block. You should not use this prompt if you are building a live dispatch system that routes tasks to human queues; it does not make routing decisions or generate the handoff message itself. Similarly, avoid using it when the underlying handoff data is incomplete, as the model may hallucinate plausible-sounding justifications to fill gaps, creating a false audit trail. For high-risk domains like healthcare or finance, the generated audit entry must be treated as a draft and reviewed by a human before it is committed to an immutable system of record.

Before using this prompt, ensure you have a clear schema for what constitutes a valid audit entry in your organization. The prompt template includes placeholders for [INPUT], [CONTEXT], and [OUTPUT_SCHEMA], which you must populate with your specific data and field definitions. The output is only as reliable as the input data and the clarity of the schema you provide. After generation, you should run automated validation checks against the output to confirm all required fields are present, the justification is non-empty, and the context provided to the human is sufficiently detailed. This prompt is a critical component of a broader agent accountability strategy, turning ephemeral handoff events into durable, reviewable evidence for system improvement and regulatory scrutiny.

This template is designed to be dropped directly into your application's prompt layer. It instructs the model to act as an impartial auditor, consuming raw handoff event data and producing a strictly structured JSON record. The prompt enforces precision by requiring the model to cite specific evidence from the provided input and to explicitly note any missing information, preventing the fabrication of plausible-sounding but unsupported details. Use this as your starting point, then adapt the placeholders and output schema to match your specific logging format and compliance requirements.

markdownCopy
You are an impartial audit system. Your task is to analyze the provided [HANDOFF_EVENT_DATA] and generate a structured audit record in JSON format.

# INPUT
[HANDOFF_EVENT_DATA]

# OUTPUT_SCHEMA
You must output a single JSON object conforming to this structure:
{
  "audit_record": {
    "event_id": "string",
    "timestamp": "string (ISO 8601)",
    "agent_id": "string",
    "escalation": {
      "trigger": "string (the specific condition or rule that caused the handoff)",
      "reason": "string (the agent's stated justification for the handoff, quoted or closely paraphrased from evidence)",
      "confidence_score_at_handoff": "number or null"
    },
    "context_provided_to_human": {
      "summary": "string (the summary the agent passed to the human)",
      "key_entities": ["string"],
      "pending_actions": ["string"],
      "context_completeness": "string (assessment: 'Sufficient', 'Partial', or 'Insufficient', with a brief justification)"
    },
    "human_resolution": {
      "action_taken": "string",
      "resolution_timestamp": "string (ISO 8601) or null",
      "was_agent_context_used": "boolean or null",
      "notes": "string"
    },
    "auditor_notes": {
      "missing_information": ["string"],
      "data_quality_issues": ["string"]
    }
  }
}

# CONSTRAINTS
1. **Evidence Grounding:** Every field must be directly traceable to the [HANDOFF_EVENT_DATA]. Do not infer or assume information not present.
2. **Missing Information:** If a required field cannot be populated from the evidence, use `null` for the value and add a specific note to the `auditor_notes.missing_information` list explaining what is missing.
3. **Precision:** For the `escalation.reason`, prefer a direct quote or a very close paraphrase over a vague summary.
4. **Output Format:** Your entire response must be the single JSON object, with no other text before or after it.

To adapt this template, start by replacing [HANDOFF_EVENT_DATA] with your actual log payload. The most critical customization is the OUTPUT_SCHEMA. You should modify the JSON structure to map exactly to your internal data model for handoff records. For instance, you might add fields for customer_id, handoff_queue_name, or sla_deadline. The CONSTRAINTS section is your primary lever for controlling model behavior; if you find the model still hallucinates details, strengthen the first constraint by adding, 'If you cannot find direct evidence for a field, you must use null.' Finally, integrate a JSON schema validator in your application harness immediately after the model response to catch any structural deviations before the record enters your system of record.

This prompt is designed to be called after a human-in-the-loop (HITL) event concludes. In a typical implementation, an orchestration layer detects that a human reviewer has resolved a queued escalation. The application then retrieves the original agent context, the escalation reason, the human's action, and any resolution notes, and passes them into this prompt to produce a structured, auditable handoff record. This record is not meant for real-time decision-making; it is a post-hoc governance artifact for operations, compliance, and quality assurance teams.

Wire this prompt into a dedicated audit logging service, not directly into the agent's runtime loop. The service should accept a structured input object containing the agent_id, session_id, escalation_reason, context_snapshot, human_reviewer_id, resolution_action, and resolution_notes. Before calling the LLM, validate that all required fields are present and that the context_snapshot is not truncated. After receiving the model's output, parse the JSON and validate it against a strict schema. If validation fails, retry once with a repair prompt that includes the schema and the raw, malformed output. Log both the raw and validated outputs to an append-only store, such as a database table with a created_at timestamp and a version field. For high-risk domains like healthcare or finance, route a sample of generated audit records to a human QA queue for periodic review against the source data.

Model choice matters here. Use a model with strong instruction-following and JSON mode capabilities, such as gpt-4o or claude-3.5-sonnet. Set temperature to 0 to maximize determinism. Do not use RAG or external tools for this prompt; all necessary context must be provided in the [CONTEXT] placeholder. The primary failure mode is an incomplete or hallucinated justification for the escalation. Mitigate this by implementing an eval step that checks if the escalation_justification field in the output can be directly traced back to a sentence in the input escalation_reason. If the justification introduces new facts not present in the input, flag the record for human review and block it from being stored as a verified artifact.