Summary
ClawScale already supports multiple channels, but production gateway deployments often need explicit routing and policy controls at the channel layer.
Problem
Many integrators need routing behavior like:
- DM allow / deny policy
- group allow / deny policy
- mention gating in groups
- thread-aware routing
- multi-account routing
- account-specific delivery selection
- consistent inbound and outbound route correlation
Without these controls, teams have to reimplement gateway policy logic outside the gateway, which reduces the value of using a shared gateway product.
Proposed solution
Add configurable channel routing and policy features, for example:
DM policy
- open
- allowlist
- deny
- pairing / approval-based
Group policy
Mention behavior
- require mention in groups
- respond to all messages
- configurable mention aliases
Multi-account routing
- default account per channel
- account override for outbound sends
- account-aware inbound metadata
- preserve the route/account needed for replies
Thread / conversation routing
- preserve thread IDs where supported
- expose them to backends
- allow outbound replies into a specific thread or reply context
Expected behavior
- Policy decisions happen at the gateway layer
- Integrators can configure routing without forking adapters
- Group, thread, and account metadata remain available to backends and outbound sends
- Outbound replies can be routed back through the correct account and reply context
Why this matters
This moves ClawScale closer to being a true channel gateway/control plane instead of only an adapter collection with text forwarding.
Acceptance criteria
- Policy options are documented and configurable
- At least one group-capable adapter supports mention gating
- Thread metadata is preserved when the provider supports it
- Multi-account routing is supported in a documented way
- Inbound and outbound routing rules behave consistently
Summary
ClawScale already supports multiple channels, but production gateway deployments often need explicit routing and policy controls at the channel layer.
Problem
Many integrators need routing behavior like:
Without these controls, teams have to reimplement gateway policy logic outside the gateway, which reduces the value of using a shared gateway product.
Proposed solution
Add configurable channel routing and policy features, for example:
DM policy
Group policy
Mention behavior
Multi-account routing
Thread / conversation routing
Expected behavior
Why this matters
This moves ClawScale closer to being a true channel gateway/control plane instead of only an adapter collection with text forwarding.
Acceptance criteria