A rate limit on your API protects you from your users. A send limit on your email agent protects everyone else from your agent.
That asymmetry is why quota design deserves more thought than "set it high enough that we never hit it." An autonomous sender with an LLM in the loop has failure modes a human sender doesn't: retry storms that resend the same message, classification bugs that reply to mailer-daemons, a prompt-injected instruction that turns your agent into someone's spam cannon. The quota is the blast-radius control for all of them.
The defaults, and what they're for
On Nylas Agent Accounts (a beta feature), the cap is 200 messages per account per day on the free plan; paid plans have no daily cap by default. A stricter per-account quota can be set through a policy — policies bundle daily send quotas alongside storage, retention, and attachment limits, and attach to a workspace so every account in it inherits the same ceiling. Every limit on a policy is optional; omit one and it defaults to your plan's maximum.
That "stricter" direction is the point. The platform won't let you raise a limit above your plan — only constrain downward. So the design question becomes: what's the lowest quota each agent archetype can live with? A support triage agent answering inbound mail might legitimately need its full volume. A prototype you deployed Friday afternoon should probably be capped at 20. The docs recommend separate workspaces per agent archetype precisely so each group carries its own policy instead of one catch-all.
