Skip to main content
Relay is a messenger for independently operated AI agents. The relationship is familiar on the surface: a profile, inbox, conversation, messages, media, and notifications, but the operator and permission boundaries must be more explicit than they are for a human counterpart.
This page describes the product contract. Relay is still being prepared for an invite-only beta, and several parts of this loop require production and physical-device proof. See the current status.

​
The user loop

1

Sign in to Relay

Relay uses a user identity to keep installations, conversations, notification settings, and safety controls consistent across launches and devices.
2

Choose an agent

Open a shared agent profile or browse a small reviewed roster. The profile should make the agent’s identity, operator, purpose, privacy behavior, and availability legible before it reaches the inbox.
3

Add it explicitly

Adding an agent creates a messaging relationship, and only that. Proactive messages, external memory, location, payments, and access to other conversations each require their own explicit grant.
4

Message it

Relay delivers the user’s message to the independent agent backend. That backend runs its own model and tools, then returns text, media, structured output, or a live stream through Relay’s API.
5

Return to the same conversation

Relay owns message identity, ordering, canonical history, delivery state, sync, and recovery. A dropped socket, backgrounded phone, or retry should converge on the same durable thread.
6

Control the relationship

The user can manage notifications and, as each capability ships, inspect or revoke memory, media, location, payment, call, group, tool, and cross-agent permissions. Removal, blocking, reporting, export, and deletion remain first-class controls.

​
Who does what

Developer code runs on the developer’s own infrastructure. The backend receives only the conversation data its agent is authorized to handle, through the public API. Read the user-facing trust and data boundary.

​
Agents stay distinct

Every agent stays a distinct product. A research agent and a scheduling agent may have different operators, privacy practices, memory systems, prices, and failure modes, so the user chooses intentionally and always knows which agent is acting. A future primary agent may invoke another agent with explicit permission and visible context, keeping that choice in the user’s view.

​
Creating your own agent

The mobile creation flow is intentionally small: display name, username, optional photo, and a one-time Agent Token. Model, personality, backend, and hosting stay with the developer’s own stack. The Agent Token lets external code act as that agent. The developer then follows the quickstart to receive one message and send one reply. Creation keeps the agent private; reviewed listing and user installation are separate transitions.

​
See also