let5see/clawdbot
1
0
Fork 0
Code Issues Pull Requests Actions 4 Packages Projects Releases Wiki Activity
Files
ad5c87c19336d5ce5d75f2fed1df1082af6534be
clawdbot/docs/concepts/provider-routing.md
Peter Steinberger 80112433a5 fix(telegram): support forum topics 
Co-authored-by: Daniel Griesser <HazAT@users.noreply.github.com>
Co-authored-by: Nacho Iacovino <nachoiacovino@users.noreply.github.com>
Co-authored-by: Randy Ventures <RandyVentures@users.noreply.github.com>
2026-01-07 02:19:42 +00:00

1.9 KiB
Raw Blame History

summary, read_when
summary read_when
Routing rules per provider (WhatsApp, Telegram, Discord, web) and shared context
Changing provider routing or inbox behavior

Providers & Routing

Updated: 2026-01-06

Goal: deterministic replies per provider, while supporting multi-agent + multi-account routing.

  • Provider: provider label (whatsapp, webchat, telegram, discord, signal, imessage, …). Routing is fixed: replies go back to the origin provider; the model doesn’t choose.
  • AccountId: provider account instance (e.g. WhatsApp account "default" vs "work"). Not every provider supports multi-account yet.
  • AgentId: one isolated “brain” (workspace + per-agent agentDir + per-agent session store).
  • Reply context: inbound replies include ReplyToId, ReplyToBody, and ReplyToSender, and the quoted context is appended to Body as a [Replying to ...] block.
  • Canonical direct session (per agent): direct chats collapse to agent:<agentId>:<mainKey> (default main). Groups/channels stay isolated per agent:
    • group: agent:<agentId>:<provider>:group:<id>
    • channel/room: agent:<agentId>:<provider>:channel:<id>
    • Telegram forum topics: agent:<agentId>:telegram:group:<chatId>:topic:<threadId>
  • Session store: per-agent store lives under ~/.clawdbot/agents/<agentId>/sessions/sessions.json (override via session.store with {agentId} templating). JSONL transcripts live next to it.
  • WebChat: attaches to the selected agent’s main session (so desktop reflects cross-provider history for that agent).
  • Implementation hints:
    • Set Provider + AccountId in each ingress.
    • Route inbound to an agent via routing.bindings (match on provider, accountId, plus optional peer/guild/team).
    • Keep routing deterministic: originate → same provider. Use the gateway WebSocket for sends; avoid side channels.
    • Do not let the agent emit “send to X” decisions; keep that policy in the host code.
Reference in New Issue View Git Blame Copy Permalink