/email-for-ai-agents providers ↗
templates

Agent Email Tool Call Schema

Agent email tools should accept narrow structured inputs. A schema reduces accidental sends, makes review easier, and gives logs enough detail to explain why an email was sent.

last updated 2026-08-26 3 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 Outbound send tool call
Agent proposes an outbound email.
subject
Schema: send_agent_email
preview
Use this as the contract between the agent and email sending tool.
body
{
  "action": "send_agent_email",
  "tenant_id": "{{tenant_id}}",
  "source_event_id": "{{source_event_id}}",
  "idempotency_key": "{{idempotency_key}}",
  "recipient": {
    "email": "{{recipient_email}}",
    "user_id": "{{recipient_user_id}}"
  },
  "template_id": "{{template_id}}",
  "subject": "{{subject}}",
  "plain_text": "{{plain_text}}",
  "risk_level": "{{risk_level}}",
  "review_required": {{review_required}}
}
variables
{{tenant_id}}{{source_event_id}}{{idempotency_key}}{{recipient_email}}{{recipient_user_id}}{{template_id}}{{subject}}{{plain_text}}{{risk_level}}{{review_required}}
mistakes to avoid
  • Letting the model choose arbitrary sender domains.
  • Missing an idempotency key.
  • Sending when review_required is true.
02 Inbound extraction object
Inbound parser produces normalized text and headers.
subject
Schema: inbound_email_intent
preview
Extract intent before any agent action is allowed.
body
{
  "message_id": "{{message_id}}",
  "mailbox": "{{mailbox}}",
  "sender": "{{sender}}",
  "intent": "{{intent}}",
  "entities": {{entities_json}},
  "confidence": "{{confidence}}",
  "risks": {{risks_json}},
  "requested_action": "{{requested_action}}",
  "review_required": {{review_required}}
}
variables
{{message_id}}{{mailbox}}{{sender}}{{intent}}{{entities_json}}{{confidence}}{{risks_json}}{{requested_action}}{{review_required}}
mistakes to avoid
  • Passing raw MIME directly to action tools.
  • Ignoring confidence.
  • Treating reply-to as a verified app identity.
03 Approval policy object
Policy layer evaluates a proposed agent email.
subject
Schema: email_action_policy
preview
Use before outbound send execution.
body
{
  "action_id": "{{action_id}}",
  "risk_level": "{{risk_level}}",
  "requires_human_review": {{requires_human_review}},
  "review_reason": "{{review_reason}}",
  "allowed_sender": "{{allowed_sender}}",
  "allowed_recipient": {{allowed_recipient}},
  "max_attachment_count": {{max_attachment_count}},
  "decision": "{{decision}}"
}
variables
{{action_id}}{{risk_level}}{{requires_human_review}}{{review_reason}}{{allowed_sender}}{{allowed_recipient}}{{max_attachment_count}}{{decision}}
mistakes to avoid
  • Encoding policy only in a prompt.
  • Skipping audit fields.
  • Treating policy denial as a provider failure.

reading this as teams building autonomous agents

An agent stack treats email as a two-way primitive. Inbound has to arrive as structured JSON a tool call can consume, sends have to be safe to retry when a model loop repeats itself, and every action needs an audit trail. A provider without inbound parsing only solves half the problem.

Applied to agent email tool call schema, that means weighing inbound parsing, idempotency keys, webhook coverage, and operating track record ahead of the rest, against inbound parsing into tool calls and model-generated sends that must not duplicate.

related pages