primitive.dev vs. Gmail (for AI agents)

Gmail is a mailbox for a human. To touch it in code, an agent’s app has to OAuth into a real Google account someone owns — and because Gmail read and modify are restricted scopes and send is a sensitive scope,^[3] that app must pass Google’s OAuth verification either way, and re-verify every year to keep the restricted access.^[2] There is no API that hands an agentits own Gmail identity; you are borrowing a person’s inbox or buying a Workspace seat, under terms written for people. primitive.dev starts the other way around: the agent gets its own address.

1. An identity the agent owns, not a human’s inbox it borrows

A Gmail account belongs to a person and carries their name, history, and consent screens. An autonomous agent has none of that — it is squatting in a human’s mailbox, or you are paying for and managing a seat per agent. primitive.dev issues the agent a receivable *.primitive.email address (or a custom domain) in one call, with inbound MX, SPF, DKIM, DMARC, and bounce handling managed. The agent is the owner.

2. No verification gauntlet, no per-user throttle to design around

Google gates restricted-scope apps behind verification and annual re-assessment,^[2] and meters the API per user — a per-user-per-minute quota budget where a single messages.send costs 100 units.^[1] That model exists to protect individual human mailboxes, not autonomous agents — for an agent that just needs to send and receive, it is pure friction. primitive.dev is built for programmatic use from the first call — a prim_ key from a single unauthenticated request, no consent screen.

3. Agent-native surface Gmail was never meant to be

primitive.dev ships the things an agent actually reaches for: a one-call primitive chat send-and-wait verb, hosted Functions that run your code on every inbound message, a hosted MCP serverwith an in-agent email-console App, and durable Memories. Gmail gives you a REST API over a human’s mailbox — powerful, but not any of those.

At a glance

Beyond the address: the whole platform

A Gmail account gives an agent a place to send and receive — inside a person’s mailbox. primitive.dev gives it a place to operate as itself:

• Hosted Functions — your JavaScript runs on every inbound email, server-side, with nothing to host or keep online.
• Programmable routing & filters — route bugs@ to a triage Function and support@ to a webhook, by rule, with sender allow/block lists.
• Primitive Memories — durable JSON state an agent and its Functions keep across turns, retries, and restarts, without bringing a database.
• Agent templates — install a ready-made agent from the template gallery (like a summarizer that replies with a summary of whatever you forward it) and run it as a hosted Function in one step.
• In-agent MCP App — an email console published as a ChatGPT app that also renders in Claude and other MCP-compatible clients, plus a public docs MCP and Node, Python, and Go SDKs.
• Payments over email — agents charge and pay each other in USDC, non-custodially, over x402 (early access), and buy usage pay-as-you-go over the Agentic Commerce Protocol.

Which to choose

Use the Gmail APIwhen your job is to act on a specific person’s real Gmail — read their mail, send as them, with their consent. Use primitive.dev when the actor is an agent that needs its own email identity, free of a human’s account and Google’s consumer terms. See the category guide or the developer resources.