Building Inboxer for both Gmail and Outlook took longer than the single-provider version we shipped first. Not because Outlook is worse — Microsoft Graph is a respectable API — but because the two platforms expose fundamentally different mental models. Anyone evaluating an AI email assistant in 2026 should know where those differences leak into the product, because they affect what your AI can and can't do.

Labels versus categories versus folders

Gmail's organizational primitive is the label: a string you attach to a thread. One thread can carry many labels. Removing a label doesn't move the thread anywhere — it just removes the tag. Archive is the absence of the INBOX label.

Outlook's primitive is the folder: a thread lives in exactly one folder at a time. Archive is moving to the Archive folder. Separately, Outlook also has Categories, which are coloured tags that behave more like Gmail labels — but most users don't know they exist, and the filter views work differently.

For AI classification, this matters: a tool built on Gmail labels can apply "1 - To Respond" as a label without disturbing the user's folder structure. The same tool on Outlook has to pick: do we use Categories (which the user has to learn about) or Folders (which moves the thread out of view)? We landed on Categories with the exact same naming as our Gmail labels, so the UX feels identical across providers.

Threading and conversation grouping

Gmail aggressively groups messages into threads — sometimes too aggressively. Five emails with the same subject from different people end up in one thread even if they're unrelated. Outlook's conversation grouping is stricter (it uses the In-Reply-To header more faithfully) but it can be disabled by the user. When it's off, every message shows up as its own row.

The implication for AI: classification accuracy depends on having the full thread context. A reply to "Confirming our 3pm Tuesday?" means nothing without the original. Gmail's aggressive threading helps the model. Outlook with conversation view off forces the AI to reconstruct threads from headers, which is possible but adds latency.

Snooze, defer, follow-up

Gmail has a native Snooze action: remove from inbox until X. The model can detect a SNOOZED label and skip the thread until it returns.

Outlook has no equivalent label. The closest thing is the "Follow up" flag with a start date and a due date. We use flag.flagStatus === "flagged" with a future date as the snooze proxy, and skip classification on flagged threads. That works for the common case but doesn't cover users who use Outlook's actual "Snooze" menu action — which moves the message to a hidden state that the Graph v1.0 API doesn't expose cleanly.

Webhooks and push notifications

Gmail's push notifications go through Google Pub/Sub. You register a watch, Gmail pushes to your topic, your service consumes. Watches expire after 7 days and must be renewed.

Microsoft Graph uses a subscription model: you POST to /subscriptions with a resource path and a notification URL, Microsoft hits your URL. Subscriptions expire after ~3 days for mail. The renewal logic is symmetric.

The hidden cost on Microsoft: webhooks are delivered via Svix, which uses a specific signature format (svix-id.svix-timestamp.body, HMAC-SHA256 with the base64-decoded secret, ±5 minute replay window). If you implement webhook verification assuming Stripe-style or Gmail-style signing, every webhook gets rejected with a 401 and you spend a debug session figuring out why. (We know.)

Draft creation and sending

Both providers expose draft create + send. Gmail's drafts have their own resource (/drafts) and need messages.modify for label updates, because threads.modify doesn't propagate to drafts. Microsoft's drafts ARE messages — they live in the /Drafts folder and are PATCHable like any message.

Net for AI: drafting a reply is API-equivalent across the two providers. The Inboxer code abstracts both behind a single EmailConnector.createDraft() interface; the consumer doesn't need to know which provider is underneath.

Voice profile data: sent items

To learn how a user writes, the AI needs access to their sent history. Both providers expose this:

Gmail: users.messages.list?q=in:sent
Microsoft Graph: /me/mailFolders/SentItems/messages

Same payload size, same parsing. Voice profile building runs identically on both. If you connect Inboxer to Gmail and the same person's Outlook, you'd get the same voice profile.

The dedupe-labels problem

Here's a quirky one. Gmail's "Conversation view" setting changes how labels render in filtered views. With it OFF (a ~30% power-user choice), filtering by label shows one row per message instead of one per conversation. So if a thread has 5 messages all labelled "5 - FYI", the user sees the same conversation 5 times. Inboxer ships a daily cron that strips duplicate labels down to just the latest message of each thread, specifically to fix this.

Outlook's category filter doesn't have this behaviour. One thread = one row, always. So the dedupe job is Gmail-only. Worth knowing if you ever migrate.

Should you choose your email provider based on AI support?

Honestly, no. Both Gmail and Outlook can host the same AI assistant in 2026 with effectively identical functionality, because the provider-level differences are abstracted away by tools like Inboxer. Pick the email client you actually like using. The AI layer rides on top either way.

The one exception: if you're on a corporate Microsoft 365 tenant where IT has disabled third-party Graph subscriptions, you can't get real-time push notifications and will fall back to polling. That makes the AI feel ~30 seconds slower per inbound email. It's a real difference but rarely a deal-breaker.