Multi-Channel Notifications and Routing

One of the most powerful and underappreciated capabilities of the Hermes + NanoClaw stack is the ability to route messages intelligently across multiple channels. A single NanoClaw task can read from one source (an API, a file, a database), decide which channel is most appropriate for the notification, and deliver a formatted message specifically suited to that channel's conventions. Why channel routing matters: different communication contexts have different norms and appropriate message formats. A quick operational alert belongs in WhatsApp or Telegram. A detailed analysis report belongs in a Slack channel where it can be threaded. A client-facing update belongs in the client's communication channel. A personal reminder belongs in your private chat with the assistant. Routing intelligently means the right person sees the right information in the right place, rather than routing everything to one channel and creating noise. The target_group_jid parameter in schedule_task is how you direct a task's output to a specific group. You can schedule a task from the main control group that delivers its output to a different registered group — for example, a daily standup summary generated in your main group but posted to your team Slack channel. For notification tasks specifically, the send_message tool allows the agent to push a message immediately during execution rather than waiting for the task to complete. This is useful for multi-step tasks where you want a quick status update sent early, with a more detailed follow-up sent when processing is complete. 'Checking now...' followed by the actual results 30 seconds later, rather than silence for 30 seconds followed by everything at once.

Unfiltered notifications are noise. The design principle for any notification system — and this is especially true when you're building one powered by an AI agent — is: only interrupt when interruption is justified. Everything else should be available on demand, not pushed proactively. The NanoClaw script field is your notification filter. Before any notification is sent, the script evaluates whether the condition for interruption has been met. The quality of this script is the quality of your notification system. A good notification script answers: has something actually changed since the last run? Is this change above the threshold of significance that warrants interruption? Is this the right time to deliver this notification (respecting Do Not Disturb hours, timezone awareness)? Timezone-aware notifications are especially important for multi-channel setups. If you have a team across time zones, or if your monitoring covers international data sources, build time awareness into your scripts. A simple check: 'const hour = new Date().getHours(); if (hour < 8 || hour > 22) return { wakeAgent: false };' prevents the agent from notifying you at 3am about a non-urgent condition. Notification categories and their appropriate channels: Urgent operational alerts (system down, critical threshold crossed) → WhatsApp or Telegram personal chat, immediate delivery, brevity over formatting. Informational digests (daily summaries, weekly reports) → Slack channel or Telegram group, formatted, can be longer. Action required (someone needs a response, a decision is needed) → wherever that person is most responsive, personally addressed. Background completed (a long-running task finished) → wherever you asked for it, simple confirmation plus summary. A notification system that respects these categories, routes appropriately, and filters aggressively will be used and trusted. One that over-notifies will be muted within a week.