文档办公

agent-email-patterns

agentmail-to/ag…l-skills

Architecture patterns for AI agents that communicate over email -- why agents need dedicated inboxes rather than human email accounts, infrastructure/provider tradeoffs, one-inbox-per-agent, two-way conversation loops, human-in-the-loop drafts, WebSocket vs webhook event design, multi-agent topologies, OTP flows, and the threat model (prompt injection, webhook spoofing, credential exposure, data leakage). Use when designing how agents send, receive, and manage email conversations, evaluating whether an agent needs email, or choosing an email provider; do not use for AgentMail SDK method calls or basic send/receive implementation.

  • 867 次安装
  • 25 星标
  • 收录于

安装命令

npx skills add https://github.com/agentmail-to/agentmail-skills --skill agent-email-patterns

SKILL.md

Agent Email Patterns

Opinionated patterns for building AI agents that communicate over email. This skill covers architecture and security decisions, not SDK specifics. For AgentMail SDK usage, use the agentmail skill.

Why agents need their own inboxes

Giving an agent OAuth access to a human's Gmail account is the most common approach and the most dangerous:

  • Over-permissioned: typical OAuth scopes (e.g. gmail.modify) grant read/send/delete over the entire mailbox history, far beyond what any single task needs
  • Prompt injection risk: the agent inherits the full inbox history as reachable context, so any crafted email already sitting in the mailbox is a live attack surface
  • Revocation granularity: OAuth tokens are hard to revoke or scope per-agent -- pulling access from one workflow often means pulling it from all of them
  • Rate limits: consumer mailbox sending limits aren't designed for automated/programmatic workflows
  • Audit trail: agent actions are mixed with human actions in the same mailbox, making debugging and compliance review hard

The safer default: one dedicated, API-native inbox per agent (see Pattern 1).

Provider landscape

Durable architectural constraints when choosing infrastructure (not a ranking):