AgenticMail — studied and declined; and how EVE becomes customer service

Consolidates three docs into this one (agenticmail-study-2026-10-19, agenticmail-eve-study, agenticmail-collab-record). Young, 2026-10-19: "Do we needed for EVE package?" and "How do we optimise EVE to become customer service in front-end and backend for working through orders and messaging — replacing the email need."

Part 1 answers the AgenticMail question. Part 2 answers the EVE question, which is the more important one.

Part 1 — AgenticMail: no, and here is the licence finding

1.1 What it is

Verified from the repo (2026-10-19): MIT licence on the AgenticMail code itself, 239★, created 2026-02-14, active (pushed 2026-10-18), TypeScript. Its description: "Email, SMS & phone-call infrastructure for AI agents."1

Its architecture:2 bootstrap installs Colima + Docker, starts the Stalwart mail server in a container, generates a master key, registers a systemd/launchd unit, and provisions a default agent. The default install is local-only (agents mail each other at *@localhost); external relay and SMS are deliberately skipped because they need user-owned credentials.

The genuinely good part — its security posture: an outbound guard blocks every agent-composed external email into a pending queue where only the master-key holder (the human owner) can approve or reject — agents structurally cannot self-approve. Plus inbound spam/phishing scoring, DKIM/SPF/DMARC auto-setup, and rate limiting.

1.2 🔴 New finding: the bundled mail server is not MIT

This is the licence risk that neither earlier doc caught, and it is decisive for a resold product.

AgenticMail's own docker-compose.yml pins image: stalwartlabs/stalwart:v0.15.5.2 Stalwart is dual-licensed under AGPL-3.0 and the proprietary Stalwart Enterprise License v2 (SELv2) — not MIT.[3]4

Why this matters to us specifically. AGPL-3.0's defining obligation is that offering the software over a network triggers the requirement to offer the corresponding source to users. We would be running Stalwart as part of a paid multi-tenant service. SELv2 is the vendor's answer — a paid subscription per mailbox tier, with the licence key "bound to the domain name".3

So the honest position is: bundling AgenticMail would pull an AGPL/proprietary mail server into a commercial tenancy product. That is a licence review and likely a paid subscription — not a free component. Our licence-clean rule (MIT/Apache only) fails here.

1.3 The other reasons not to bundle it

1. It duplicates a layer EVE already ships. eve's own integrations gallery lists first-party/official channels for email (Resend, Gmail, Novu), SMS and voice (Twilio — "SMS and speech-transcribed calls"), WhatsApp, Telegram, and six iMessage/SMS providers (Linq, Sendblue, Blooio, Photon, Dial, AgentPhone).6 Adopting AgenticMail would add a parallel implementation of channels we already carry — the duplication defect class our architecture doc exists to remove.
2. It duplicates the mailbox we sell. Our offer already includes the tenant's O365 mailbox. Bundling Stalwart means running a second mail estate per tenant (container + SQLite + dispatcher + relay chain) to duplicate a capability we sell.
3. Pre-1.0 churn. Created 2026-02, one active maintainer, rapid tag cadence. Not "runs a customer's business" grade like Medusa.
4. Version/registry drift (verified). GitHub tags reach v0.9.103,2 the README documents 0.9.54, but the npm latest dist-tag is 0.8.20.5 Three different "current" versions is a release-hygiene signal worth noting before depending on it.
5. Its SECURITY.md is stale — it declares "Supported: 0.2.x" while the product ships 0.9.x. Treat its security posture as unverified, despite the guard design reading as sound.

1.4 Verdict and what we take

Do not bundle. Do not adopt. Take three design ideas, no code:

Named trigger for re-evaluation: if a tenant asks for inbound email or voice, re-evaluate as a component behind an eve channel — not as a parallel stack, and with the Stalwart licence question answered first.

Part 2 — EVE as customer service, front-end and back-end

Young's question: "How do we optimise EVE to become customer service in front-end and backend for working through orders and messaging — replacing the email need."

The answer is an architecture we already have the parts for. EVE becomes the conversation layer; Medusa becomes the action layer; and the "email need" is replaced by in-app messaging plus a customer account — with email demoted from the channel to a notification.

2.1 The three-plane design

   FRONT-END (customer)                    BACK-END (tenant staff)
   ────────────────────                    ──────────────────────
   EVE Web Chat channel                    EVE drafts → pending queue
   (eve.dev/integrations)                  (the AgenticMail pattern, in Medusa)
        │                                        │
        │  session principal = customer          │  human approves
        ▼                                        ▼
   ┌──────────────────────────────────────────────────────┐
   │              MEDUSA  (the action layer)              │
   │  Store API (customer-scoped, JWT/cookie session)     │
   │  Order module: returns · edits · exchanges · claims  │
   │  Notification module: in-app feed + email            │
   └──────────────────────────────────────────────────────┘

Why this shape: EVE already separates conversation from action — a channel "converts incoming messages into agent input, maps each platform conversation to an eve session, and decides how, where, and whether to deliver replies."11 Medusa already owns the order lifecycle. We are wiring two layers that each already do their job, not building a third.

2.2 Front-end — the customer talks to EVE, EVE acts on the order

What Medusa already exposes to a customer-scoped session:8

• Authentication — JWT bearer or cookie session, obtained via POST /auth/customer/emailpass.8
• Store API — customer-scoped endpoints; a publishable API key identifies the sales channel.8
• Order module — the full CS action set: "Returns, Edits, Exchanges, and Claims: make changes to an order to edit, return, or exchange its items, with version-based control over the order's timeline."7 Plus draft orders, promotion adjustments, and tax lines.

So EVE's front-end tool set is thin and well-defined — four tools against the Store API:

The critical design rule: EVE must never take a customer id as a parameter. The order must be resolved from the session principal, not from what the user types. An agent that accepts "show me order #1234" will happily show a stranger's order — this is the same "authorisation is not in the caller" defect our own store had. Bind identity at the channel, resolve orders from the bound principal.

That is what eve's auth/route-protection and audience model is for: a channel "supplies the session principal", and each session is classified public / private / unknown, with unknown as the safe default.11 Customer conversations must be private.

2.3 Back-end — staff work the queue, not the inbox

The back-end is where "replacing the email need" actually lands. Today a customer emails, a human reads it, and a human types a reply. The replacement:

1. EVE drafts, a human approves. Every AI-composed message to a customer — order update, return confirmation, reply — rests in a pending queue until the owner approves. This is the AgenticMail outbound-guard pattern, and it needs no new infrastructure: the queue is a small module in Medusa, which we already run.
2. The conversation lives in the product, not in a mailbox. The customer's thread is an in-app message thread attached to their account and their order. Nothing to forward, nothing to file, no "please reply above this line".
3. Email becomes a notification, not a channel. Medusa's Notification Module already supports this: a notification goes to a channel, and the module's providers declare which channels they serve.10 Our default for the pilot is the feed channel (in-app) — and email only for the messages that genuinely must leave the building (receipt, shipping confirmation, password reset).
4. One queue, one owner. Returns, exchanges and claims all arrive in the same operator queue as messages — so the Nuxt operator console has one work surface instead of an inbox plus an admin panel.

2.4 The two controls that make this safe

This is where EVE-as-CS either is sellable or is not.

Control 1 — the HIL gate (F7), extended to messaging. The existing rule is that every write terminates at the Admin API behind human approval. Extend it to outbound messages: an AI-composed customer message is a write to a customer, and it gets the same gate. Nothing an agent drafts reaches a customer without a human.

Control 2 — fresh MFA on elevated actions. Medusa's requireMfa: { maxAgeSeconds } demands a recent MFA challenge for sensitive operations.2fa-and-account-management A refund or a large claim approval should require it — so an approval given hours ago in a stolen session does not authorise money movement.

Together: the agent cannot act alone, and the human cannot act on a stale session. Two independent controls on one boundary — which is what makes an AI-staff tier defensible to a tenant.

2.5 What this changes in the package

On "replacing the email need" — be precise in the pitch. We are not removing email; we are removing the inbox as the customer-service workflow. Email still carries receipts and shipping notices (and O365 is still a product line). What disappears is "customer emails → staff reads → staff replies" as the support process. That is a defensible claim; "we replace email" is not.

2.6 The order of work (Sol's lane)

1. Bind identity at the channel — customer session principal → private audience. Everything else is unsafe without this.
2. Four read/act tools against the Store API, customer-scoped.
3. The pending-queue module in Medusa + the operator approve surface in Nuxt.
4. Switch the notification default to feed for CS traffic; keep email for transactional.
5. Prove the gate: a MUST-FAIL test that an unapproved agent message cannot reach a customer, and that a customer cannot read another customer's order.

Step 5 is the one that matters — it is the same discipline as F7: a capability with no probe is not a deliverable.

Honest limits

• I read the repo, README, docker-compose, npm registry, Stalwart's licence files, eve's integration gallery and channel docs, and Medusa's Store API / Order / Notification module docs. I did not install AgenticMail, and I did not test any eve channel or build the queue — the design in Part 2 is a design, not a build.
• The Stalwart licence conclusion is from the licence files and README, not from legal review. AGPL-over-network obligations are a real question and deserve a lawyer's eye before anyone ships a bundled mail server.
• I did not measure the Stalwart container's memory footprint (Tam flagged this as the number worth checking before pricing). I have removed the cost claim rather than guess at it — the licence finding makes the resource number moot for now.
• The claim that eve's Twilio/Resend channels work in our deployment is unverified — it is eve's own documentation.6
• Part 2's tool list is my reading of the Store API surface; Sol owns the final spec, and the customer-scoping rule needs a real cross-customer test, not a doc.

Sources

1 https://github.com/agenticmail/agenticmail — AgenticMail — repo (MIT) 2 https://raw.githubusercontent.com/agenticmail/agenticmail/main/docker-compose.yml — AgenticMail — docker-compose (bundles Stalwart v0.15.5) 3 https://github.com/stalwartlabs/stalwart — Stalwart — repo (AGPL-3.0 / SELv2 dual licence) 4 https://raw.githubusercontent.com/stalwartlabs/stalwart/main/README.md — Stalwart — README (licence section) 5 https://www.npmjs.com/package/agenticmail — AgenticMail — npm (latest 0.8.20) 6 https://eve.dev/integrations — eve — Integrations gallery 7 https://docs.medusajs.com/resources/commerce-modules/order — Medusa — Order Module (returns, edits, exchanges, claims, versioning) 8 https://docs.medusajs.com/api/store — Medusa — Store API (customer-scoped) 10 https://docs.medusajs.com/resources/infrastructure-modules/notification — Medusa — Notification Module (channel-based providers) 11 https://eve.dev/docs/channels/overview — eve — Channels overview (session principal, audience, turnPolicy)

2.7 (Tam) — Training EVE before it serves: the validation curriculum

Young, 2026-10-19: "we need to train EVE about security and validation of order, customer ... and more before serving the customer." Agreed — the agent is only as safe as its operational curriculum. The gates EVE must pass BEFORE customer traffic, each with a MUST-FAIL probe (the F7 discipline — a capability with no probe is not a deliverable):

Training method = system-prompt curriculum + the probes as automated regression, run on every EVE template release before customer enablement. Not a one-off doc — it is the release gate.

2.8 (Tam) — Notification-module wiring,verified detail

Verified tonight against Medusa v2 docs (resources/infrastructure-modules/notification): the module is a channel + provider registry — notifications are sent by (channel, provider) pairs and the passive feed channel name appears in the docs surface. Wiring recommendation:

• Channel taxonomy: feed (in-app; the CS default) | email | reserved sms.
• Email provider: rides the tenant's own O365 via Graph/SMTP credentials (tenant-scoped, stored on the tenant record) — receipts, shipping, password resets. Never a fleet-run mail server (see Part 1's licence finding for why).
• SMS: deferred to the Twilio family when a customer demands it (Mira's cost rule stands — avoid by default).
• One queue feeds all channels: the pending-queue module's approved payload passes its channel at send time, so the SAME approval can send feed and email simultaneously — one HILL gate, multiple delivery lanes.

2.9 (Tam) — Young's new canvas: EVE as a product beyond CS

"we can optimise it to create products such as Marketing, Social Media Management onto Medusa." The Medusa ground for that already exists (verified in v2 docs tonight):

• Promotion module — discount + campaign + budget primitives (resources/commerce-modules/promotion): the data model for marketing campaigns.
• Sales Channel module — omnichannel distribution (per channel/product scoping): the primitive for multi-surface selling (storefront, social shop, marketplace).

EVE products that grow from the SAME queue architecture (no new control surface):

All four go through the SAME pending-queue + HIL gate — one control surface, four product faces. That is the reuse payoff of building the queue once.