templates Agent Email Reply Templates
Agent-generated replies should be specific, short, and auditable. These templates keep the agent from overclaiming, ask for clarification when confidence is low, and route risky cases to a human reviewer.
last updated 2026-08-13 4 templates
implementation note
Replace variables before sending, keep one primary action per email, and connect each template to a specific trigger rather than a generic drip schedule.
01 Clarification needed
Intent is clear but required fields are missing. subject
A quick clarification
preview
The agent needs one missing detail before taking action.
body
Hi {{recipient_name}},
To complete {{requested_action}}, one detail is still needed:
{{missing_detail}}
Reply with that detail and the request can continue.
{{sender_name}} variables
{{recipient_name}}{{requested_action}}{{missing_detail}}{{sender_name}}
mistakes to avoid
- ›Guessing the missing detail.
- ›Asking multiple unrelated questions.
- ›Pretending the action is already complete.
02 Action completed
Agent action completes and the policy allows automatic confirmation. subject
{{action_name}} is complete
preview
Confirmation after an approved action finishes.
body
Hi {{recipient_name}},
{{action_name}} is complete.
Reference: {{reference_id}}
Summary: {{safe_summary}}
{{sender_name}} variables
{{recipient_name}}{{action_name}}{{reference_id}}{{safe_summary}}{{sender_name}}
mistakes to avoid
- ›Including sensitive internal reasoning.
- ›Omitting a reference ID.
- ›Adding promotional copy to a transactional confirmation.
03 Human review handoff
Policy marks the outbound action as high risk or low confidence. subject
This request is under review
preview
A human reviewer needs to approve the next step.
body
Hi {{recipient_name}},
This request needs human review before the next step can happen.
Reason: {{review_reason}}
Expected review window: {{review_window}}
{{sender_name}} variables
{{recipient_name}}{{review_reason}}{{review_window}}{{sender_name}}
mistakes to avoid
- ›Blaming the model.
- ›Giving a fake review time.
- ›Sending the risky content before approval.
04 Unable to complete
Policy denies an email-based action. subject
This request cannot be completed
preview
Clear denial when policy blocks the action.
body
Hi {{recipient_name}},
This request cannot be completed by email.
Reason: {{safe_reason}}
Use this path instead: {{next_step_link}}
{{sender_name}} variables
{{recipient_name}}{{safe_reason}}{{next_step_link}}{{sender_name}}
mistakes to avoid
- ›Revealing security rule internals.
- ›Leaving the user without a next step.
- ›Using vague denial language.
reading this as developers picking email infrastructure
The question here is which one a backend engineer would rather operate. That means SDK depth in the language already in use, whether a retry can safely be replayed, how much the event log tells you when a customer says the email never arrived, and whether the pricing curve stays sane as volume grows.
Applied to agent email reply templates, that means weighing developer experience, SDK breadth, idempotency keys, and operating track record ahead of the rest, against password resets, receipts, and magic links shipped from application code.