Introducing /email: Send and receive email from any AI agent

Today we're launching /email — the primitive that gives an AI Employee a real, sending- and receiving-capable email address. DKIM, SPF, and DMARC configured the moment a /domain is attached. Inbound mail surfaces as runtime objects the agent can read. Every send carries a structured reason the deliverability layer enforces.

The problem: most agent-sent email lands in spam

Email is the most-used primitive in any autonomous business. It's also the easiest to do wrong. The status quo:

• An agent sending from a personal Gmail with no DKIM — flagged within hours.
• An agent sending from raw Resend, Postmark, or SendGrid — works, but you've now got a SMTP integration, a reputation problem, and no agent-native primitives like inbox routing or reason logging.
• An agent sending from a shared "ops@" alias — every reply lands in the same inbox; nothing scopes to the Employee that sent it.

Deliverability isn't a software problem. It's an identity problem. Gmail's filters care less about the SMTP server than about whether the sending identity has a reputation. If your fleet of Employees all share one alias, you have one identity. If each Employee has its own address bound to a real Company, you have ten identities — and the reputation of each is yours to grow.

Until now. With /email, every Employee gets a provisioned address, every domain gets correct DNS automatically, and every send is bound to an Employee whose reputation accrues independently.

How /email works

The workflow is three steps:

1. Provision — every /kyc-verified Employee in a Company gets an email address by default. Send from a Naïve-managed domain or attach your own via /domain.
2. Send / Receive — the Employee calls send_email, list_inbox, get_email_body, schedule_email, or cancel_scheduled_email through its scoped API key.
3. Compose — pair with /research for outbound that cites real sources, or /brand for sender names and signature blocks bound to the Company's identity.

Custom domains in one call

The thing that makes agent email work is correct DNS. With a Company-attached domain via /domain, Naïve auto-publishes:

• A DKIM key (rotated monthly)
• A SPF record listing only Naïve sender IPs
• A DMARC policy starting at p=none and tightening to p=reject as reputation accrues
• Inbound MX records pointed at the Naïve mail engine

Cloudflare is the backing DNS, so propagation is fast and updates are atomic.

naive domains connect lumenletters.com
# DKIM, SPF, DMARC, MX configured automatically

You don't ever copy DNS records into a registrar UI. The Employee can send from editor@lumenletters.com the moment DNS propagates (typically minutes).

Two ways to send email: prompt or code

1. Natural language

naive email send \
  --from-inbox <inbox_uuid> \
  --to "alex@example.com" \
  --subject "Autonomous newsletter pilot" \
  --body "Hi Alex, I wanted to reach out about our autonomous newsletter pilot..."

The CLI sends from the specified inbox.

2. Code

const res = await fetch("https://api.usenaive.ai/v1/email/send", {
  method: "POST",
  headers: {
    "Authorization": `Bearer ${process.env.NAIVE_API_KEY}`,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    inbox_id: "inbox-uuid",
    to: "alex@example.com",
    subject: "Quick question on autonomous newsletters",
    body: "Hi Alex,\nI'm the editor at Lumen Letters...",
  }),
});
const { message_id } = await res.json();

The send is scoped to an inbox. The message_id is logged on the Employee, exposed in deliverability monitoring, and queryable in the dashboard.

Read inbound, schedule outbound, triage at scale

The primitive ships with the full email lifecycle:

# Triage the inbox
naive email inbox

# Read a specific message
naive email read <message_id>

# Send a scheduled email (schedule via the API)
curl -X POST https://api.usenaive.ai/v1/email/send \
  -H "Authorization: Bearer $NAIVE_KEY" \
  -H "Content-Type: application/json" \
  -d '{"inbox_id":"inbox-uuid","to":"alex@example.com","subject":"Following up","body":"..."}'

Inbound mail surfaces in the same runtime model as every other primitive output: structured objects, queryable by Employee, with full body lazy-loaded so context windows don't fill up on the inbox listing alone.

Deliverability monitoring, built in

Every Employee has a sender reputation score that updates in near-real-time based on Postmaster signals from Google, Yahoo, and Microsoft. When a reputation degrades, the runtime warns before the next send and offers to throttle or pause.

When a reputation degrades, the runtime warns before the next send and offers to throttle or pause the Employee. This is what stops a misaligned agent from cratering the entire domain's reputation — the runtime sees the dip, slows the Employee, and surfaces the issue to an operator before it becomes a deliverability incident.

What you can build with /email

Run agent-native cold outbound at deliverability-safe volume — One Employee per persona, each with its own address and reputation. Compose with /research so outbound emails cite recent, real signals about the prospect.

Provision a support inbox an agent can actually triage — Inbound emails to support@yourcompany.com surface as runtime objects. The support Employee classifies, replies, and escalates — every action logged, every reply carrying a reason.

Build an autonomous newsletter business — Pair /email with /brand and /research to publish, cite, and reply. The newsletter Employee owns its address, its reputation, and its readers.

Route 2FA and verification codes correctly — Pair /email with /credentials so 2FA codes sent to the Employee's address auto-route to the Employee that requested them — never cross-contaminating other agents in the Company.

Audit every send your fleet makes — The structured reason field on every send is the audit log. You can answer "why did agent X send this email" without re-running the agent loop.

Get started

• Read the docs: usenaive.ai/docs/guides/email
• Connect a domain: usenaive.ai/docs/guides/domains
• Background reading: Google Postmaster Tools and RFC 7489 (DMARC).
• Quickstart: usenaive.ai/docs/getting-started/quickstart
• Join the community on Discord