Work and personal are not the same world. The moment an agent can reach both your work mailbox and your personal one, every request carries a question nobody asked out loud: which one did you mean? Tools usually answer it with a current context you switch by hand, which works right up until you forget you switched.
Lanes Link removes the guess. One endpoint serves every profile in a workspace, under one token, and every tool call carries a required profile argument beside connection. There is no current profile and nothing to switch. The caller names which world a call acts within, every time.
How Lanes Link does it
- Profile is a required argument, not a mode. Because it is named per call, there is no ambient state to get wrong and no "which context am I in" to reason about mid-session.
- Two mailboxes stay one tool.
gmail.users.messages.listdoes not fork into a work version and a personal version. Theprofileargument decides which mailbox it reaches. - Crossing is refused, not filtered. Naming a connection from a different profile is rejected before anything is dispatched, so a mistake fails loudly instead of quietly returning the wrong inbox.
- Nothing is shared across the boundary. Profiles share no configuration, no state, and no credentials. Work memory does not surface in a personal session, because it is not the same store.
- One endpoint, still. Separation does not cost you a second deployment or a second token. It is one endpoint serving both.
The workflow
Add a profile per world, connect each world's accounts under its own profile, and let the caller be explicit from then on. When a request is genuinely ambiguous, a well-briefed agent asks you which profile you meant rather than defaulting to whichever is listed first.
The payoff is mostly in what stops happening. A work document does not land in a personal Drive because a context was stale. A personal calendar does not leak into a summary you paste into a work thread. And when you eventually want to hand the work profile to someone else or tear it down, it comes apart cleanly, because it never shared anything with the other one.
Set it up
Profiles are created from the CLI, and the first one becomes your default:
$ bun install -g @lanes-sh/link
$ lanes link profile add personal --default
$ lanes link profile add work
$ lanes link start
ok serving http://127.0.0.1:7337/mcp
profiles: personal, workThen:
- Connect each world separately. Run
lanes link connect gmailonce per profile so each holds its own account. - Register the endpoint.
lanes link mcp addwires it into Claude Code and Codex, and installs a skill that tells the agent to ask when the profile is ambiguous rather than picking one. - Be explicit in the ask. "Search my work mail" is enough for the agent to name the right profile in the call.
Further reading
- Lanes Link: one endpoint for everything an agent needs: profiles, permissions, and the audit log in full.
- Connect your accounts once, for every agent: connecting each world's accounts once.
- Give agents scoped access, with an audit trail: policy per capability, on top of the profile boundary.
- Give every agent the same memory: why separate stores per profile matter as much as separate mailboxes.
Browse the source at lanes-sh/link, Apache-2.0, or read the announcement.