arizuko

arizuko › howto › Asymmetric channels

asymmetric channels

Ingest signal from one or more channels into a folder's memory without the agent replying there. The agent reads everything that lands; it speaks only on the channel you nominated. Useful when one source is high-volume context (a busy WhatsApp group, an RSS firehose, a mirrored mailing list) and another is the actual conversation surface.

the mechanism: target fragment

The routes.target column carries an optional #mode URI fragment that decides what routd does after the message lands in the folder:

targeteffect
folderstore under folder and fire a turn (default)
folder#observestore under folder, do not fire a turn. The message is visible to the agent in history on the next trigger turn.

One folder, two routes, two effects. The agent's ACL is folder-scoped — observed messages are fully readable. The mode is routd's contract about when to invoke the agent, nothing about visibility.

recipe

Two routes against the same folder, one in each mode:

seq  match                                       target
10   platform=<reply-channel> chat=<your-jid>     myfolder
20   platform=<ingest-channel> room=<src-jid>     myfolder#observe
  1. Decide which channel speaks. Pick the one the user is actively conversing on — their phone, their team's Slack, their Telegram DM. That's the trigger route, no fragment.
  2. Decide which channels feed. Anything else the agent should know about but not reply on. Each gets a route to the same folder with #observe.
  3. Put the trigger route first. Lower seq wins. The first match wins, so a trigger route for a specific chat must be above any catch-all observe route on a broader pattern.
  4. Tune the context window if needed. The trigger turn folds the trailing OBSERVE_WINDOW_MESSAGES (default 10) / OBSERVE_WINDOW_CHARS (default 4000) of observed history into the prompt. For busy ingest channels, raise either at the instance level or per-route via routes.observe_window_messages / routes.observe_window_chars.

worked example: Telegram talks, WhatsApp listens

seq  match                                       target
10   platform=telegram chat=user/5229089286      rhias/nemo
20   platform=whatsapp room=420735544891@…       rhias/nemo#observe

The team converses on Telegram. WhatsApp messages from the named group land in the rhias/nemo folder as <observed> entries; the agent never replies on WhatsApp. When something from WhatsApp matters, the agent posts to Telegram with a one-line attribution.

This was first deployed as “Nemo” under the reality product — the agent holds context across both channels without forking the conversation. The reality page treats it as a case study; this page is the generic recipe.

defence in depth (optional)

The route mode is the platform-level enforcement: routd will not schedule a turn for an observed message, full stop. If you want a second layer the agent itself acknowledges, drop a soft rule into the folder’s CLAUDE.md:

## Channels

Reply on Telegram only. Never call `send_message` targeting WhatsApp,
even if a tool result tempts you to. Observed WhatsApp posts inform
context; the response goes on Telegram.

With the route mode in place this rule is redundant by construction — useful as documentation, not as a guardrail.

extending the pattern

One inbound bus, one outbound channel:

The constraint is on the folder, not the channel: any number of #observe routes can converge on one folder. Each route is just another row in the table.

go deeper

Edit this page · updated