Combining Remote Control, Dispatch, and Channels — Practical Patterns
Three composable patterns cover the majority of scenarios that genuinely require combining Remote Control, Dispatch, and Channels: the monitored long-run, the CI response pipeline, and the team agent queue. Each pattern combines specific primitives for specific reasons — not by default.
Quick Reference
- →Monitored long-run: Remote Control to start, Channels to observe, Remote Control to steer
- →CI response pipeline: Routine triggers Dispatch → Channels streams diagnostic → Dispatch chains fix job
- →Team agent queue: shared Dispatch queue + Channels to shared Discord + Remote Control for any member to steer
- →Start with simplest primitive — add layers only when the task requires each layer
- →Over-engineering the notification stack adds operational overhead without proportional value
- →Remote Control alone handles most 'check on session' cases — add Dispatch and Channels for specific needs
- →Document why each layer was added — forces intentional composition
Why Combine? The Three Scenarios That Justify It
Most sessions don't need all three layers. Remote Control alone handles 'I want to check on my session from another device.' Channels alone handles 'I want my team to see what Claude is doing.' Dispatch alone handles 'I want to queue work asynchronously.' You add a second or third layer when the task has requirements that genuinely need it.
Three patterns represent the real-world scenarios where combining all three layers produces value that none alone provides: the monitored long-run (one engineer, long task, needs to be present but mobile), the CI response pipeline (automated trigger → automated response → human oversight at decision points), and the team agent queue (multiple engineers, shared workload, collective visibility).
Every layer you add is another thing that can fail, expire, or need maintenance. A Channels integration that sends events to a Discord webhook adds: one webhook URL to maintain, one connection to keep authenticated, and one failure mode (webhook rate limiting, Discord downtime) that can silently drop events. Add layers for specific, justified reasons — not because they sound useful.
| Pattern | Why Remote Control | Why Dispatch | Why Channels |
|---|---|---|---|
| Monitored Long-Run | Start on workstation, steer from mobile when Channels shows wrong direction | Not needed — one task, one session | Passive observation while mobile — know when to act |
| CI Response Pipeline | Optional — review diagnostic before approving fix | Async job chaining: diagnostic → fix → verify | Stream pipeline status to team Discord so everyone sees outcomes |
| Team Agent Queue | Any team member can observe/redirect any running job | Shared queue for multiple engineers' submissions | Shared Discord gives all team members visibility into all jobs |