20+ Channels: Why AI Agents Need to Live Where Your Team Works

API-only agents are useless in practice

Build an AI agent with most frameworks and you get an API endpoint. To see what it's doing, you call the API. To give it feedback, you call the API. To approve its actions, you call the API.

Nobody works this way. Your team is on Slack. Your clients are on email. Your developers are on Discord. An agent that can't meet people where they already communicate is a demo, not a production system.

20+ channels, same agent

Klawty inherits OpenClaw's channel architecture. Out of the box, your agent can communicate on:

Stable channels: Discord, Slack, Telegram, WhatsApp, Signal, Matrix, MS Teams, IRC, Line, Nostr, iMessage (macOS), Terminal, Web

Beta channels: Google Chat, Mattermost, Twitch

One agent can be active on multiple channels simultaneously. Leila (our client ops agent) posts status updates to Discord's #client-comms channel for the internal team AND sends draft emails through Gmail for client communication. Same agent, same reasoning, different output channels.

The adapter pattern

Every channel in Klawty implements the same interface:

class ChannelAdapter {
  async send(channel, message) { /* post to channel */ }
  async receive() { /* poll or websocket for new messages */ }
  async react(messageId, emoji) { /* add reaction */ }
  async getHistory(channel, limit) { /* fetch recent messages */ }
}

The agent runtime doesn't know or care whether it's talking to Discord or Telegram. It calls send() with a message. The adapter handles formatting (Discord embeds vs Telegram Markdown vs Slack blocks), rate limiting (Discord: 50 requests/second, Telegram: 30 messages/second), and authentication (bot tokens, API keys, OAuth).

Adding a new channel means implementing one adapter file. The agent, the task system, the proposal lifecycle — none of them change.

Why channels matter for governance

The proposal system (PROPOSE and CONFIRM tiers) uses Discord reactions for approval. A human sees the proposal in their Discord client, taps an emoji, and the agent proceeds. This works because Discord is already open on their phone.

If the approval mechanism required logging into a web dashboard, checking a queue, and clicking a button, response times would be hours, not minutes. Channel-native approval turns governance from a bottleneck into a notification.

📱 Discord notification:
🔔 PROPOSAL from Raph (CONFIRM tier)
Action: production-deploy
Target: api.client-site.com
Version: v2.4.1
React: ✅ or ❌

The operator approves from their phone while standing in line for coffee. Try that with an API-only agent framework.

Channel dedup

The risk of multi-channel agents is spam. An agent that posts to Discord every cycle will flood the channel. Klawty's channel dedup layer hashes every outbound message and checks against a 24-hour window:

-- Before posting
SELECT id FROM message_hashes
WHERE channel = 'discord:client-comms'
  AND hash = sha256('Weekly SEO report: traffic up 12%...')
  AND created_at > datetime('now', '-24 hours');
-- If found: skip post silently

The agent thinks it posted. The channel stays clean. The dedup layer absorbs the repetition that's inherent in cyclical autonomous agents.

The real test

We run 8 agents across 6 Discord channels, Gmail, and Telegram. The agents post roughly 80 messages per day across all channels. Of those, about 30 are suppressed by dedup (same content within 24 hours). The remaining 50 are genuine updates, proposals, and handoff notifications.

The team reads them the same way they read messages from human colleagues. That's the point — agents should be team members, not API endpoints you have to remember to check.