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

Dimensionprimitive.devMailgun
Built forAn agent’s own email identityApplication transactional sending[1]
Managed address the agent ownsYesNo — you send from your domains
InboundRuns your code (Functions)Routing & parsing to your webhook[2]
Send + get the reply in one callYes — primitive chatAssemble from send + inbound
MCP + in-agent App UIYesNot 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 and support@ 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.

  1. Mailgun — Email API ("send emails from your application, trigger transactional emails")
  2. Mailgun — inbound email routing & parsing