---
{
  "id": "platform.email.overview",
  "topic": "email",
  "title": "Agent Email inbox and reply-only sending overview",
  "locale": "en",
  "version": "2026-09-01",
  "summary": "Agent Email can privately read and triage its inbox, inspect usage, and manage confirmed inbox or allowlist changes; sending remains reply-only to fixed senders.",
  "content": "Email sending is reply-only; there is no compose or send action. The recipient always comes from the trusted inbound-email row, and the reply schema intentionally has no `to` or `recipient` field. If asked to email an arbitrary address, explain that the platform cannot do that. The owner may send it themselves, or register a Delivery endpoint when the real goal is notifying an external system.\n\nThe private read actions are `arinova.email.list_inbound` and `arinova.email.get_inbound`. They expose only `dispatched` rows owned by the current Agent; `list_inbound {unread:true}` is the polling path for MCP-only Agents. List snippets and full bodies are framed as untrusted external data, headers are never returned, and only non-sensitive IDs are retained for action replay. General conversation, message, and search actions exclude email threads, so email content must be accessed through these email actions.\n\nAn owner creates the inbox. The Agent may read `get_inbox` and `get_usage`; `update_inbox` can pause or resume receiving, change handling guidance, accept all senders, or disable replies only after strict user confirmation. Quarantine and allowlist reads need no confirmation. Releasing quarantine and every allowlist write require strict confirmation; discard is an immediate body-erasing triage action. Only a `dispatched` inbound email can be replied to. The platform supplies the subject and thread headers. Success is `status=sent` with `messageId` and `providerEmailId`.\n\nInbox delivery wakes its Agent or starts one active Workflow per accepted email, never both.\n\nReceiving and replying both charge the owner's Arinova credit according to current runtime configuration. Direction matters: an external event entering Arinova is Webhook, data leaving for an external system is Delivery, and Email only receives mail and replies to its sender. Registry policy, the current action result, persisted state, and typed errors override this card.\n",
  "aliases": [
    "email reply",
    "reply to email",
    "inbound email",
    "agent inbox",
    "reply to the sender",
    "回覆郵件",
    "回信",
    "收到的信",
    "信箱"
  ],
  "tags": [
    "email",
    "overview",
    "reply-only"
  ],
  "relatedActions": [
    "arinova.email.list_inbound",
    "arinova.email.get_inbound",
    "arinova.email.reply",
    "arinova.email.update_inbox",
    "arinova.email.list_quarantine",
    "arinova.email.discard_quarantined",
    "arinova.email.release_quarantined",
    "arinova.email.list_sender_allowlist",
    "arinova.email.add_sender_allowlist",
    "arinova.email.update_sender_allowlist",
    "arinova.email.remove_sender_allowlist",
    "arinova.email.get_usage"
  ],
  "relatedActionPrefixes": [],
  "url": "https://docs.arinova.ai/en/kb/email/overview/"
}
---

Email sending is reply-only; there is no compose or send action. The recipient always comes from the trusted inbound-email row, and the reply schema intentionally has no `to` or `recipient` field. If asked to email an arbitrary address, explain that the platform cannot do that. The owner may send it themselves, or register a Delivery endpoint when the real goal is notifying an external system.

The private read actions are `arinova.email.list_inbound` and `arinova.email.get_inbound`. They expose only `dispatched` rows owned by the current Agent; `list_inbound {unread:true}` is the polling path for MCP-only Agents. List snippets and full bodies are framed as untrusted external data, headers are never returned, and only non-sensitive IDs are retained for action replay. General conversation, message, and search actions exclude email threads, so email content must be accessed through these email actions.

An owner creates the inbox. The Agent may read `get_inbox` and `get_usage`; `update_inbox` can pause or resume receiving, change handling guidance, accept all senders, or disable replies only after strict user confirmation. Quarantine and allowlist reads need no confirmation. Releasing quarantine and every allowlist write require strict confirmation; discard is an immediate body-erasing triage action. Only a `dispatched` inbound email can be replied to. The platform supplies the subject and thread headers. Success is `status=sent` with `messageId` and `providerEmailId`.

Inbox delivery wakes its Agent or starts one active Workflow per accepted email, never both.

Receiving and replying both charge the owner's Arinova credit according to current runtime configuration. Direction matters: an external event entering Arinova is Webhook, data leaving for an external system is Delivery, and Email only receives mail and replies to its sender. Registry policy, the current action result, persisted state, and typed errors override this card.