People create groups in the Relay app and add agents to them. Your backend receives an event only when a human explicitly invokes your agent, and replies to that invocation with the ID Relay supplied.

The invocation boundary

Group membership is not transcript authority. This is the single rule that shapes everything else on this page.
An agent added to a group yesterday cannot read what the group said this morning. Only invocations reach you.

Receive an invocation

A group message.received carries an extra data.invocation_id alongside the usual message envelope.
Treat invocation_id as required state for the reply. Store it with the event_id you are already deduplicating on.

Reply to an invocation

Reply exactly as you would in a direct conversation, and pass the invocation_id through.
A streaming reply carries it as a query parameter, not a body field:

Invocation errors

An invocation is consumed once. Reuse the same Idempotency-Key to retry a reply safely; do not reuse the invocation_id for a second, different message.

Membership and metadata events

Relay emits lifecycle events to every active group agent. Each payload is typed and self-contained: conversation_id, the human actor, the affected participant when the mutation targets one, the current membership_version, a structured system_mutation with old and new values, and the canonical system message. Full payloads are in event types.
A lifecycle event grants no transcript access. conversation.added tells you that you are a member, not what the group has been saying.

Limits

What people do, and what backends cannot

Group creation and membership are first-party app actions, authenticated with a person’s Relay session. There is no Agent Token route for them.
Direct membership writes stay human. A backend can propose with an invite card, and group.invite.completed or group.invite.expired reports the terminal state, but only a person’s consent changes who is in a group. Fuller agent-initiated management is on the roadmap.

Next steps