Agent Decision Log Entry Prompt Template

Governance engineers and platform teams use this prompt to generate a structured, timestamped log entry every time an agent makes a decision. The log captures the agent's task, reasoning chain, evidence sources, the decision itself, and a confidence score. This prompt is designed for multi-agent systems where every action must be explainable to auditors, compliance reviewers, and incident responders. Use it when you need a verifiable decision trail that can be stored in append-only logs, fed into monitoring dashboards, or assembled into audit evidence packages.

The ideal user is an AI platform engineer or governance lead who owns the auditability contract for an agent system. You should have a defined schema for log entries, a storage target (such as a database with append-only semantics or a log stream), and a clear policy for which agent actions require a decision log. Before using this prompt, ensure you have the agent's full context available: the task description, the reasoning or chain-of-thought output, the evidence or tool outputs the agent consulted, and the final decision payload. The prompt works best when invoked as a post-action step in an agent execution loop, not as a real-time user-facing explanation.

Do not use this prompt for real-time user-facing explanations or for summarizing entire agent sessions; those require separate playbooks for explainability and session reconstruction. This prompt is also not a replacement for structured logging at the application layer—it complements application logs by producing a human-auditable narrative record. Avoid using it for low-risk, read-only agent actions where the cost of logging exceeds the compliance value. If your agent operates in a regulated domain, pair this prompt with the Agent Compliance Evidence Package Prompt and require human review for any log entry with a confidence score below your defined threshold.

This template is designed to be the single source of truth for recording an agent's action in a multi-agent system. It forces the model to capture not just the final decision, but the task context, the evidence considered, the reasoning path, and a calibrated confidence score. The output is a structured JSON object that can be directly ingested into an append-only audit log, making it a foundational component for governance, debugging, and compliance workflows. Before using this prompt, ensure you have a clear definition of the agent's role and the specific task it was assigned, as these are critical inputs.

textCopy
You are an audit logging agent. Your sole function is to produce a structured, timestamped decision log entry in strict JSON format. Do not perform the task described in the [TASK_DESCRIPTION]; only log the decision-making process that occurred.

Generate a JSON object using the following schema:
{
  "log_entry": {
    "agent_id": "[AGENT_ID]",
    "agent_role": "[AGENT_ROLE]",
    "task_id": "[TASK_ID]",
    "timestamp": "[TIMESTAMP]",
    "task_summary": "A one-sentence summary of the assigned task.",
    "input_context": {
      "user_request": "[USER_REQUEST]",
      "relevant_documents": ["[DOCUMENT_1_ID]", "[DOCUMENT_2_ID]"],
      "previous_agent_outputs": "[PREVIOUS_AGENT_OUTPUTS]"
    },
    "reasoning_trace": [
      "Step 1: Initial assessment of the task and available context.",
      "Step 2: Evaluation of key evidence or constraints.",
      "Step 3: Formation of a conclusion or decision."
    ],
    "decision": {
      "action_taken": "[ACTION_TAKEN]",
      "action_parameters": {},
      "justification": "A concise justification linking the decision to the evidence and reasoning."
    },
    "confidence": {
      "score": 0.0,
      "rationale": "Explanation for the confidence score, noting any key uncertainties or missing information."
    },
    "escalation_flag": false,
    "escalation_reason": null
  }
}

Populate the template using the following inputs:
- Agent ID: [AGENT_ID]
- Agent Role: [AGENT_ROLE]
- Task ID: [TASK_ID]
- Timestamp: [TIMESTAMP]
- Task Description: [TASK_DESCRIPTION]
- User Request: [USER_REQUEST]
- Relevant Document IDs: [DOCUMENT_IDS]
- Previous Agent Outputs: [PREVIOUS_AGENT_OUTPUTS]
- Action Taken: [ACTION_TAKEN]
- Action Parameters: [ACTION_PARAMETERS]

Constraints:
- The `reasoning_trace` must contain at least three distinct, logical steps.
- The `confidence.score` must be a float between 0.0 and 1.0.
- If the `confidence.score` is below [CONFIDENCE_THRESHOLD], set `escalation_flag` to true and provide a clear `escalation_reason`.
- The `decision.justification` must explicitly reference at least one piece of evidence from `input_context`.
- Output ONLY the valid JSON object. No other text.

To adapt this template, start by replacing the square-bracket placeholders with your application's runtime variables. The most critical adaptation is the CONFIDENCE_THRESHOLD, which should be tuned based on the risk tolerance of the specific agent's domain. For high-stakes actions like financial transactions or clinical decisions, set this threshold high (e.g., 0.9) and ensure the escalation_flag triggers a human-in-the-loop review. For lower-stakes informational tasks, a lower threshold may be acceptable. The reasoning_trace field is the most common point of failure; implement a post-generation validation check to ensure it contains distinct steps and not just a single paraphrased sentence.

After integrating this prompt, your next step is to build a validation harness. This harness should parse the JSON output and run a series of checks: schema compliance, presence of all required fields, a confidence score within the 0.0-1.0 range, and a logical consistency check between the confidence.score and the escalation_flag. For high-risk deployments, log a warning if the reasoning_trace is too short or if the decision.justification does not contain a reference to an item in the input_context. Avoid the temptation to use this log as a replacement for a human-readable summary; instead, pair it with a separate summarization prompt for audit or support workflows.

This prompt is not a standalone utility; it is a structured logging contract that must be called at every decision point in an agent's execution loop. The implementation harness should intercept the agent's reasoning state immediately before a tool call, action, or final response is committed. The prompt expects a snapshot of the agent's current task, the evidence it considered, the options it weighed, and the decision it intends to make. This snapshot is then formatted into a structured, timestamped log entry that can be appended to an append-only store, written to a database, or streamed to an observability platform. The harness must ensure that the log entry is generated before the action is executed, not after, to preserve an accurate record of the agent's intent.

To wire this into an application, wrap the agent's decision step in a function that assembles the required inputs—[AGENT_ID], [TASK_CONTEXT], [EVIDENCE_SOURCES], [DECISION_OPTIONS], [SELECTED_ACTION], and [CONFIDENCE_SCORE]—and passes them to the prompt template. The model's response should be validated against a strict JSON schema that includes required fields like log_id, timestamp, decision_rationale, and evidence_map. If validation fails, retry once with the validation error injected as a [CONSTRAINT] before escalating to a human reviewer. For high-risk domains, the harness should enforce a synchronous write to an immutable log store (e.g., a blockchain-anchored database or a write-once ledger) and return the log's cryptographic hash as part of the agent's execution context for downstream traceability.

Model choice matters here: use a model with strong instruction-following and JSON mode support, such as GPT-4o or Claude 3.5 Sonnet, to minimize format drift. Set temperature=0 to maximize determinism in the log structure. The harness should also log the raw prompt, the model's response, and the validation result to a separate debugging stream for prompt observability. Avoid the temptation to batch multiple decision logs into a single prompt call; each decision point should produce its own atomic log entry to prevent partial failures from corrupting a batch. Finally, implement a periodic audit job that samples log entries and runs the Agent Hallucination Detection Audit Prompt and Agent Factual Grounding Audit Prompt from the same pillar to verify that logged reasoning matches the evidence the agent actually had at the time of the decision.