primitive.dev vs. Mailgun
Different layers of the stack. Claims below are cited to Mailgun’s own pages, read 2026-07-08.
Mailgun is transactional email infrastructure for applications: “send emails from your application and automatically trigger transactional emails,” over a REST API and SMTP, priced by monthly volume.[1] It is built for application transactional sending at volume. primitive.dev is built for the other actor: it gives an autonomous agentits own email identity, owns the full mail stack end to end (inbound MX through outbound) tuned for an agent’s interactive round-trip, and resolves a two-way conversation — rather than sending mail on behalf of your app.
1. An identity the agent owns, not an app sender
With Mailgun your application sends from domains you verify — the app is the sender. primitive.dev issues the agent its own receivable *.primitive.email address with one API call (inbound MX, SPF, DKIM, DMARC, and bounce handling managed), or a custom domain. The agent is the mailbox owner and can be reached, not just heard from.
2. A two-way conversation in one call
Mailgun has robust inbound routing and parsing,[2] but a request/reply round-trip is yours to assemble: send, receive a parsed webhook, correlate the thread, wait. primitive.dev collapses that into one verb — primitive chat <email> <message> sends and returns the threaded reply in a single call — which is the shape an agent actually needs.
3. Agent-native surface: Functions, MCP, in-agent UI
Beyond send/parse, primitive.dev runs hosted Functions on every inbound message, exposes a hosted MCP server with an in-agent email-console App — a published ChatGPT app that also renders in Claude and other MCP-compatible clients — ships durable Memories, and offers a credential-free demo plus zero-touch agent signup. Mailgun is application email infrastructure; primitive.dev is agent email infrastructure.
At a glance
| Dimension | primitive.dev | Mailgun |
|---|---|---|
| Built for | An agent’s own email identity | Application transactional sending[1] |
| Managed address the agent owns | Yes | No — you send from your domains |
| Inbound | Runs your code (Functions) | Routing & parsing to your webhook[2] |
| Send + get the reply in one call | Yes — primitive chat | Assemble from send + inbound |
| MCP + in-agent App UI | Yes | Not the product focus |
Beyond the address: the whole platform
Mailgun moves an application’s mail at volume. primitive.dev is the platform an agent runs on:
- Hosted Functions — your JavaScript runs on every inbound email, server-side, with nothing to host or keep online.
- Programmable routing & filters — route
bugs@to a triage Function andsupport@to a webhook, by rule, with sender allow/block lists. - Primitive Memories — durable JSON state an agent and its Functions keep across turns, retries, and restarts, without bringing a database.
- Agent templates — install a ready-made agent from the template gallery (like a summarizer that replies with a summary of whatever you forward it) and run it as a hosted Function in one step.
- In-agent MCP App — an email console published as a ChatGPT app that also renders in Claude and other MCP-compatible clients, plus a public docs MCP and Node, Python, and Go SDKs.
- Payments over email — agents charge and pay each other in USDC, non-custodially, over x402 (early access), and buy usage pay-as-you-go over the Agentic Commerce Protocol.
Which to choose
Choose Mailgun when an application needs to push transactional email at volume — that is what it is built for. Choose primitive.dev when an agent needs its own address, has to receive and reply in a thread, and you want to run code on inbound mail. See the category guide or the developer resources.
Sources
Competitor claims reflect Mailgun's public pages as read on 2026-07-08; products change — check the originals.