When NOT to Use an Agent Account

Picture a team building a morning-briefing assistant for their sales reps. The pitch: every day at 8 a.m., the agent summarizes each rep's inbox and flags the deals going cold. They provision the agent a shiny mailbox of its own, wire up webhooks, ship it — and every briefing comes back empty. Of course it does. The reps' email never arrives in the agent's mailbox. It was never going to. The agent needed access to a human's inbox, not an identity of its own.

It's a hypothetical, but I'd bet money versions of it have happened. New primitives invite overuse, and agent mailboxes are having a moment. So here's the unfashionable post: when not to use one.

The question that decides it

Is the agent acting as itself, or on behalf of a person? That's the whole fork. An Agent Account — a hosted mailbox the agent owns end-to-end, currently in beta — is for the first case. OAuth grants against a real person's Gmail or Outlook are for the second, and the docs say so plainly.

When the agent should wear a human's identity

The briefing bot above. An assistant that drafts replies for you to send. Anything where the messages must come from a person's address and replies must land in their inbox — because that's where the counterparty expects the conversation to live.

For this, you connect the human's account and let the agent operate it. The share-your-email guide shows the CLI version, where the agent drives a connected inbox with structured JSON output:

nylas email list --unread --limit 10 --json
nylas email send --to "[e-mail]" \
  --subject "Re: Server outage" \
  --body "Looking into this now." --yes

Messages go out from the user's own address; replies return to the user's inbox. The triage loop the docs sketch runs entirely on this model: list unread messages, read the important ones in full, classify with the LLM, reply to the urgent ones, mark the rest as read. Search even runs on the provider's native syntax — Gmail search operators, Microsoft KQL — so queries like from:[e-mail] or has:attachment subject:invoice work exactly as the user would type them.

If your agent stack speaks Model Context Protocol, nylas mcp install registers the same operations as typed tools — and there are 85+ CLI guides covering variations. None of this involves an agent identity, and none of it should.

A useful smell: if the words "on behalf of" appear anywhere in your spec, you probably want a connected grant, not an agent mailbox.

When bulk marketing should stay on marketing tools

The other counter-case is volume without conversation. Newsletters, promo blasts, product announcements to 50,000 subscribers — the value there lives in campaign tooling: template management, A/B tests, list hygiene, unsubscribe compliance, aggregate analytics. That's what ESPs and marketing platforms are for, and a mailbox-shaped primitive doesn't compete with them.

The numbers agree. The free plan's send quota is 200 messages per account per day — sized for an agent holding real conversations, not a broadcast channel. Even the migration guide for moving off transactional providers says you don't have to replace them entirely: keep the blast pipe for receipts and marketing, and use an agent mailbox specifically where replies carry signal.

The gray zone: one product, both forks

Most real products end up needing both, and the seam between them is worth drawing deliberately.

Take a customer-support product. The assistant that drafts replies inside a rep's inbox — reading their threads, proposing responses they send under their own name — is connected-grant territory, full stop. But the same product's [e-mail] address, the one that receives every inbound ticket directly and runs triage rules before a human ever looks? That's an Agent Account, because no human's mailbox is the source of truth for that address.

Or take a voice agent on support calls. When it sends reset instructions or a meeting recap the moment the caller asks, it sends from its own [e-mail] address — and the reply returns through the same account, so the whole exchange is one thread in one mailbox the agent owns. That's the agent acting as itself. If the recap instead had to come from the account executive's address, you'd be back on a connected grant.

The good news is that picking both isn't an architecture tax. An Agent Account is just another grant under the hood — same grant_id contract, same Messages, Threads, and Webhooks endpoints — so one codebase runs both forks through the same code path and branches on the grant's provider field ("nylas") when it matters.

When it's actually the right call

For symmetry, the cases that do fit: system mailboxes your app owns outright (support@, scheduling@) with no human to OAuth against; ephemeral inboxes provisioned per test run and torn down after; per-customer identities in a multi-tenant product, each with its own quota and reputation; and any agent that needs to receive and act on replies as itself, in its own threads, on its own calendar.

The pattern across all four: the identity belongs to software, the conversation is two-way, and no human's mailbox is the source of truth.

A 30-second decision check

Three questions before you provision anything:

1. Whose name is on the message? A person's → connected grant. The system's → agent mailbox.
2. Where must replies land? A human's inbox → connected grant. The agent's own thread → agent mailbox.
3. Is it a conversation or a broadcast? Broadcast at scale → marketing/transactional tooling. Conversation → agent mailbox.

Honest accounting matters more with new primitives, not less — the failure mode isn't that agent mailboxes don't work, it's that they work just well enough to hide an architecture mistake for a month.

Run your current agent project through the three questions above. If you land on "agent mailbox" for all three, the overview is the place to start — and if you've already shipped the wrong fork and lived to refactor it, I'd genuinely like to hear that story.