When AI gets multiple inboxes: separate context accounts from action accounts

When AI gets multiple inboxes: separate context accounts from action accounts

The risky moment is not when AI reads a calendar. It is when it mixes up which calendar it read, which account it replies from, and whether the reply should have stayed as a draft.

This is no longer theoretical. Manus now supports multiple Gmail and Google Calendar accounts in the same task and in scheduled tasks. ChatGPT can, for users with connected Gmail or Outlook, draft and send email from inside chat. OpenAI lets workspace admins decide when ChatGPT should ask before actions in connected apps. Claude is adding operational visibility for connectors, and Mistral's public documentation shows beta endpoints for MCP connectors.

Source: Manus, Connect Multiple Gmail and Google Calendar Accounts on Manus

Source: OpenAI, ChatGPT release notes

Source: OpenAI, ChatGPT Enterprise & Edu release notes

The practical point is simple: once AI works inside real accounts, "does the integration work?" is too small a question. Better questions are: which account is AI allowed to read, which account may it act from, and who can see what happened?

Two account types that should stay separate

A context account is an account AI may read to understand the situation. It might be an inbox, calendar, project folder, or CRM view. Reading can still be sensitive, but it does not change anything outside the system.

An action account is the account AI uses when it does something another person will notice. It sends an email, creates a calendar event, updates a ticket, shares a file, or changes a row in a system.

The same person may own both types. The rules should still be different.

Everyday example:

• AI may read "Work Gmail" and "Personal calendar" to find free time.
• It may only create a draft from "Work Gmail".
• The personal account may never be used for sending.
• A client booking stops if the calendar has a conflict, unclear time zone, or more than one possible meeting room.

It sounds fussy. In practice, this is where trust gets built.

The vendor news behind the principle

Manus frames the feature as bringing the right inboxes and calendars into the task, then choosing where Manus acts from. That is a useful product feature. It is also a useful control model: read broadly when needed, act narrowly when the outcome matters.

OpenAI's new app permissions for Enterprise and Edu point in the same direction. Admins can choose whether ChatGPT should always ask, ask for any changes, or ask for "Important actions". OpenAI describes the default as allowing more automatic reading while asking before actions that may have an effect outside ChatGPT, expose sensitive information, or be difficult to undo.

Source: OpenAI, ChatGPT Enterprise & Edu release notes

Claude adds another part of the same picture. Anthropic has launched a public-beta dashboard for published connectors where owners can see active users, tool calls, errors, latency, and usage across Claude, Claude Code, and other surfaces. This is not a general analytics API. It is still a sign that connectors are starting to be treated like small products with owners and operational follow-up.

Source: Claude, Connector Observability and In-App Directory Submission

Mistral's beta connector documentation points in the same direction from the API side. MCP, or Model Context Protocol, is a standard for connecting AI systems to tools and data sources. Mistral's public docs show endpoints for creating connectors, listing tools, getting OAuth URLs, calling connector tools, and managing credentials at organization, workspace, and user level. That does not mean every customer should build custom connectors tomorrow. It means connector boundaries are becoming a business decision, not only a technical setting.

Source: Mistral, beta connectors API reference

Five rules before AI may send or book

1. Name accounts so people understand them

Do not write only "Gmail 1" and "Calendar 2" in instructions. Use names a colleague can review: "Work Gmail", "Client A inbox", "School admin calendar", or "Personal calendar, read only". For scheduled jobs, names matter even more because nobody is sitting there to correct the prompt every Monday morning.

2. Start in draft mode

For email, customer follow-up, student or parent communication, contracts, invoice reminders, and staff planning, the first version should be a draft. Not because AI is useless. Because the cost of the wrong sender or recipient is not worth it.

3. Write the read rule and the action rule separately

A good instruction can be this short:

Read Work Gmail, the Client A inbox, and the Project calendar. Summarize open questions. Create drafts only from Work Gmail. Do not send without approval.

It says what AI may read, what it may produce, and where the boundary is.

4. Require a stop when identity is unclear

AI should pause if two accounts seem valid, the customer has several contacts, a thread contains personal data, the calendar has a conflict, or a booking affects external attendees. The stop rule should be boringly clear: ask the user.

5. Log the decision, not only the result

For every recurring job, you should be able to see which accounts were read, which account was used for a draft or action, whether a human approved it, and why the job paused. This does not need to be a large system. A simple audit note field is often enough at the start.

A simple starting template

If you want to test this without turning it into a big governance project, start with one routine. Weekly planning, customer follow-up, or absence and scheduling information all work.

Write down:

• Which accounts AI may read
• Which accounts AI may never act from
• Which actions always become drafts
• Which actions may happen directly
• Which situations stop the job
• Where the log goes
• Who owns the rule when the workflow changes

This is often a better first Tool Forge or Mindset Forge task than building another demo. Once the account boundaries are on paper, safe automation gets much easier.