---
name: channel-routing
description: Messaging conventions and channel routing rules. Reply in current session auto-routes to the source channel; cross-session messaging via sessions_send; sub-agent orchestration via subagents tool; system message handling. Never use exec/curl for provider messaging — Symi handles routing internally.
triggers:
  [message, messaging, channel, route, routing, send, sessions_send, subagent, system-message]
---

# Channel Routing — messaging conventions

## Where messages go

- **Reply in current session** → automatically routes to the source channel (Signal, Telegram, Slack, etc.). Just respond — Symi delivers it.
- **Cross-session messaging** → use `sessions_send(sessionKey, message)` to deliver to another session/sub-agent.
- **Sub-agent orchestration** → use `subagents(action=list|steer|kill)` for managing spawned sub-agent runs from the current requester session.

## System messages

`[System Message] ...` blocks in your input are **internal context** — they are not user-visible by default.

If a `[System Message]` reports completed cron/sub-agent work and asks for a user update, **rewrite it in your normal assistant voice** and send that update. Do NOT:

- Forward the raw system text verbatim.
- Default to `NO_REPLY` just because the trigger came from a cron/sub-agent.

The user expects a normal-sounding update; the System Message is just telling you what to update them about.

## What NOT to do

- **Never use `exec`/`curl` for provider messaging.** Symi handles all routing internally — invoking external HTTP calls bypasses delivery accounting, dedupe, and channel-specific formatting.
- Don't include channel-specific protocol headers (Slack Block Kit JSON, Telegram parse_mode strings) in your text body unless explicitly using the `message` tool with the right `channel` parameter.
- Don't `sessions_send` to your own session — just respond normally.

## When to use `message` vs respond directly

- **Just respond** when delivering the user's reply in the current conversation. The runtime routes it.
- **Use the `message` tool** when:
  - Sending proactively to a different recipient or channel.
  - Sending a non-text payload (poll, reaction, file).
  - Targeting a specific channel when multiple channels are configured.
  - You also use `message` to deliver the user-visible reply: in that case respond with ONLY `NO_REPLY` afterward to avoid double-delivery.

See the `message` tool's own description for the full parameter reference and channel-specific options.
