Source: https://cli.nylas.com/guides/connect-agent-gmail-and-outlook # Connect an Agent to Gmail and Outlook Give one AI agent a single inbox view across Gmail and Outlook. Connect both mailboxes over OAuth and read, search, and send with the same CLI commands. Written by [Pouya Sanooei](https://cli.nylas.com/authors/pouya-sanooei) Software Engineer Updated June 14, 2026 > **TL;DR:** Connect both mailboxes with `nylas auth login --provider google` and `--provider microsoft`. Each becomes a grant; the agent reaches either one by passing the grant ID to `nylas email list`. Two providers, one command surface, no per-provider SDK. ## How does one AI agent read both Gmail and Outlook? One agent reads both providers by holding two grants — one for Gmail, one for Outlook — and targeting each with the same command. A grant is a single connected mailbox; once both are connected, the agent passes a grant ID to choose which inbox a command runs against. The CLI normalizes Gmail and Microsoft 365 behind one interface, so the agent's code never branches on provider. One AI agent holds two grants — a Gmail grant and an Outlook grant — and reaches each with the same commands by passing the grant IDOne agentsame commandsGmail grantgrant_googOutlook grantgrant_msft That is the whole trick: two grants, one set of commands. Without it, an agent that spans both providers needs Google's Gmail API and Microsoft's Graph API — two REST surfaces, two auth models, two SDKs. Here the only thing that changes between inboxes is the grant ID you pass. ## How do you connect both mailboxes? Run the login command once per provider. The `nylas auth login --provider` flag opens the consent flow for Google or Microsoft, and each completed login adds a grant. After both, list the grants to capture their IDs — you'll pass these to every later command. ```bash # Connect Gmail, then connect Outlook — one consent flow each nylas auth login --provider google nylas auth login --provider microsoft # Capture both grant IDs nylas auth list --json ``` Each grant stores its own OAuth tokens, and a Google access token expires after 3,600 seconds, so the CLI refreshes each one independently before it lapses. The agent never re-prompts for either provider once both grants exist. ## How does the agent read across both inboxes? Target one grant at a time by passing its ID as the first argument, and loop over the two IDs to cover both inboxes. The agent calls the identical `nylas email list` command for Gmail and Outlook, changing only which grant it points at. Two calls give a single, merged view of everything unread across both providers. ```bash # Read each inbox by grant ID — same command, different grant nylas email list grant_goog --unread --json nylas email list grant_msft --unread --json ``` For an agent that mostly works one inbox, set a default grant with `nylas auth switch` and drop the flag until it needs the other one. Either way, the agent loops two grant IDs to read 100% of its mail across the two providers. ## How do you send from the right account? Switch the active account to the right grant, then send. The `nylas auth switch` command points every following command at that mailbox, so `nylas email send` goes out from its address. One agent can hold up to 5 connected inboxes on the free tier, so a single switch picks the right sender among them. Replying from the inbox a thread arrived in keeps the conversation on the right identity — a customer who emailed your Outlook address gets a reply from Outlook, not Gmail. ```bash # Switch to the Outlook grant, then send from that account nylas auth switch grant_msft nylas email send \ --to customer@example.com \ --subject "Re: your ticket" \ --body "Following up from our support inbox." ``` ## Why is one CLI better than the Gmail API plus Graph API? Spanning Gmail and Outlook natively means integrating two separate REST APIs: Google's [Gmail API](https://developers.google.com/gmail/api/guides) and Microsoft's [Graph mail API](https://learn.microsoft.com/en-us/graph/api/resources/mail-api-overview). They use different field names, different pagination, and different message models, so an agent built on both carries two code paths for every action. Both providers still authenticate with the OAuth 2.0 framework from [RFC 6749](https://datatracker.ietf.org/doc/html/rfc6749), but the resource APIs above it diverge. Collapsing them to one command surface means the agent has a single set of tools to learn and one place to handle errors — the difference between two integrations and one. ## Next steps - [Agent Account vs Delegated OAuth](https://cli.nylas.com/guides/agent-account-vs-delegated-oauth) — whether each mailbox should be a connected grant or the agent's own inbox - [Email APIs for AI Agents Compared](https://cli.nylas.com/guides/email-apis-for-ai-agents-compared) — how the one-command-surface model stacks up against direct provider APIs - [Revoke an AI Agent's Email Access](https://cli.nylas.com/guides/revoke-user-email-access-agent) — disconnect either grant cleanly when a user offboards - [Full command reference](https://cli.nylas.com/docs/commands) — every `nylas email` and `nylas auth` subcommand ## Try Nylas CLI Install the CLI with `curl -fsSL https://cli.nylas.com/install.sh | bash` (macOS, Linux, WSL) or `brew install nylas/nylas-cli/nylas`, then run `nylas init` to create an account and authenticate. **Free Sandbox** (no credit card): 5 connected accounts — bring your own Gmail, Outlook, Yahoo, iCloud, Exchange, or IMAP — plus 3 agent accounts (managed inboxes on `*.nylas.email`). Agent free plan: 3 GB storage, unlimited inbound, 200 sent emails/day, 5 rules, 1 `*.nylas.email` subdomain, and unlimited custom domains. Production is uncapped and requires a credit card: https://www.nylas.com/pricing/