Your Dot and Your Inbox: What It Can and Still Cant Do With Email

Email is one of the clearest places to see what OpenAI actually built when it designed dots' permission layer, because email is both genuinely useful for an agent to touch and genuinely risky if it gets something wrong. According to a third-party product guide covering dots' inbox mechanics — not OpenAI's own documentation, so treat the specifics as a cross-checked claim rather than an official spec — the actual behavior sits in a fairly deliberate middle ground: real capability, with real limits that don't go away just because you've approved something once before.

What a dot can do with your inbox

A dot doesn't get its own email address. It uses your connected account — the same inbox you'd check from your phone — which means every email it sends is, mechanically, coming from you. Before anything goes out, OpenAI's Auto-Review process checks the planned action — who it's going to, what it says — against both your standing instructions and your Custom Rules, the same background verification layer we covered when dots first launched. That's not a rubber stamp; it's a check that runs on the specific outgoing message, not a blanket pass granted once and forgotten.

That last point matters more than it might seem: approving one message does not grant ongoing permission for the next one. Each outgoing email gets its own check against your rules, every time. If you want different behavior for email specifically than for, say, calendar actions or file edits, Custom Rules let you set that — per the same guide, there are four settings available per action: act without asking, act only if pre-approved, ask before acting every time, or hand off to you entirely. Email, given its stakes, is a natural candidate for the stricter end of that spectrum even if you've loosened the rules elsewhere.

What a dot still can't do

The background "proactive research" a dot runs — the read-only idle-mode capability we described at launch — stays read-only when it touches your inbox too. A dot can notice a new email arrived, read its contents, and factor that into its ongoing work. It cannot, in that mode, reply, forward, or take any action on what it read. The write side of email only activates under the Auto-Review-gated flow described above, triggered by an actual task, not by background monitoring on its own.

And the standalone-address gap is the structural limit underneath all of this: a dot cannot yet have its own email address independent of your account. Every email a dot sends is legally and practically indistinguishable, from the recipient's side, from an email you sent yourself. That's a meaningful constraint if you were picturing a dot as something closer to a delegate with its own identity in your organization's directory — it isn't that, not yet, and the plugin-and-permissions model described at launch doesn't currently extend to issuing a dot its own mailbox.

A dot borrowing your inbox, with every send checked against your rules, is a very different trust model than a dot having an inbox of its own. OpenAI has built the first one. The second one isn't on the table yet.

Where the Custom Rules settings actually bite on email

It's worth walking through what each of the four Custom Rules settings — act without asking, act only if pre-approved, ask before acting, and hand off to you — would actually look like applied to email specifically, since the abstract categories can obscure how different the lived experience is between them. "Act without asking" on an outgoing email means a dot drafts, Auto-Review clears it against your standing instructions, and it sends — you find out after the fact, if you check the Activity View at all. "Ask before acting" means the same draft exists, but nothing leaves your account until you've explicitly said yes to that specific message, every time, with no accumulated trust from previous approvals carrying forward. For most people, email probably sits somewhere in the middle of that range rather than at either extreme — permissive enough that routine replies don't require constant sign-off, strict enough that anything going to a new recipient, or touching a sensitive topic, gets a human look first.

That configurability is also where the inbox-mechanics guide's framing of dots as personal rather than team agents becomes concrete. Because the rules are set by one account and apply to that account's outgoing mail, there's no mechanism for a colleague to have different Custom Rules apply to the same dot's email behavior — the rules follow the dot's owner, not the recipient or the context of who's asking.

Why this is the right amount of caution for email specifically

Of the capabilities a dot could plausibly have, email access is one of the highest-stakes by nature — it's the surface most directly connected to your reputation and your relationships outside the product. The combination described here — borrowed identity, per-message review, granular rule settings, read-only background access — reads as a reasonably conservative design for that risk level, consistent with the broader permission philosophy OpenAI described at launch. It's also a sensible place for OpenAI to start precisely because email mistakes are hard to take back — an email sent to the wrong recipient, or with the wrong tone, can't be silently edited after the fact the way a draft document can. A permission model that treats every outgoing message as its own decision, rather than extending trust indefinitely from one approval, trades a bit of convenience for a meaningfully lower ceiling on how bad a single mistake can be.

The next article in this batch looks at the flip side of that same constraint: what the lack of a standalone dot identity rules out when it comes to team, rather than personal, email use.

Part 35 of 47 in the ChatGPT Dots series. Previously: iOS Widgets and Shortcuts: Opening Your Dot Without Opening ChatGPT. Next: No Standalone Email Address Yet: The Gap Between a Dot and a Coworker. Browse more builder insights or explore AI skills at aiskill.market.