Answer Box: Voice agents that promise to email customers after a call often fail to deliver because they lack their own mailbox. Nylas's Agent Account feature gives each voice agent a real, replyable email address, enabling automated follow-ups and threaded conversations without human intervention.
The broken promise in voice AI
Every voice agent demo ends the same way: the bot says it will email the details, the customer hangs up satisfied, and nothing sends. The transcript sits in the voice stack, the email is a TODO that was never wired up, and the customer waits for a message that never arrives. This is the most common broken promise in conversational AI, and it breaks for a boring reason: the voice agent has no mailbox of its own.
The real challenge isn't speech — voice stacks already handle transcripts, turn-taking, and summaries. The hard part is bridging channels: turning what happened on the call into a written, replyable email that comes from the agent and whose replies come back to the agent. Voice in, email out, reply back in. No human in the loop, no shared support inbox, no spoofed noreply@.
Why a real mailbox beats fire-and-forget
Most teams use a transactional email API like SendGrid or SES to fire a templated summary into the void. That works until the customer replies. Their reply hits a black hole (noreply@) or lands in some shared support@ inbox where it's divorced from the call it answers. The agent that made the promise never sees the answer.
A Nylas Agent Account is a real, owned email address that your voice agent sends from and receives at. It has a grant_id that works with every grant-scoped endpoint Nylas already exposes — Messages, Drafts, Threads, Folders, Webhooks. There's nothing new to learn on the data plane: if you've ever sent a message or listed a mailbox with Nylas, you already know the API. What the Agent Account adds is that the address is real and yours. The follow-up comes from a replyable sender like assistant@yourcompany.com, with your domain and DKIM signature. The customer can hit Reply and reach the agent. The reply lands in the agent's own mailbox and fires a standard message.created webhook, so your code sees inbound mail instantly and can route it back to the same conversation. The whole exchange is one thread — send, reply, send again — a real email conversation with history, not disconnected one-shot blasts.
Provisioning the agent's mailbox
You need three things: the Nylas CLI (installable via Homebrew on macOS or Linux), a Nylas API key (nylas init creates an account and mints one), and a domain for the sender. For prototyping, Nylas hands out trial *.nylas.email subdomains, so you can create assistant@your-app.nylas.email immediately. For production, register your own domain like assistant.yourcompany.com, publish the DNS records Nylas gives you, and let it warm over roughly four weeks of gradually rising volume.
Provisioning the mailbox is one line: `nylas agent account create assistant@assistant.yourcompany.com --name "Acme Assistant"`. The --name sets the display name so the customer sees Acme Assistant <assistant@assistant.yourcompany.com>. The command prints the new grant's id — save that, it's the handle for every send and read. Under the hood, the CLI calls POST /v3/connect/custom with provider: "nylas". The "provider": "nylas" marks this as an Agent Account rather than an OAuth grant. Provision once per agent identity and store the grant ID wherever your service reads config.
Sending the post-call follow-up
When the call ends, your voice stack hands you a summary and confirmation number. Turning that into an email is one command. The body accepts HTML, so you can ship a readable confirmation instead of a wall of text: `nylas email send assistant@assistant.yourcompany.com --to customer@example.com --subject "Your appointment is confirmed — Tue Jun 30, 2:00 PM" --body "<p>Thanks for calling, Jordan. As we discussed, you're booked for <b>Tue Jun 30 at 2:00 PM</b>.</p><p>Confirmation #AC-4821. Reply to this email if you need to change anything and I'll take care of it.</p>" --yes`. The --yes skips the interactive prompt, which is non-negotiable for unattended runs.
The same send over HTTP is POST /v3/grants/{grant_id}/messages/send. The response includes the sent message's id and its thread_id. Persist both against the call record in your own database. Agent Accounts don't support custom metadata, so the join between call and email thread lives in your DB. Keep call and follow-up state on your side; treat Nylas as the transport layer.