Files
agent-claw/serverless-relay-patterns.md
daniel 0369a74ac1 Initial research: OpenClaw on AgentCore architecture
- 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
2026-05-04 08:28:52 -05:00

9.3 KiB

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.


┌─────────────────────────────────────────────────────┐
│  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.