> ## Documentation Index
> Fetch the complete documentation index at: https://docs.relayapp.im/llms.txt
> Use this file to discover all available pages before exploring further.

# Why Relay

> Why specialized AI agents need a first-party messenger and distribution layer.

Relay exists to make the relationship with useful agents better for people, and
to remove real product work for the developers who operate them. The user is the
first test.

## The relationship is the product

The useful agents in a person's life will come from many products. A coding
agent, researcher, scheduler, fitness coach, finance agent, and personal
assistant can each have different operators, capabilities, data, prices, and
trust boundaries.

Adding each specialist today usually means another app, account, interface,
subscription, notification system, permission model, and isolated history. The
agent can be excellent while the relationship around it is fragmented.

One general assistant reduces that fragmentation and introduces a different
tradeoff.

| Approach              | Cost                                                                                           |
| --------------------- | ---------------------------------------------------------------------------------------------- |
| An app per agent      | Repeated installs, accounts, notifications, and disconnected history                           |
| One general assistant | Specialization becomes a hidden model choice or tool call; the user may not know who is acting |
| Automatic routing     | The router can pick the wrong expert, and operator identity disappears                         |

Relay starts from intentional choice. The agent stays distinct because its
identity and specialization are part of the value.

## Existing channels own the relationship

Putting an agent into Telegram, Discord, Slack, WhatsApp, SMS, RCS, or iMessage
removes an app install, and can be the right answer for reach. The host
platform keeps the relationship: it defines the account, bot identity,
invocation rules, history, permissions, rich output, delivery, discovery,
payments, and enforcement surface.

| Path                                   | Tradeoff                                                                                                                       |
| -------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------ |
| Official bot and business APIs         | Supported, but constrained by the host's contract                                                                              |
| Unofficial personal-account automation | May depend on private interfaces, a linked session, or signed-in hardware. Enforcement or a platform change can break delivery |
| Carrier messaging                      | Real reach, plus consent and opt-out handling, sender setup, filtering, variable delivery, segmentation, and usage-based cost  |

[Compare the alternatives side by side](/alternatives).

## Agent work needs a native grammar

Human chat is optimized for short exchanges between people. Agent work can take
time, wait for approval, stream progress, return structured output, share media,
fail and retry, or finish with a durable result.

Forced into typing indicators, message edits, bot commands, or channel-specific
cards, those states blur. The user cannot tell whether the agent is working,
stuck, waiting, or done, and every developer re-translates the same behavior into
each destination's primitives.

A first-party messenger makes those states one product: familiar conversations,
one canonical transcript, explicit delivery and recovery, typed message parts,
and permissioned native capabilities.

## What Relay changes

<Columns cols={2}>
  <Card title="For the user" icon="user">
    Discover a reviewed agent or open a share link, inspect its operator, add it
    explicitly rather than granting silent inbox access, and message it in a
    durable, recoverable conversation. Working, approval, failure, retry, and
    completion states are legible. Notifications, memory, media, location,
    payments, calls, groups, and cross-agent context stay under per-agent
    control as they ship.
  </Card>

  <Card title="For the developer" icon="code">
    Focus on the brain. Relay owns identity, profiles, conversations, ordering,
    delivery, sync, notifications, media transport, installation, safety, and
    the native client. You own models, prompts, tools, behavior, external
    memory, hosting, availability, and support. Your existing backend adds Relay
    through a versioned REST API and signed webhooks, with no Relay runtime or
    required SDK.
  </Card>
</Columns>

Removal, muting, blocking, reporting, export, and deletion all work without
pretending an independent developer's systems are Relay's database. The
transcript should create continuity, not lock-in.

## The honest bet

Existing networks already have distribution, identity, push, history, payments,
and network effects, and a standalone app can give a flagship agent complete
control. Relay wins by making a many-agent inbox, explicit operator boundaries,
richer agent states, dependable recovery, and reviewed distribution worth a new
messenger.

Proving that starts deliberately small: 20 to 50 invited people, a few
dependable agents, reliable text, streaming finalization, offline recovery,
notifications, removal, blocking, reporting, account deletion, privacy, and
support. Calls, payments, groups, and an open marketplace come after the basic
relationship is trustworthy.

## See also

<Columns cols={3}>
  <Card title="How Relay works" icon="route" href="/how-relay-works">
    The intended user loop and ownership boundary.
  </Card>

  <Card title="Compare your options" icon="scale-balanced" href="/alternatives">
    Where apps, bots, channels, providers, and bridges fit.
  </Card>

  <Card title="Current status" icon="gauge" href="/current-status">
    What is proved today and what the first release gate requires.
  </Card>
</Columns>