Agent Completion Notification Prompt Template

This prompt is designed for orchestration engineers and platform builders who need a standardized way for agents to announce task completion. Use it when an agent finishes a delegated task and must communicate results, confidence, evidence, and recommended next steps to the orchestrator or downstream agent. The primary job-to-be-done is enforcing a structured output contract so that completion payloads are machine-parseable, auditable, and safe to act on without manual inspection. The ideal user is an AI platform engineer wiring together agent graphs, DAG-based executors, or event-driven agent meshes where a missing or malformed completion signal can stall the entire pipeline.

This prompt is not appropriate for progress updates mid-task, error reporting, or handoff summaries between agents with different capability scopes. Those scenarios require separate templates with different output contracts—progress updates need partial result fields and estimated time remaining, error reports need stack traces and retry eligibility flags, and handoff summaries need recipient-specific action items. Using this completion prompt for those purposes will produce payloads that are either missing critical fields or misleadingly marked as terminal. The prompt assumes the agent has fully completed its assigned work and is ready to yield control. If your agent is in a streaming or incremental execution mode, pair this prompt with a separate progress update template and only invoke completion when the final step is done.

Before wiring this into production, ensure your agent runtime can validate the output against the expected schema before forwarding it to the orchestrator. A completion payload with a missing evidence array or an uncalibrated confidence_score can cause downstream agents to act on incomplete information. In high-risk domains such as healthcare, finance, or legal workflows, add a human review gate that inspects the recommended_next_steps field before any automated action is taken. Do not use this prompt as a fire-and-forget signal in systems where the cost of a false completion is high—always pair it with idempotency keys, correlation IDs, and a dead-letter queue for payloads that fail validation.

This prompt template generates a standardized completion notification that one agent sends to an orchestrator or downstream agent when it finishes its assigned task. The payload enforces a strict contract: it requires the agent to report what it did, what it found, how confident it is, what evidence supports its conclusions, and what should happen next. Without this structure, agent chains accumulate silent failures—an agent might complete its work but fail to communicate critical uncertainty, missing evidence, or the fact that it skipped a step. This template is designed for orchestration engineers who need every agent in a chain to speak the same completion language.

textCopy
You are an agent that has just completed an assigned task. Generate a structured completion notification using the exact schema below. Do not omit any required fields. If a field cannot be populated, set it to null and include a reason in the `field_omissions` array.

TASK CONTEXT:
- Task ID: [TASK_ID]
- Task Description: [TASK_DESCRIPTION]
- Assigned Agent Role: [AGENT_ROLE]
- Input Summary: [INPUT_SUMMARY]

COMPLETION SCHEMA (JSON):
{
  "notification_type": "task_completion",
  "task_id": "[TASK_ID]",
  "agent_role": "[AGENT_ROLE]",
  "status": "[SUCCESS | PARTIAL | FAILED | ABORTED]",
  "completion_summary": "[One-paragraph summary of what was accomplished]",
  "results": {
    "primary_output": "[Main deliverable or finding]",
    "secondary_outputs": ["[Optional list of additional outputs]"],
    "output_format": "[JSON | TEXT | STRUCTURED_OBJECT | FILE_REFERENCE]"
  },
  "confidence": {
    "score": [0.0-1.0],
    "calibration_notes": "[How this score was determined]",
    "low_confidence_factors": ["[Specific reasons for uncertainty]"]
  },
  "evidence": [
    {
      "source_id": "[SOURCE_IDENTIFIER]",
      "source_type": "[DOCUMENT | TOOL_OUTPUT | API_RESPONSE | PRIOR_AGENT | USER_INPUT]",
      "relevance": "[Why this evidence matters]",
      "excerpt_or_reference": "[Direct quote, pointer, or summary]"
    }
  ],
  "completeness": {
    "all_steps_completed": [true | false],
    "skipped_steps": ["[Steps that were skipped and why]"],
    "remaining_work": "[What still needs to be done, if anything]"
  },
  "next_step_recommendations": [
    {
      "action": "[Recommended next action]",
      "target_agent_or_role": "[Who should perform it]",
      "priority": "[HIGH | MEDIUM | LOW]",
      "deadline_if_applicable": "[ISO timestamp or null]"
    }
  ],
  "escalation_triggers": [
    {
      "condition": "[What condition should trigger escalation]",
      "severity": "[CRITICAL | WARNING | INFO]",
      "recommended_escalation_target": "[Human reviewer, supervisor agent, or fallback path]"
    }
  ],
  "field_omissions": [
    {
      "field": "[Field name]",
      "reason": "[Why it could not be populated]"
    }
  ],
  "correlation_id": "[CORRELATION_ID]",
  "timestamp": "[ISO 8601 timestamp]"
}

CONSTRAINTS:
- The `status` field must be exactly one of: SUCCESS, PARTIAL, FAILED, ABORTED.
- If status is PARTIAL or FAILED, the `remaining_work` field must contain actionable detail.
- Every evidence item must include a `source_id` that can be traced back to an upstream artifact.
- Confidence scores below 0.7 must include at least one `low_confidence_factor`.
- If the task was ABORTED, the `completion_summary` must explain why and the `next_step_recommendations` must include a recovery path.
- Do not fabricate evidence. If no evidence exists, set the `evidence` array to empty and note it in `field_omissions`.

To adapt this template, replace the square-bracket placeholders with actual values from your orchestration layer before sending it to the model. The TASK_CONTEXT block should be populated by the orchestrator that assigned the task—this gives the agent the information it needs to self-report accurately. The schema itself should be treated as a contract: your downstream agent or orchestrator should validate every incoming completion notification against this schema before acting on it. If a required field is missing or malformed, reject the notification and request a corrected payload rather than proceeding with incomplete information. For high-risk workflows where incorrect completions could cause downstream damage, add a human review step before the notification is accepted by the next agent in the chain.

The Agent Completion Notification prompt is designed to be called at the end of an agent's execution cycle, not as a standalone chat interaction. In a production orchestration system, this prompt should be invoked by the agent harness immediately after the agent produces its final output. The harness passes the agent's raw result, the original task contract, and any execution metadata into the prompt to generate a structured completion payload. This payload then becomes the input to the next agent in the chain or the final response to the user. The key integration point is that the completion notification is not the agent's output—it is a wrapper that makes the output machine-readable and auditable.

Wire this prompt into your agent framework as a post-execution hook. After the agent completes its primary task, call the completion notification prompt with the following inputs: the agent's raw output, the original task specification, the agent's role identifier, and any tool call logs or evidence artifacts. The prompt returns a structured JSON payload containing the result summary, confidence score, evidence attachments, and next-step recommendations. Validate this payload against a strict schema before forwarding it. If validation fails, retry the prompt once with the validation errors injected into the [CONSTRAINTS] field. If the retry also fails, log the failure and escalate to a human reviewer with the raw agent output attached. For high-risk domains, always require human approval on the completion payload before it triggers downstream actions.

For observability, log every completion notification payload with a correlation ID that traces back to the originating task. Store the raw agent output, the generated completion payload, and the validation result in your audit system. This creates a verifiable chain: task request → agent execution → completion notification → downstream action. When choosing a model for this prompt, prefer models with strong JSON mode and schema adherence. The completion notification prompt is a structural contract, not a creative task, so smaller, faster models often perform well here. Avoid using this prompt for agents that produce streaming outputs or incremental results—it is designed for discrete task completion with a clear end state. If your agent produces partial results over time, use the Agent Progress Update Message prompt instead and reserve this completion notification for the final handoff.