A shared inbox where the agent drafts and humans approve from Outlook is a powerful hybrid — and it's the part of "AI email" that most demos quietly skip.
Most "AI email" demos point a model at a human's personal inbox: connect a Gmail grant, summarize threads, maybe auto-draft a reply that nobody actually trusts enough to send. That's fine for a personal assistant. It falls apart the moment you want the agent to be a participant on a real team mailbox — [email protected] — where five humans and one agent all need to see the same messages, the same folders, and the same draft sitting in the queue.
The naive fix is to give the agent its own service and bolt a UI on top. Now you're building a mail client. You've got a database of "agent state," a sync loop, a permissions layer, and a frontend nobody asked for, all to reimplement what Outlook already does well.
There's a better shape. A Nylas Agent Account is a real mailbox you can drive two ways at once: the agent works it over the API, and your humans work it from their normal mail client over IMAP/SMTP. Both surfaces read and write the same storage. A draft the agent creates via the API shows up in the Drafts folder in Apple Mail. A message a human drags into "Needs review" in Outlook shows up in the API's folders field within seconds. That bidirectional sync is the whole trick, and it's what makes genuine human+agent collaboration possible instead of two systems fighting over one inbox.
I work on the Nylas CLI, so the terminal commands below are the exact ones I reach for when I'm wiring this up. Every step shows the raw curl call and the nylas equivalent, because you'll want the API in your service and the CLI on your laptop.
What you actually get
An Agent Account is just a grant — the same grant_id abstraction you already use for every other Nylas mailbox. Nothing new to learn on the data plane:
Agent side (API): Messages, Drafts, Folders, Threads, Attachments, Webhooks — every grant-scoped endpoint works exactly as it does for a Gmail or Microsoft grant.
Human side (IMAP/SMTP): Outlook, Apple Mail, Thunderbird connect with the account email and an app password. People work the mailbox the way they always have.
Shared state: flags, folder moves, drafts, and sends propagate across both surfaces and fire the same webhooks, no matter which side initiated them.
The model is: the agent triages and drafts, a human reviews and approves from the comfort of their mail client, and the queue between them is just a folder both sides can see.
Why this beats building your own review UI
- You don't write a mail client. Outlook is the review UI. Humans approve drafts where they already live.
- The agent doesn't poll a side-channel. It gets
message.createdwebhooks for inbound mail and reads/writes the real mailbox. - There's one source of truth. No reconciliation between "agent's view" and "human's view" — it's literally one mailbox.
- It degrades gracefully. If your agent service is down, the humans still have a fully working mailbox. If a human is on vacation, the agent still triages.
One honest caveat up front, because it matters for how you scope this: this is not a multi-user ACL system. There's one app password for the mailbox, and everyone who connects a client shares it. You can't grant Alice read-only and Bob send. If you need per-person permissions, that lives in your application layer in front of the API, not in the shared inbox. I'll come back to the security tradeoff at the end.
Before you begin
You need:
- A Nylas application and API key.
- A registered sending domain — either your own custom domain or a Nylas
*.nylas.emailtrial subdomain. New domains warm over roughly four weeks, so don't provision one the morning of a launch. - An email address on that domain for the inbox, e.g.
[email protected].
The API base host in these examples is https://api.us.nylas.com (use the EU host if your app is in the EU region), and every request authenticates with Authorization: Bearer <NYLAS_API_KEY>.
If this is your first Agent Account, read the — the full IMAP/SMTP reference, the folder mapping, and the sync table.
— provisioning, policies, rules, and the rest of the data plane.
SOCIAL SHARE CARD GENERATOR