Task Completion Summary Prompt for Operators

This prompt is designed for the final step of an agent execution loop. After a multi-step workflow completes, fails partially, or exhausts its retry budget, an operator needs a structured summary to decide the next action without reading the full execution trace. The ideal user is an SRE, engineering lead, or operations specialist responsible for supervising autonomous agents in production. They need a concise, evidence-backed handoff that reconciles what was accomplished against the original objectives, flags deviations, inventories artifacts, and recommends follow-ups. The required context includes the original plan or goal, a structured execution log, and any tool outputs or error traces generated during the run.

Use this prompt when you need a single, definitive summary at the end of an agent's execution. It is particularly valuable for long-running workflows where reviewing the full trace is impractical, for partially failed runs where partial results must be preserved, and for compliance-sensitive environments where every agent decision needs a human-readable audit trail. The prompt forces the model to perform completeness checks against the original objectives, explicitly list unresolved items, and provide a clear recommendation for the operator. This structured output can then be routed to a review queue, logged as an audit record, or used to trigger downstream workflows.

Do not use this prompt for real-time streaming status updates or mid-execution heartbeats. Those require separate monitoring prompts designed for incremental progress reporting, such as the Agent Execution Heartbeat Prompt Template or the Stuck Agent Detection and Alert Prompt. This prompt is also inappropriate for interactive debugging sessions where an operator is actively stepping through the agent's reasoning; in that case, a conversational trace exploration interface is more effective. Finally, do not use this prompt for workflows where the agent's output is consumed directly by another automated system without human review—those handoffs require machine-readable status codes and structured state objects, not operator-facing narratives.

This prompt template is designed to be pasted directly into your agent's completion handler after a multi-step workflow finishes. It instructs the model to produce a concise, structured summary for a human operator, covering what was accomplished, any deviations from the original plan, unresolved items, artifacts produced, and recommended follow-up actions. The summary acts as a handoff document between the autonomous agent and the human responsible for oversight.

textCopy
You are an operator reporting agent. Your task is to produce a final task completion summary for a human operator after a multi-step workflow has finished executing.

## Inputs
- Original Plan: [ORIGINAL_PLAN]
- Execution Log: [EXECUTION_LOG]
- Final State: [FINAL_STATE]
- Artifact Inventory: [ARTIFACT_INVENTORY]

## Output Schema
Return a single JSON object with the following structure:
{
  "summary": {
    "objective": "string (restate the original objective in one sentence)",
    "status": "string (enum: completed | partially_completed | failed | abandoned)",
    "completed_steps": ["string (step ID and brief outcome)"],
    "failed_steps": ["string (step ID, failure reason, and recovery attempted)"],
    "skipped_steps": ["string (step ID and reason for skipping)"],
    "deviations_from_plan": ["string (description of any deviation, its cause, and its impact)"],
    "unresolved_items": ["string (open questions, incomplete work, or blocked dependencies)"],
    "artifacts_produced": ["string (file path, URI, or identifier for each output artifact)"],
    "recommended_follow_up": ["string (actionable next step for the operator)"],
    "completeness_check": {
      "original_objectives_met": ["string (objective and whether it was satisfied)"],
      "missing_coverage": ["string (any part of the original request not addressed)"]
    },
    "operator_notes": "string (any additional context the operator needs, including assumptions made or risks identified)"
  }
}

## Constraints
- Be concise. Each string field should be no more than 2-3 sentences unless the complexity demands more.
- If the workflow completed successfully, the tone should be factual and brief.
- If there were failures or deviations, clearly separate what went wrong from what succeeded. Do not bury failures in optimistic language.
- If the original plan was modified during execution, explain why and what the new plan became.
- If any artifacts are missing or corrupted, flag them explicitly.
- Do not invent outcomes. Only report what is present in the Execution Log and Final State.
- If the Execution Log is incomplete or truncated, note this in `operator_notes` and mark confidence as low.

To adapt this template, replace each square-bracket placeholder at runtime: [ORIGINAL_PLAN] should contain the agent's initial plan object, [EXECUTION_LOG] should contain the full trace of tool calls and observations, [FINAL_STATE] should contain the agent's final memory or state snapshot, and [ARTIFACT_INVENTORY] should list every file, record, or side effect produced. Before deploying, validate that the model's output conforms to the JSON schema using a programmatic validator. For high-risk workflows, route summaries with a failed or abandoned status to a human review queue before any downstream action is taken. Log every generated summary alongside the execution trace for auditability.

Wire this prompt into your agent runtime as a post-execution hook. Call it after the agent's main loop exits, regardless of exit reason (success, failure, escalation, or abandonment). The prompt consumes the execution trace, final state, and original plan to produce a structured operator summary. This summary is the primary handoff artifact between the agent and the human operator, so it must be generated reliably and routed correctly. Do not call this prompt if the agent was interrupted mid-execution and will resume; use a checkpoint prompt instead to preserve resumable state.

For strict schema compliance, use Structured Outputs or JSON mode with the output contract defined in the prompt template. Validate the response before routing: confirm that completion_status is a recognized enum value, artifacts_produced contains valid URIs or identifiers, and unresolved_items is populated when the status is not completed. If validation fails, retry once with the validation errors injected into the prompt context. If the second attempt also fails, log the raw output and escalate to the human review queue with a summary_generation_failed flag. For high-risk workflows (finance, healthcare, legal), always route summaries to a human review queue regardless of validation status, and require explicit acknowledgment before the workflow is marked closed.

Pass the validated structured output to your notification layer—Slack, email, dashboard, or ticketing system—based on the recommended_escalation field. If the summary indicates unresolved items or recommends escalation, route to a human review queue with the full summary payload and a link to the execution trace. Log the full summary alongside the execution trace for auditability, including the prompt version, model identifier, timestamp, and validation result. For long-running workflows, consider appending this summary to a session-level audit log that operators can query without accessing raw traces. Avoid calling this prompt on empty or near-empty execution traces, as the model may hallucinate completion details; instead, surface a no_execution_data status directly from the harness.