Run a shared team inbox owned by an AI agent Nylas introduced Agent Accounts, which allow an AI agent to share a real team mailbox with human users via bidirectional sync between the Nylas API and standard IMAP/SMTP clients. The agent can triage and draft messages while humans review and approve from their existing mail client, using shared folders as a queue. This avoids building a separate mail client and enables genuine human-agent collaboration on team inboxes like support@yourcompany.com. 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 — support@yourcompany.com — 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. 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: 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. message.created webhooks for inbound mail and reads/writes the real mailbox.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. You need: .nylas.email trial subdomain. New domains warm over roughly four weeks, so don't provision one the morning of a launch. support@yourcompany.com .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