AI clients assume a flat life: each connector is added once, with a single identity. Personal brand and job search, work for CodyVal and Hookie, and hobby or group projects need different identities for the same connector. A personal Gmail and a work Gmail are both Gmail. Browser profiles and Slack workspaces already separate those contexts but the AI clients I use still don't.
The client stores one slot per connector type and marks it connected for the whole user. That matches someone who really has one account of each. It breaks when the same connector has to carry more than one identity.
The connector type is the wrong unit of access
What I actually need:
- a personal Gmail and a work Gmail
- the same GitHub MCP servers in each context, without a personal chat seeing work repos and vice-versa
- calendars that belong to different contexts
- and the same pattern applies to any connector with per-context identity.
Gmail is two separate accounts. GitHub is one account having access to multiple organizations. I still don't want a personal chat to see CodyVal or Hookie by default. Same connector type, different question: which grant, and which repos that grant can reach. Once every connection is simply "available," I cannot tell which account or which repos a call will use, and neither can the agent.
Repo isolation does not exist in consumer apps
When I work in a codebase, Claude Code and Cursor let me attach MCPs and other tools per repository, so one repo's tools stay out of another's. Consumer apps do not offer the same isolation.
Claude Desktop has projects, and Grok Bot can spin a second agent, but both only isolate instructions, files, and memory. MCP servers stay in one pool, so every project and every agent sees the same connectors; each connector is still one identity, and the grant is account-wide whether I add a custom MCP in chat or connect a marketplace plugin.
The consumer space has no good answer
When the host has one shared pool, I only connect my personal MCPs and handle work or hobby by hand. I stay out of a mix-up by leaving the other identities disconnected, not because the product isolates them.
Executor can take those tools off the host through its toolkit, but it is a niche product for people already in this bubble, and account connectors like Gmail are still clumsier there than in Claude Desktop.
A profile is the right unit of ownership
Two named Gmail connectors in one pool would still share chats and memory. The unit I want is a built-in profile, the way browsers already do it: it owns the MCP connectors, chats, and memory.
I connect each identity on the profile it belongs to, and the OAuth grant stays there. If the personal profile reuses the work grant, both can act as the work account; a GitHub grant that can see every org has the same leak. Inside a profile, agents share those connectors, chats, and memory, so I connect an identity once and a second agent can use it and continue a chat the first one started.
I mocked this in a Claude Design prototype where the rail switches between Personal, Work and Hobbies.
Work owns the work Gmail, GitHub with work visibility (hookie-sh/cli, CodyVal/*), and Linear, while Personal owns a personal Gmail and GitHub with personal visibility. Both GitHub connections are the same user but with different repo access. Release and Docs are two agents on Work, so they share those accounts without a second sign-in.
I am still one person across profiles, so name, timezone, and writing style can live in a global layer. Connectors, memories, and instructions stay on the profile that owns them unless I mark them shared. Each context keeps its own tools and history; I can switch without leaking work into personal, and without rebuilding the things that should follow me.
- Agents
- Developer Tools
- Product Engineering
- MCP
