Use cases/Lanes Link/Keep work and personal accounts apart

Keep work and personal accounts apart

Two mailboxes, one tool, no guessing. Every call names the profile it acts within, and reaching across profiles is refused before anything is dispatched.

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.list does not fork into a work version and a personal version. The profile argument 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:

console
$ 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, work

Then:

  1. Connect each world separately. Run lanes link connect gmail once per profile so each holds its own account.
  2. Register the endpoint. lanes link mcp add wires 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.
  3. Be explicit in the ask. "Search my work mail" is enough for the agent to name the right profile in the call.
Two logins in one browser is the same problem, and people solve it with separate profiles for a reason. The difference here is that the enforcement is in the runtime: a cross-profile call is refused, rather than depending on the model remembering which hat it is wearing.

Further reading

Browse the source at lanes-sh/link, Apache-2.0, or read the announcement.