AgenticMail — do we need it for the EVE package? (2026-10-19)

What it IS (repo verified live: ★239 MIT, TypeScript, active tags through v0.9.103)

AgenticMail = email + SMS + phone-call infrastructure purpose-built for AI agents: runs a bundled Stalwart mail server in Docker (SMTP/IMAP/HTTP), gives each agent a REAL email address (*@localhost local-only mode or external Gmail/domain relay), MCP-server integration (Claude Code/OpenClaw/Codex plugin targets), agent→agent threads for task assignment + synchronous RPC, plus SMS/voice via Google Voice/46elks bridges.

Appeal and the two strong parts

1. Agent-to-agent over real mail threads (threads + RPC + attachments, no custom orchestration) — matching what the fleet DOES (dispatch/ACK/relay) but over SMTP instead of A2A JSON.
2. The security posture is honest: outbound guard (every agent-sent external email BLOCKS first and requires master-key approval), spam/phishing scoring of inbound, DKIM/SPF/DMARC auto-DNS setup, human-only approve/reject flow (agents can NEVER self-approve). The approval model is exactly how a tenant AI staff layer should behave.

The flaws that matter, measured

• Young project, thin band: created 2026-02, 239★, one active maintainer, recent commits mostly dependency bumps (last substantive change Sep-13). Rapid tags (v0.9.x) = pre-1.0 API churn risk. Not yet the "runs a business on it" grade Medusa is.
• Heavy runtime for a light need: Stalwart container + SQLite + PM2 dispatcher + (in full mode) external relay chain = a multi-container estate just to pass mail. For OUR stack we already have M365 (per-tenant O365 is INCLUDED in our offer) — bundling a second mail server would duplicate the mail capability we sell.
• SMS/Voice tier via Google Voice = consumer-account glue, not an API product — that lane is ToS-fragile and not a SaaS-grade building block. Real business SMS (Twilio/Vonage) = paid API lane (Mira's earlier cost note: avoid SMS by default).

Verdict for the 3-in-1 / EVE package: NOT needed in core — selectively borrow ONE pattern

• Do NOT bundle: the mail-server side (we already sell O365; customer mail should ride the tenant's OWN mailbox, not a fleet-run Stalwart instance we have to babysit).
• Borrow the PATTERN, not the product: the outbound-guard + human-approve flow maps one-to-one onto our EVE HIL layer — for any tenant EVE agent that can SEND email/SMS to third parties (receptionist confirming bookings, order updates), the default posture should be EVE drafts the mail → human/owner approves from a pending queue → only then does it leave. Store the queued mail in Medusa (a small module) rather than shipping a second mail server — same control, zero new infra.
• Where real mail-sending IS needed later: tenants already own O365 mailboxes; EVE sends through Graph/the tenant's SMTP creds (scoped per-tenant, keys never leave the tenant) — that lane is cheaper and more credible than embedded Stalwart.
• MCP integration shape is a nice confirmation: AgenticMail validates the same "expose agent capabilities as MCP tools" pattern our EVE agents use — no adoption needed.

One-line reason in the package spec

"EVE staff can be given a mailbox (the tenant's O365), and by default every message an AI staff member composes rests in a pending queue until the owner approves — the same protection AgenticMail sells, wired into the stack we already host."

🎯 Tam's Read: AgenticMail is the right shape of idea (agent-native comms with approval gates) at the wrong layer for us (re-runs mail-server work we already sell as O365); borrow the approval-queue discipline into EVE's HIL design, skip the Stalwart estate, and revisit if a customer ever wants fleet-hosted mailboxes inside the package.