0369a74ac1
- Architecture comparison (OpenClaw daemon vs AgentCore serverless) - Component compatibility analysis - Fargate analysis - AgentCore rebuild plan (Telegram, zero always-on compute) - Memory strategy: AgentCore Memory + factbase as structured KB - Serverless relay patterns per channel - All open questions resolved - OpenClaw feature delta March→May 2026 - Build phases and cost estimates
193 lines
9.3 KiB
Markdown
193 lines
9.3 KiB
Markdown
# Serverless Channel Relay Patterns — Research
|
|
|
|
## The Core Question
|
|
|
|
Can we replace the always-on channel relay (Fargate task) with event-driven serverless (Lambda + API Gateway), eliminating the persistent connection cost?
|
|
|
|
**Short answer**: Depends entirely on the channel. Telegram and Slack — yes, fully serverless. Discord — yes for slash commands, **no for regular chat messages**. WhatsApp (Baileys/personal) — no.
|
|
|
|
---
|
|
|
|
## Channel-by-Channel: Serverless Viability
|
|
|
|
### ✅ Telegram — Fully Serverless
|
|
|
|
Telegram bots support **full webhook mode** for all message events. Every message type (text, photos, reactions, etc.) can be delivered as an HTTP POST to your endpoint.
|
|
|
|
**Pattern**: `Telegram servers → API Gateway → Lambda → SQS → InvokeAgentRuntime`
|
|
|
|
```
|
|
User sends message to Telegram bot
|
|
→ Telegram POSTs to your HTTPS endpoint
|
|
→ API Gateway (HTTP API, ~$1/million requests)
|
|
→ Lambda (verify, parse, enqueue)
|
|
→ SQS (buffer for async processing)
|
|
→ Lambda → InvokeAgentRuntime (AgentCore)
|
|
→ Agent responds
|
|
→ Lambda calls Telegram Bot API to send reply
|
|
```
|
|
|
|
- **Well-proven pattern**: multiple serverless frameworks have Telegram webhook plugins
|
|
- Lambda timeout: use deferred/async pattern for long agent runs (respond 204 immediately, process async)
|
|
- Cost: essentially **free** at personal assistant scale (~$0.01/mo)
|
|
- grammY (used by OpenClaw) supports webhook mode natively
|
|
|
|
### ✅ Slack — Fully Serverless
|
|
|
|
Slack's **Events API** delivers all events (messages, reactions, mentions) as HTTP webhooks. No persistent connection needed.
|
|
|
|
```
|
|
User sends Slack message
|
|
→ Slack POSTs to your endpoint within 3 seconds
|
|
→ API Gateway → Lambda (must respond 200 within 3s or Slack retries)
|
|
→ Lambda: ack immediately, process async via SQS/Lambda
|
|
→ Agent runs → Slack Web API to post reply
|
|
```
|
|
|
|
- Standard pattern: Bolt for JavaScript/Python works in Lambda
|
|
- **3-second ack requirement**: must decouple ack from agent processing
|
|
- OpenClaw's Slack (Bolt) supports Events API mode (vs Socket Mode which needs WS)
|
|
- AgentCore Gateway actually has a **1-click Slack integration** if you want to skip custom code
|
|
|
|
### ⚠️ Discord — PARTIAL (big asterisk)
|
|
|
|
This is the tricky one. Discord has two separate systems:
|
|
|
|
#### What's serverless: Interactions (slash commands, buttons, select menus)
|
|
Discord sends these as HTTP POSTs to an **Interactions Endpoint URL**. Lambda handles them fine.
|
|
- Pattern: `Discord → API Gateway → Lambda → respond within 3s (or defer)`
|
|
- Works for: `/ask`, `/chat`, button clicks, context menu commands
|
|
- **3-second hard limit** on initial response — need deferred responses for agent invocations
|
|
|
|
#### What's NOT serverless: Regular chat messages (MESSAGE_CREATE)
|
|
Regular messages in channels/DMs — the kind an AI assistant primarily needs — **only come via the Gateway WebSocket**. Discord does not send MESSAGE_CREATE as a webhook.
|
|
|
|
Discord has an outgoing webhook events system (separate from Interactions), but as of 2025/2026 it only supports 3 event types:
|
|
- `APPLICATION_AUTHORIZED` (user installs app)
|
|
- `ENTITLEMENT_CREATE` (premium purchase)
|
|
- `QUEST_USER_ENROLLMENT`
|
|
|
|
**No MESSAGE_CREATE, no REACTION_ADD, no DM events via webhook.** There's a long-standing feature request for this but Discord hasn't shipped it.
|
|
|
|
**Source**: Discord changelog: *"You can now subscribe to a limited number of HTTP-based outgoing webhook events... Currently, 3 events are available: APPLICATION_AUTHORIZED, ENTITLEMENT_CREATE, and QUEST_USER_ENROLLMENT."*
|
|
|
|
#### So for Discord, options are:
|
|
1. **Slash commands only** → Lambda, fully serverless. User has to use `/chat <message>` instead of plain messages.
|
|
2. **Regular messages** → still needs Gateway WS connection (always-on process)
|
|
3. **Hybrid**: slash commands via Lambda + tiny always-on relay just for MESSAGE_CREATE
|
|
|
|
### ❌ WhatsApp (Baileys/personal) — Not Serverless
|
|
|
|
Baileys uses the WhatsApp Web protocol — a persistent WebSocket with stateful auth. No webhook mode exists for personal WhatsApp. Needs always-on.
|
|
|
|
**Exception**: **WhatsApp Business API (Cloud API)** is fully webhook-based:
|
|
- Meta sends message events to your HTTPS endpoint
|
|
- Lambda + API Gateway pattern is well-documented
|
|
- But: requires a Business account, phone number registration through Meta, not the same as personal WhatsApp
|
|
|
|
If you're willing to switch from Baileys (personal WA) to the Business API, this is fully serverless. Different UX though — it's a separate business number, not your personal number.
|
|
|
|
---
|
|
|
|
## Recommended Architecture: Hybrid Serverless + Tiny Relay
|
|
|
|
```
|
|
┌─────────────────────────────────────────────────────┐
|
|
│ SERVERLESS LAYER (Lambda + API Gateway) │
|
|
│ │
|
|
│ Telegram ────────→ Lambda → SQS → Lambda │
|
|
│ Slack (Events) ──→ Lambda → SQS → Lambda ─────→ InvokeAgentRuntime
|
|
│ Discord (slash) ──→ Lambda → defer → Lambda │
|
|
│ WA Business ─────→ Lambda → SQS → Lambda │
|
|
└─────────────────────────────────────────────────────┘
|
|
|
|
┌─────────────────────────────────────────────────────┐
|
|
│ TINY RELAY (Fargate, only if you need it) │
|
|
│ │
|
|
│ Discord (chat msgs) ─→ tiny Node.js relay ─────→ InvokeAgentRuntime
|
|
│ WhatsApp (Baileys) ─→ tiny Node.js relay ─────→ InvokeAgentRuntime
|
|
│ │
|
|
│ ~0.25 vCPU / 0.5 GB ≈ $9/mo │
|
|
└─────────────────────────────────────────────────────┘
|
|
```
|
|
|
|
If Discord and Baileys are the only things that need persistent connections, you can minimize the relay to the smallest possible Fargate task (~$9/mo). Everything else is serverless.
|
|
|
|
---
|
|
|
|
## Discord-Specific: Slash-Command-Only Pattern
|
|
|
|
If you're OK with slash commands as the interface instead of plain messages, Discord becomes fully serverless:
|
|
|
|
```
|
|
/ask What's on my calendar today?
|
|
→ Discord POSTs to API Gateway
|
|
→ Lambda: validate sig, respond DEFERRED_CHANNEL_MESSAGE_WITH_SOURCE
|
|
→ async Lambda → InvokeAgentRuntime
|
|
→ agent processes
|
|
→ Lambda calls Discord webhook to post followup
|
|
```
|
|
|
|
The UX difference: users type `/ask <prompt>` instead of just `<prompt>`. For a personal assistant on your own server, this is tolerable. For a general-purpose assistant reading all messages, it's a significant regression.
|
|
|
|
---
|
|
|
|
## The SQS Pattern (Decouple Ack from Processing)
|
|
|
|
Applies to all webhook channels — Telegram, Slack, Discord interactions. The webhook Lambda must respond within 3 seconds (Slack/Discord) or 10 seconds (Telegram). Agent runs can take 30-120 seconds. Solution:
|
|
|
|
```
|
|
1. Webhook Lambda:
|
|
- Validate signature
|
|
- Enqueue to SQS (< 100ms)
|
|
- Return 200/204 immediately
|
|
|
|
2. Processing Lambda (SQS trigger):
|
|
- Pull message from SQS
|
|
- InvokeAgentRuntime (async, up to 15 min Lambda timeout)
|
|
- On completion: call channel API to post reply
|
|
```
|
|
|
|
Cost at personal assistant scale: effectively $0.
|
|
|
|
---
|
|
|
|
## Cost Comparison
|
|
|
|
| Architecture | Monthly Cost | Discord UX |
|
|
|---|---|---|
|
|
| Full Fargate relay (all channels) | ~$9-15 + NAT | Full chat |
|
|
| Full Lambda (all channels, slash commands only) | ~$0.01 | Slash commands |
|
|
| Hybrid: Lambda + tiny Fargate (Discord chat + Baileys) | ~$9 + $0.01 | Full chat |
|
|
| Lambda only + WhatsApp Business API (no Baileys) | ~$0.01 | Full chat (business WA) |
|
|
|
|
---
|
|
|
|
## Verdict Per Channel
|
|
|
|
| Channel | Serverless? | Lambda Pattern | Notes |
|
|
|---|---|---|---|
|
|
| Telegram | ✅ Fully | API GW → Lambda → SQS | grammY webhook mode |
|
|
| Slack | ✅ Fully | API GW → Lambda → SQS | Bolt Events API mode |
|
|
| Discord (slash only) | ✅ With limits | API GW → Lambda (deferred) | No chat message listening |
|
|
| Discord (all messages) | ❌ | Needs Gateway WS | Feature request open, not shipped |
|
|
| WhatsApp Business API | ✅ Fully | API GW → Lambda → SQS | Needs Meta Business account |
|
|
| WhatsApp Baileys (personal) | ❌ | Needs persistent WS | Personal account protocol |
|
|
| Signal | ❌ | Needs signal-cli subprocess | No webhook mode |
|
|
| iMessage (BlueBubbles) | ❌ | Local Mac process | By definition |
|
|
|
|
---
|
|
|
|
## What This Means for the Rebuild
|
|
|
|
A lean serverless relay is possible if you:
|
|
1. Use Telegram and/or Slack as primary channels (both fully serverless)
|
|
2. Accept slash-command UX for Discord OR run a tiny Fargate relay just for Discord chat
|
|
3. Optionally switch to WhatsApp Business API instead of Baileys
|
|
|
|
The relay doesn't have to be a full-fat OpenClaw gateway — for the serverless channels it's literally just "validate signature, enqueue to SQS, return 200." ~100 lines of code per channel.
|
|
|
|
---
|
|
|
|
*Research: 2026-05-04. Sources: Discord webhook events docs, Discord changelog (only 3 webhook event types confirmed), Telegram setWebhook docs, Slack Events API docs, WhatsApp Business API webhook docs.*
|