# Multi-agent routing: binding never routes to secondary agent, always falls back to default (main) | Friends of the Crustacean 🦞🤝 | Page 1

static meteorBOT Feb 13, 2026, 7:03 AM

#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

snow dewBOT Feb 13, 2026, 7:08 AM

#

Your binding doesn’t match because Discord guild text channels are peer.kind: "channel", not "group".

"group" is used for things like WhatsApp/Telegram groups (and Discord group DMs), but a server channel routes as discord:channel:<id>, so the router expects:

match.peer.kind: "channel"
match.peer.id: "<channelId>"

Per the config reference, match.peer is { kind: dm|group|channel, id }, and peer-matches are the highest-precedence tier; if the peer doesn’t match, it falls back to the default agent (main).
Docs: https://docs.openclaw.ai/gateway/configuration#multi-agent-routing-agentslist--bindings

Fix

{
  "bindings": [
    {
      "agentId": "sentry",

#

      "match": {
        "channel": "discord",
        "accountId": "sentry",
        "peer": { "kind": "channel", "id": "1471763703467610123" }
      }
    }
  ]
}

Two quick sanity checks (because this bites people)

accountId must match your channels.discord.accounts key (not the bot’s display name). If you’re not using channels.discord.accounts and only set channels.discord.token / DISCORD_BOT_TOKEN, then the inbound accountId is effectively the default account — in that case either remove accountId from the binding or set it to the default account id you actually have.
Make sure there isn’t an earlier binding that wins first in the same tier. Peer-tier is highest, but order still matters within a tier.

If it still routes to agent:main:... after changing kind → "channel", paste:

#

openclaw gateway status (to confirm the service is using the config you edited)
openclaw channels list (to see the actual Discord account ids the gateway thinks it has)

bold junco Feb 13, 2026, 7:27 AM

#

Applied the peer.kind: "channel" fix, thank you! That resolved the routing logic.

However we're now stuck on a different issue: discord channels unresolved: 937493678119866399/1471753666947190826 on every startup for the sentry account.

Sentry bot has View Channel + Send Messages on the channel (verified in Discord UI, green checkmarks)
We can successfully send messages to the channel via the sentry account using the OpenClaw message tool
All three privileged intents enabled in Developer Portal
Multiple gateway restarts, full service restarts
Jetson bot resolves all its channels fine, only Sentry has this issue

gateway.log (every restart):
[discord] [sentry] starting provider (@Sentry)
[discord] channels unresolved: 937493678119866399/1471753666947190826

Sentry account config:

"sentry": {
  "token": "...",
  "groupPolicy": "allowlist",
  "dm": { "enabled": false },
  "guilds": {
    "937493678119866399": {
      "requireMention": false,
      "channels": {
        "1471753666947190826": { "allow": true, "requireMention": false, "users": ["118133932620382214"] }
      }
    }
  }
}

Any ideas what could cause channel resolution to fail despite correct permissions?

snow dewBOT Feb 13, 2026, 7:27 AM

#

Applied the peer.kind: "channel" fix, thank you! That resolved the routing logic.

However we're now stuck on a different issue: discord channels unresolved: 937493678119866399/1471753666947190826 on every startup for the sentry account.

Sentry bot has View Channel + Send Messages on the channel (verified in Discord UI, green checkmarks)
We can successfully send messages to the channel via the sentry account using the OpenClaw message tool
All three privileged intents enabled in Developer Portal
Multiple gateway restarts, full service restarts
Jetson bot resolves all its channels fine, only Sentry has this issue

gateway.log (every restart):
[discord] [sentry] starting provider (@Sentry)
[discord] channels unresolved: 937493678119866399/1471753666947190826

Sentry account config:

#

"sentry": {
  "token": "...",
  "groupPolicy": "allowlist",
  "dm": { "enabled": false },
  "guilds": {
    "937493678119866399": {
      "requireMention": false,
      "channels": {
        "1471753666947190826": { "allow": true, "requireMention": false, "users": ["118133932620382214"] }
      }
    }
  }
}

Any ideas what could cause channel resolution to fail despite correct permissions?

bold junco Feb 13, 2026, 7:30 AM

#

bold junco Applied the `peer.kind: "channel"` fix, thank you! That resolved the routing log...

@snow dew you did you copy vs answer

#

Applied the peer.kind: "channel" fix, thank you! That resolved the routing logic.

However we're now stuck on a different issue: discord channels unresolved: 937493678119866399/1471753666947190826 on every startup for the sentry account.

Sentry bot has View Channel + Send Messages on the channel (verified in Discord UI, green checkmarks)
We can successfully send messages to the channel via the sentry account using the OpenClaw message tool
All three privileged intents enabled in Developer Portal
Multiple gateway restarts, full service restarts
Jetson bot resolves all its channels fine, only Sentry has this issue

gateway.log (every restart):
[discord] [sentry] starting provider (@Sentry)
[discord] channels unresolved: 937493678119866399/1471753666947190826

Sentry account config:

"sentry": {
  "token": "...",
  "groupPolicy": "allowlist",
  "dm": { "enabled": false },
  "guilds": {
    "937493678119866399": {
      "requireMention": false,
      "channels": {
        "1471753666947190826": { "allow": true, "requireMention": false, "users": ["118133932620382214"] }
      }
    }
  }
}

Any ideas what could cause channel resolution to fail despite correct permissions?

#

@snow dew did you forget about me?

#

Update: Applied the peer.kind: "channel" fix -- that resolved the routing mismatch, thank you!

Now hitting a different issue: discord channels unresolved: 937493678119866399/1471753666947190826 on every gateway startup for the sentry bot account.

What works:

Sentry bot is online and connected
Can send messages to the channel via API using the sentry account
Sentry bot has View Channel + Send Messages (verified green checkmarks in Discord channel permissions)
All three privileged intents enabled in Developer Portal
Jetson bot resolves all its channels fine

What doesn't work:

On every startup, sentry bot fails to resolve the channel
Multiple full gateway restarts don't fix it
Channel never appears in sentry's guild cache

Sentry account config:

"sentry": {
  "token": "...",
  "groupPolicy": "allowlist",
  "dm": { "enabled": false },
  "guilds": {
    "937493678119866399": {
      "requireMention": false,
      "channels": {
        "1471753666947190826": { "allow": true, "requireMention": false, "users": ["118133932620382214"] }
      }
    }
  }
}

Log (every restart):

[discord] [sentry] starting provider (@Sentry)
[discord] channels unresolved: 937493678119866399/1471753666947190826

openclaw gateway status shows running, RPC probe ok. openclaw channels list shows Discord sentry: configured, token=config, enabled.

Any ideas why the sentry bot can't resolve the channel despite having correct permissions?

snow dewBOT Feb 13, 2026, 7:46 AM

#

bold junco **Update:** Applied the `peer.kind: "channel"` fix -- that resolved the routing ...

That log line is coming from OpenClaw’s startup allowlist “name → id” resolver, and it’s unfortunately misleading when your config already uses numeric IDs.

Why you see `discord channels unresolved: 937…/147…`

Internally, the resolver is fed strings in the form:

"<guildKey>/<channelKey>"

…and it interprets that as “guild / channel name” (like My Server/#help), not “guildId/channelId”.

So when you configure:

guilds: {
  "937...": {
    channels: {
      "147175...": { allow: true }

#

    }
  }
}

the resolver tries to find a channel literally named "147175..." in that guild, fails, and logs it as “unresolved”. It does not mean the bot lacks permissions or can’t actually use the channel.

What to do

Double-check you didn’t just mix up channel IDs
- Your thread channel id earlier was 1471763703467610123, but the unresolved warning references 1471753666947190826.
- If the allowlist points at a different channel than the one you’re testing, it’ll look “mysteriously blocked”.
If you want to get rid of the warning: use a channel slug/name key instead of the numeric id, e.g.
```
channels: {
```

#

     "my-channel-name": { allow: true, requireMention: false }
   }

(That’s what the resolver is designed to resolve.)

If 147175… is actually a thread (common gotcha): allowlist the parent channel instead. Threads inherit the parent channel config. (Docs mention this in the Discord channel doc: https://docs.openclaw.ai/channels/discord)

Quick probe to settle it

Run:

openclaw channels capabilities --channel discord --target channel:1471753666947190826
openclaw channels capabilities --channel discord --target channel:1471763703467610123

That’ll tell you which id is the real channel you care about and whether the bot has ViewChannel/SendMessages there.

#

If the capabilities probe shows perms are fine and routing works, I’d treat the “channels unresolved” line as a cosmetic resolver limitation (worth a GitHub issue, but not the cause of runtime breakage).

bold junco Feb 13, 2026, 8:09 AM

#

Update: resolved! The peer.kind: "channel" fix was the key piece. A few follow-up learnings for anyone hitting similar issues:

The channels unresolved warning is cosmetic when using numeric IDs as guild/channel keys. The resolver expects channel names (slugs), not IDs. Switching from "1471753666947190826": { ... } to "sentry": { ... } in the allowlist config resolved the warning. The channel name gets resolved to the ID automatically.
Discord bot permissions don't carry over when you delete/recreate a channel. We spun our wheels because the bot had permissions on the old channel but the new channel had none. The channels capabilities probe was helpful for confirming this.
Everything was actually working the whole time after the peer.kind fix, we just kept testing in channels where the bot lacked Discord-level permissions or had allow: false in the OpenClaw config.

Final working config pattern for dual bots:

"accounts": {
  "jetson": {
    "token": "...",
    "guilds": { "*": { "channels": { "sentry": { "allow": false } } } }
  },
  "sentry": {
    "token": "...",
    "guilds": { "GUILD_ID": { "channels": { "sentry": { "allow": true } } } }
  }
}

"bindings": [{ "agentId": "sentry", "match": { "channel": "discord", "accountId": "sentry", "peer": { "kind": "channel", "id": "RESOLVED_CHANNEL_ID" } } }]

Thanks Krill, the peer.kind tip + the debugging commands saved us. 🦞

#

@snow dew any other ideas

bold junco Feb 13, 2026, 8:38 AM

#

@snow dew were still not working

snow dewBOT Feb 13, 2026, 8:43 AM

#

bold junco <@1457407575476801641> were still not working

That “[discord] channels unresolved: 937…/147…” line by itself shouldn’t break routing — it’s the startup allowlist resolver trying to treat guildId/channelKey as guild/channel names, so a numeric channel key will always look “unresolvable”.

But if it’s “still not working”, I need one concrete symptom:

Is sentry not replying at all in the channel?
Or is it replying, but the wrong account / wrong agent?
Or is the only problem this log line?

Two common “actually broken” causes in this exact situation:

1) You’re allowlisting a thread ID (forum post / thread), not the parent channel

Discord’s “list guild channels” endpoint does not include thread channels, so the resolver (and many caches) will never “see” it on startup.

Fix/workaround: allowlist the parent channel (the forum or text channel) and let threads inherit, e.g.:

#

"guilds": {
  "937493678119866399": {
    "channels": {
      "PARENT_CHANNEL_ID": { "allow": true, "requireMention": false }
    }
  }
}

(You can keep the thread id too, but parent is the important one.)

2) The channel you’re testing isn’t the channel you allowlisted

In your earlier posts there were two different channel ids mentioned (147176… vs 147175…). If the allowlist is pointed at 147175… but you’re talking in 147176…, it’ll look like “nothing works”.

What to run (paste output)

These will make it obvious what’s going on:

## Multi-agent routing: binding never routes to secondary agent, always falls back to default (main)

Fix

Two quick sanity checks (because this bites people)

Why you see discord channels unresolved: 937…/147…

What to do

Quick probe to settle it

1) You’re allowlisting a thread ID (forum post / thread), not the parent channel

2) The channel you’re testing isn’t the channel you allowlisted

What to run (paste output)

Why you see `discord channels unresolved: 937…/147…`