Build vs buy agent email infrastructure by responsibility.

Split the stack before comparing products

Agent email contains at least four layers. Transport accepts and delivers messages. Mailbox state maps messages to identities, threads, search, and retention. Tooling exposes bounded operations to software actors. Workflow policy decides which content can cause which external action. Vendors stop at different layers.

A sending provider may own deliverability but not the agent's mailbox identity. An inbound parse webhook may deliver JSON but not retain a queryable conversation. An agent inbox SaaS may own both product and runtime. An open-source application may provide the behavior while leaving every production operation with your team.

Draw these layers and assign an owner before evaluating feature lists. Otherwise, the team can mistake source availability for low operating cost or mistake a parse webhook for a complete mailbox product.

Choose a managed product when operations are not a differentiator

A managed service can shorten the path to production by absorbing deployment, scaling, storage availability, product upgrades, and support. Managed sending platforms also operate infrastructure and reputation systems that are difficult to reproduce responsibly. For a small team, that transfer of work can be worth more than source access.

Buying does not transfer every responsibility. The customer still owns credential distribution, user authorization, prompt-injection defenses, content retention choices, action policy, application observability, and incident coordination. Review current contracts, data handling, export paths, quotas, support, and shutdown behavior rather than assuming SaaS removes risk.

• Buy when launch speed and vendor operation outweigh custom policy.
• Verify the exact mailbox, event, attachment, and sending capabilities needed.
• Keep provider credentials scoped and outside model context.
• Design export and replacement paths before the data becomes critical.

Choose open source when control is a requirement the team will operate

Self-hosted mails0 runs the application in the operator's Cloudflare account using Workers, D1, R2, and Email Routing. The team can inspect and modify identity, storage, limits, extraction, webhook, and lifecycle behavior. It can use its own domain and decide how policy fits existing platform systems.

That control creates a release and incident surface. The team must manage Cloudflare resources, DNS, migrations, secrets, R2 objects, retention jobs, rate limits, abuse controls, outbound provider configuration, logs, alerts, rollback, and security updates. Free infrastructure allowance does not make engineering and operational work free.

Self-host when those controls are material to product, compliance, data, or architecture and the team can name the owner. Do not self-host only because the repository is available.

Build from cloud components only when mailbox semantics are product-specific

Cloudflare Email Routing, Cloudflare Email Sending, Amazon SES receipt rules, provider parse webhooks, object storage, databases, queues, and functions can be assembled into a custom system. This is appropriate when the product has unusual tenant, routing, compliance, message-state, or integration requirements that an inbox product cannot represent.

The hidden work includes MIME parsing, attachment safety, thread reconstruction, search, idempotency, tenant authorization, credential recovery, retention, event retries, tooling, dashboards, and migrations. Estimate these as product features and ongoing operations, not a one-time webhook handler.

Own the application layer and buy delivery when that boundary is stable

A common architecture self-hosts mailbox identity and state while delegating outbound delivery to a provider. This keeps source, data, domain behavior, and agent tools under application control without attempting to reproduce sender reputation and global delivery operations.

Keep the provider adapter explicit. Record send request, provider acceptance, delivery events, inbox placement when observable, and recipient action separately. For inbound, document whether Cloudflare routing, a provider parse webhook, or another service is authoritative. A hybrid reduces some work but still needs an integrated incident model.

Sources and product scope

Product behavior is verified against the mails0 source and documentation. External comparisons link to official vendor documentation checked on 2026-08-15.

Related implementation paths