Agent Session Reconstruction Prompt for Auditors

This prompt is designed for auditors, governance engineers, and compliance officers who need to reconstruct a single, coherent narrative from raw multi-agent execution logs. The job-to-be-done is transforming fragmented, timestamped event streams—user requests, agent reasoning steps, tool calls, and final outputs—into a chronological, human-readable summary suitable for audit review. The ideal user is someone who already has access to structured or semi-structured agent logs but lacks the time to manually piece together a session's causal chain. Required context includes the raw log data, the session identifier, and any known agent role definitions to correctly attribute actions.

You should use this prompt when the audit objective is to understand what happened in a specific user interaction, verify that agent actions were appropriate, or detect missing events. It is particularly effective for post-hoc reviews of escalated support tickets, compliance spot-checks, or debugging unexpected agent behavior. The prompt is designed to handle logs from systems with multiple specialized agents, parallel tool calls, and interleaved events. It explicitly checks for temporal inconsistencies, such as responses that appear before their triggering requests, and flags missing context gaps where a handoff or tool result is referenced but not present in the provided log data.

Do not use this prompt for real-time monitoring dashboards, aggregate trend analysis across thousands of sessions, or as a replacement for structured log storage. It is a reconstruction tool, not a live observability system. If the raw logs contain redacted or encrypted fields, the prompt will note the gap but cannot recover the original data. For high-risk domains such as healthcare or finance, the output of this prompt is a draft audit artifact that requires human review before being accepted as an official record. The next step after generating the narrative is to validate its factual consistency against the source logs using an evaluation rubric, checking for hallucinated events or misattributed actions.

This prompt template is designed to be the core instruction you send to an LLM when an auditor needs a chronological, narrative summary of a specific user interaction that spanned multiple agents. It forces the model to act as a forensic analyst, not a creative writer. The template uses square-bracket placeholders for all variable inputs, ensuring you can programmatically inject raw logs, session metadata, and output constraints without manual editing. Before using this template, ensure your raw logs are structured and contain the minimum required fields: a consistent timestamp format, a unique event identifier, and a clear actor (user, agent name, or tool name). The prompt is designed to be strict; it instructs the model to flag missing data rather than hallucinate a coherent story.

textCopy
You are an AI forensic auditor. Your task is to reconstruct a strict chronological narrative of a multi-agent session from the provided raw event logs.

## INPUT DATA
- Session ID: [SESSION_ID]
- User Query: [USER_QUERY]
- Raw Event Log (JSON):
[RAW_EVENT_LOG]

## OUTPUT SCHEMA
Produce a JSON object conforming to this exact schema:
{
  "session_id": "string",
  "reconstruction": {
    "summary": "A one-paragraph executive summary of the user's request and the final outcome.",
    "timeline": [
      {
        "sequence_number": "integer",
        "timestamp": "ISO 8601 string from the log",
        "actor": "user | agent_name | tool_name",
        "action": "A concise, factual description of the event.",
        "reasoning": "The agent's stated reasoning for the action, or null for user/tool events.",
        "source_event_ids": ["list of event IDs from the raw log that support this step"]
      }
    ],
    "anomalies": [
      {
        "type": "temporal_inconsistency | missing_event | duplicate_action | unauthorized_action | other",
        "description": "A clear description of the anomaly.",
        "related_event_ids": ["list of relevant event IDs"]
      }
    ],
    "unresolved_questions": ["A list of questions that cannot be answered from the provided logs alone."]
  },
  "audit_metadata": {
    "generated_at": "ISO 8601 timestamp of this analysis",
    "log_completeness": "complete | partial | corrupt",
    "confidence_score": "0.0 to 1.0 rating of how well the logs support the reconstruction"
  }
}

## CONSTRAINTS
1. **Chronological Order Only:** Reconstruct events strictly by their timestamp. Do not group by agent or topic.
2. **Evidence Grounding:** Every step in the timeline must include `source_event_ids` that directly reference the [RAW_EVENT_LOG]. Do not infer events that are not present in the log.
3. **Anomaly Detection:** Actively scan for temporal inconsistencies (e.g., a response before a request), gaps in the event sequence, and actions taken by agents outside their defined role. Flag these in the `anomalies` array.
4. **Handle Missing Data:** If the logs are incomplete or corrupt, set `log_completeness` to the appropriate value, lower the `confidence_score`, and list specific gaps in `unresolved_questions`. Do not fabricate a clean narrative from bad data.
5. **No Speculation:** The `reasoning` field must be a direct quote or a close, faithful paraphrase of the agent's stated reasoning in the log. If no reasoning is present, use `null`.

## RISK LEVEL
[RISK_LEVEL]

## EXAMPLES
[EXAMPLES]

To adapt this template, start by mapping your internal log schema to the RAW_EVENT_LOG placeholder. The prompt expects a JSON array of event objects, but the model can handle a JSON string if that's how your logging system exports data. The most critical adaptation is the anomalies type list; you should tailor the enum values to match the known failure modes of your specific agent framework. For high-risk audit scenarios, always set the RISK_LEVEL to high and add a final instruction in the CONSTRAINTS section to refuse to answer if the confidence_score falls below a threshold like 0.7. After generating the output, you must validate the JSON against the schema and verify that every source_event_ids reference is a real ID in the input log to prevent hallucinated citations.

This prompt is designed to be called programmatically as part of an audit pipeline, not as a one-off chat interaction. The typical harness receives raw agent logs, session metadata, and a reconstruction request, then assembles the prompt with the required [RAW_LOGS], [SESSION_ID], [USER_QUERY], and [AUDIT_SCOPE] placeholders. The model response should be a structured JSON object containing the chronological narrative, a list of detected anomalies, and a completeness score. Because this output may be used as evidence in compliance reviews, the harness must validate the response against a strict schema before storing it.

Implement a validation layer that checks the reconstructed timeline for internal consistency: every event must have a timestamp, every tool call must have a corresponding response event, and the final agent response must appear after all tool calls. If the model output fails schema validation or contains unresolved placeholders, retry once with a more explicit instruction to fix the specific violation. For high-risk audits, route outputs with a completeness score below 0.8 or with unresolved temporal anomalies to a human review queue. Log every reconstruction attempt, including the raw prompt, model response, validation result, and reviewer decision, to maintain an audit trail of the reconstruction process itself.

Choose a model with strong instruction-following and long-context handling, such as Claude 3.5 Sonnet or GPT-4o, since raw agent logs can exceed 10k tokens. Set temperature to 0 or very low (0.1) to maximize deterministic, repeatable reconstructions. If the logs span multiple sessions or contain tool outputs with sensitive data, apply a redaction step before prompt assembly. Never pass raw PII or credentials into the reconstruction prompt. For production deployments, cache the prompt template and version it alongside your audit tooling so that reconstruction behavior is reproducible across audit periods.