One RelayLink account for multiple AI assistants

A RelayLink account represents one person and email identity, not one assistant. Connect several assistants to share correspondence while keeping a separate credential for each door.

4 min read

Claude handles a decision at work, ChatGPT helps from home, and a small agent framework runs a scheduled task. If each connection used a different RelayLink account, you would split one person's contacts, history, and identity across artificial mailboxes.

A RelayLink account represents the person behind one email address. Assistants are clients of that account. Connect several when they all act for the same person.

What every connected assistant shares

All assistants authenticated as the account work with the same:

  • inbox and unread state;
  • conversation threads and package history;
  • accepted contacts, pending requests, blocks, and private nicknames;
  • display name and email identity;
  • drafts stored on the account.

That shared state is the benefit. An assistant at home can continue a thread the work assistant started without copying a transcript. A framework can check the same inbox a hosted assistant checks. A nickname set in the portal is available when either assistant addresses that contact.

It is also an honest boundary. RelayLink does not maintain a private inbox per assistant under one account. When one assistant fetches a package, the account has fetched it. When one assistant changes the account's display name, correspondence from every connection uses that identity.

Ask whoami when you are uncertain which account or RelayLink host a connector is using. The answer should be the same person for every assistant meant to share this workspace.

Give each connection its own door

Shared correspondence does not require shared credentials.

OAuth is available on every RelayLink deployment. Use it when the client can take you through RelayLink sign-in and consent, and approve each application as the account. Use a named API key when a client or configuration cannot complete that browser flow, and issue a separate key for that integration.

Avoid copying one API key into several assistants. Separate credentials let you disconnect or revoke one client without changing the others, and key names plus last-used times help identify what is still active.

The doors remain different:

  • disconnecting an OAuth application ends that application's grants and tokens;
  • revoking a named key ends only that key;
  • neither action automatically closes the other kind of access.

This separation is security isolation, not data isolation. As long as the credentials remain active, the connected assistants act as the same RelayLink account.

Coordinate drafts and sends

Several assistants can read the same threads, so give them a simple operating rule: check current state before continuing old work. Read the thread or draft list again instead of relying on a conversation's memory.

Every assistant-composed package still needs human approval before delivery. The @relaylink shorthand opens a draft; it never sends. Connecting a second assistant does not create a background permission to deliver whatever it composes.

If one assistant prepares a draft and another presents it for approval, inspect the rendered package just as you would in one session. The account boundary preserves who is sending, but it cannot tell which assistant's reasoning you prefer.

Hand work to yourself

Address a package to your own RelayLink email when one assistant should leave structured context for another. The package follows the ordinary draft and approval path, then appears as inbound correspondence in the account's shared inbox.

A self-handoff has one participant: you. It sends no notification email and creates no email reply link, because there is nobody else to notify. The portal inbox and the next assistant's inbox check are how it is picked up.

Until any assistant fetches the latest handoff, the thread is waiting on you. After the fetch, it is idle. That gives the next session a clear signal without pretending you are waiting for another person.

When separate accounts are appropriate

Use another RelayLink account for another person or email identity, not merely for another model. Contacts consent to correspond with an account identity. Combining two people's assistants behind one identity would make authorship and access misleading.

Likewise, if two assistants must not see the same correspondence, one account is the wrong isolation boundary. RelayLink's separate credentials control which clients can enter; they do not partition what an admitted client can see.

For one person moving among assistants, one account keeps the durable context together. Separate doors make each connection removable, while a shared inbox makes the handoff useful.

Frequently asked questions

Do I need a separate RelayLink account for each assistant?
No. One account represents one person and email identity. Claude, ChatGPT, agent frameworks, and other MCP clients can all connect to that same account.
Do connected assistants see the same RelayLink inbox?
Yes. Inbox, unread state, threads, contacts, nicknames, and the account's display identity belong to the account rather than to one assistant.
How do I hand work from one of my assistants to another?
Send a RelayLink package to your own account email. It appears as an unread self-handoff for the account and sends no email notification because there is no other participant.