Agent Chain Accountability Summary Prompt

This prompt is designed for compliance engineers, governance teams, and auditors who need to understand what happened inside a multi-agent workflow without reading raw, verbose logs. The job-to-be-done is to synthesize a structured, human-readable accountability summary from a chain of agent decision logs, handoff records, and tool-call traces. The ideal user is someone who must answer the question 'Who did what, why, and when?' for a specific transaction or workflow execution, often under regulatory or internal audit pressure. The required context is a complete, ordered set of agent artifacts—decision logs, handoff payloads, tool invocation records, and any human approval events—for a single, identifiable workflow run.

Use this prompt when you have a linear or branching chain of agent actions and need a single document that highlights key decision points, escalation triggers, and the flow of accountability between agents. It is particularly valuable for post-hoc review of high-stakes workflows in finance, healthcare, or any domain where agent actions have material consequences. The prompt is designed to enforce factual consistency with the underlying logs, so it includes explicit instructions to cite source artifacts and flag any gaps in the provided trace. You should not use this prompt for real-time agent orchestration, for debugging a single agent's reasoning in isolation, or when the underlying logs are incomplete or untrusted—garbage in, garbage out applies with full force here.

Before using this prompt, ensure you have assembled a complete artifact package for the workflow run. Missing handoff records or tool-call logs will produce an unreliable summary. The prompt is not a substitute for a structured logging system; it is a post-processing step that assumes well-formed input. If your agent logs are inconsistent, start with the Agent Decision Log Entry Prompt Template and Multi-Agent Handoff Record Prompt Template to standardize your inputs first. After generating the summary, you must validate it against the source logs using the provided eval criteria for factual consistency, and in regulated contexts, a human reviewer should sign off on the final accountability document before it is archived or submitted to auditors.

This template is designed to be copied directly into your prompt library or orchestration layer. It accepts a raw, multi-agent log chain and produces a structured summary that answers the core audit questions: who did what, when, and why. The prompt enforces a strict output schema so the result can be parsed by downstream compliance tools or rendered in a review dashboard. All placeholders are enclosed in square brackets—replace them with your actual log data, risk classifications, and output format requirements before execution.

textCopy
You are an audit assistant specialized in multi-agent workflow analysis. Your task is to read a chain of agent execution logs and produce a structured accountability summary. The summary must be factual, grounded strictly in the provided logs, and must not invent actions, intentions, or outcomes not explicitly recorded.

## INPUT
[AGENT_LOG_CHAIN]

## CONSTRAINTS
- Do not infer agent intent beyond what is logged.
- Flag any gaps in the log chain where context appears to be missing.
- If an agent's reasoning is not recorded, state "Reasoning not logged" rather than guessing.
- Preserve the chronological order of events.
- If the risk level is [RISK_LEVEL], apply heightened scrutiny to decision justifications and escalation triggers.

## OUTPUT SCHEMA
Return a single JSON object with the following structure:
{
  "workflow_id": "string",
  "summary": "A 2-3 sentence executive summary of what the agent chain accomplished.",
  "agents_involved": [
    {
      "agent_id": "string",
      "role": "string",
      "actions_taken": ["string"],
      "key_decisions": [
        {
          "decision": "string",
          "evidence_used": ["string"],
          "timestamp": "ISO 8601 string"
        }
      ],
      "escalations_triggered": [
        {
          "target": "string",
          "reason": "string",
          "timestamp": "ISO 8601 string"
        }
      ]
    }
  ],
  "handoff_points": [
    {
      "from_agent": "string",
      "to_agent": "string",
      "context_passed": "string",
      "context_missing": ["string"],
      "timestamp": "ISO 8601 string"
    }
  ],
  "unresolved_items": ["string"],
  "log_gaps_identified": ["string"],
  "overall_risk_flags": ["string"]
}

## EXAMPLES
[FEW_SHOT_EXAMPLES]

## INSTRUCTIONS
1. Parse the entire [AGENT_LOG_CHAIN] chronologically.
2. Identify each agent, its role, and every action taken.
3. For each key decision, extract the evidence cited in the logs. If no evidence is cited, note "No evidence logged."
4. Trace every handoff between agents and note any context that was requested but not provided.
5. List any items that were raised but never resolved.
6. Flag any time gaps, missing log entries, or jumps in the sequence.
7. If [RISK_LEVEL] is "high" or "critical", add a risk flag for any decision made without explicit human approval where policy would normally require it.
8. Output only the JSON object. Do not wrap it in markdown fences or add commentary.

To adapt this template, replace [AGENT_LOG_CHAIN] with the raw concatenated logs from your agent execution platform. The [RISK_LEVEL] placeholder should be set to low, medium, high, or critical based on your workflow's risk classification. The [FEW_SHOT_EXAMPLES] placeholder is optional but strongly recommended for production use—provide 1-2 example input/output pairs that demonstrate correct handling of edge cases like missing handoff context or agents acting outside their stated role. If your logs use a non-standard format, preprocess them into a consistent JSON or line-delimited structure before passing them to this prompt. For high-risk workflows, always route the generated summary to a human reviewer before it becomes part of an official audit trail.

The Agent Chain Accountability Summary Prompt is not a standalone chat interaction. It is a post-execution synthesis step that runs after a multi-agent workflow completes. The harness must collect all agent logs, decision records, tool call traces, and handoff payloads from the workflow execution, assemble them into a structured [CHAIN_LOG] input, and pass them to the prompt. This prompt should be invoked as a final step in the orchestration graph, triggered only when the primary workflow reaches a terminal state—success, failure, or escalation. Do not run this prompt on in-flight workflows; partial logs produce misleading summaries that auditors will reject.

Wire the prompt into an application by building a collector service that queries your agent execution store for all artifacts tied to a single workflow_id. The collector must retrieve: (1) the initial user request, (2) each agent's role definition and task assignment, (3) structured decision log entries from every agent, (4) tool call audit records with arguments and responses, (5) handoff records between agents, (6) any human escalation events with resolutions, and (7) error traces if the workflow failed. Serialize these into a JSON array ordered by timestamp and pass it as [CHAIN_LOG]. Validate the assembled log before calling the model: check that every agent in the expected chain produced at least one decision record, that timestamps are monotonically increasing, and that no handoff target references a missing agent. If validation fails, return an error to the orchestration layer rather than producing a degraded summary.

Model choice matters here. Use a model with a large context window (128K tokens minimum) and strong instruction-following for structured output. The prompt produces a JSON summary with fields like workflow_summary, agent_actions, key_decisions, escalation_triggers, and unresolved_items. Enforce the output schema with structured output APIs or a strict JSON mode. After generation, run automated evals: (1) check that every agent_id in the summary appears in the source [CHAIN_LOG], (2) verify that key_decisions entries quote or reference specific log timestamps, (3) confirm that escalation_triggers map to actual handoff or human-review events in the logs, and (4) flag any summary claim that cannot be traced to a source log entry as a potential hallucination. Failed evals should trigger a retry with the eval errors appended as [CONSTRAINTS] feedback, up to a maximum of two retries before escalating to a human reviewer.

For high-stakes audit workflows, insert a mandatory human review gate after generation. Present the reviewer with the summary, the raw [CHAIN_LOG], and the eval results side by side. The reviewer should confirm factual consistency, approve or amend the summary, and sign off before the artifact is stored in an immutable audit system. Log the reviewer's identity, timestamp, and any amendments as part of the final accountability record. Store the approved summary alongside the raw logs in an append-only store with a content hash for tamper evidence. Avoid treating this prompt's output as the sole audit artifact—it is a human-readable synthesis that must remain traceable to the underlying machine-readable records.