You are trying to decide who needs to sign in, who must accept whom, and how an email-only recipient differs from a standing contact. The words account, contact, and recipient answer different questions. Product evaluators, integration teams, and account holders need the distinction before they design a workflow around it.
An account is one person's identity
A RelayLink account represents one person using one email address and display name. It owns that person's inbox, threads, contacts, connected assistants, and credentials.
Several assistants may connect to the same account when they all belong to that person. Claude at work, ChatGPT at home, and an agent framework can see the same correspondence because they are acting for the same identity. A briefing to your own address can hand work between them.
An account is not a team mailbox. If several people share it, recipients cannot tell which colleague approved a package because every send has the same account identity. People who need to speak for themselves should use their own accounts.
A contact is an accepted relationship
A contact is not another account stored inside yours. It is an accepted relationship between two account holders.
One person sends a contact request. The other person accepts it; the requester cannot accept their own request. The invitation carries no note, because free text would let an unaccepted sender place content in the other person's account before consent. Inviting a contact opens standing correspondence without merging either side's identity or data.
Blocking is different from simply lacking a contact relationship. It prevents delivery in both directions and does not announce itself to the other person. Unblocking removes the block; it does not restore the former contact relationship. If the two people want standing contact again, they must establish it again.
A recipient is a role in one delivery
A recipient is the person a package is addressed to. That role does not imply an account or a contact.
If the address is not attached to an activated RelayLink account, the person can receive the briefing by email, open its package page, and reply without registering or connecting an assistant. Receiving that package does not give them an authenticated inbox or create a standing contact relationship.
Once that recipient signs in and activates the account, a new thread from the sender requires an accepted contact relationship. A cold-email thread they already participate in can continue, unless either side blocks the other. A refusal is deliberately not an account lookup; do not interpret its wording as confirmation that the address is registered.
Put the terms together
Consider a consultant writing to a client:
- The consultant authenticates as their account.
- The client is the recipient of the package.
- If the client remains unactivated and email-only, they can read and reply without becoming a contact.
- If the client activates an account, the two people need an accepted contact relationship before starting a new thread; their existing cold thread remains open.
The thread remains the conversation. Packages are individual briefings on it. A private nickname is the account holder's addressing label, not the recipient's new name. Allowing the recipient to see that word permits it to appear in assistant-composed correspondence; it does not rename the other account or send a separate announcement.
Where this model fits
This model fits person-to-person correspondence where identity, consent, and the exact approved message matter. It lets one side use an assistant without requiring the other side to adopt RelayLink.
It does not fit a shared support queue where interchangeable staff should all speak as one operational role, or a bulk messaging system that treats recipients as rows in a campaign. RelayLink's account boundary is intentionally personal. Start at the connect page if that is the identity model you need, or read whether every user needs an account for the shortest adoption path.