wehub-resource-sync
186 lines
11 KiB
Markdown
186 lines
11 KiB
Markdown
# Architecture
|
|
|
|
How `@copilotkit/channels-whatsapp` is structured and **why** each boundary exists.
|
|
|
|
This package is the WhatsApp `PlatformAdapter` for [`@copilotkit/channels`](../channels).
|
|
The channel engine owns the platform-agnostic orchestration (handlers, the
|
|
run/tool/interrupt loop, JSX action binding, the `ActionStore`); this package
|
|
owns everything WhatsApp-specific: webhook ingress, Cloud API egress, buffered
|
|
rendering, and opaque-id interactions.
|
|
|
|
## Design goals
|
|
|
|
1. **The agent doesn't know about WhatsApp.** It receives ordinary AG-UI input
|
|
and emits ordinary AG-UI events.
|
|
2. **WhatsApp mechanics don't bleed into the engine.** Webhook signature
|
|
validation, message buffering, history reconstruction, interactive-message
|
|
encoding, and `button_reply` / `list_reply` decoding all live behind the
|
|
`PlatformAdapter` interface.
|
|
3. **One file, one job.** Each source file has a single responsibility.
|
|
4. **Failures are contained.** A failed send doesn't crash the run.
|
|
5. **History is adapter-owned.** WhatsApp exposes no readable message history;
|
|
the adapter maintains a `HistoryStore` and replays it on every turn. This is
|
|
the key difference from Slack: history is held locally, not reconstructed
|
|
from the platform, so a durable `HistoryStore` is required for persistent
|
|
memory across restarts.
|
|
|
|
## The boundary: `PlatformAdapter`
|
|
|
|
`WhatsAppAdapter` (constructed via `whatsapp(opts)`) implements
|
|
`@copilotkit/channels`'s `PlatformAdapter`. The members it implements:
|
|
|
|
- `platform`, `capabilities` (`supportsStreaming: false`, modals/typing/
|
|
reactions all `false`), `ackDeadlineMs` (5000)
|
|
- `start(sink)` / `stop()` — start / stop the `WebhookServer` and push
|
|
normalized events into the engine's `IngressSink`
|
|
- `render(ir)` — IR → Cloud API payloads (`renderWhatsAppMessage`)
|
|
- `post` / `update` / `stream` / `delete` — egress via `WhatsAppClient`;
|
|
`update` re-posts (no edit API), `delete` is a no-op, `stream` buffers the
|
|
full iterable then posts once
|
|
- `createRunRenderer(target)` — the AG-UI `RunRenderer` for a run; buffers
|
|
the full response and sends as text
|
|
- `decodeInteraction(raw)` — inbound `button_reply` / `list_reply` payload →
|
|
`InteractionEvent`
|
|
- `lookupUser(query)` — always returns `undefined` (no user directory on
|
|
WhatsApp)
|
|
- `getMessages(target)` — the conversation's messages from `HistoryStore`
|
|
(backs `thread.getMessages`)
|
|
- `postFile(target, args)` — upload media via the media-upload API then send
|
|
(backs `thread.postFile`)
|
|
- `conversationStore` — `WhatsAppConversationStore` backed by `HistoryStore`
|
|
|
|
The engine drives ingress through the `IngressSink` it hands to `start`
|
|
(`sink.onTurn` / `sink.onInteraction`) and egress through these methods.
|
|
|
|
## Request lifecycle
|
|
|
|
```
|
|
WhatsApp Cloud API
|
|
│
|
|
▼
|
|
WebhookServer
|
|
GET /webhook ──► verify hub.verify_token → 200 + hub.challenge
|
|
POST /webhook ──► validate X-Hub-Signature-256
|
|
│
|
|
▼
|
|
handleWebhookValue (webhook-listener.ts)
|
|
• filters status updates, own echoes
|
|
• resolves sender contact from webhook contacts[]
|
|
• dispatches interactive → sink.onInteraction
|
|
text/media → sink.onTurn (with HistoryStore.append)
|
|
│
|
|
▼
|
|
@copilotkit/channels: Thread
|
|
│ thread.runAgent()
|
|
▼
|
|
runAgentLoop
|
|
┌──────────────────────────────────────────────────────────────────────┐
|
|
│ agent.runAgent(..., RunRenderer.subscriber) │
|
|
│ • createRunRenderer buffers TEXT_MESSAGE_* → single send │
|
|
│ • captures frontend tool calls + on_interrupt custom events │
|
|
└──────────────────────────────────────────────────────────────────────┘
|
|
│
|
|
┌──────────────┼──────────────────────────────────┐
|
|
▼ ▼ ▼
|
|
tool.handler(args) onInterrupt handler finish
|
|
renders JSX via posts interactive message via HistoryStore.append
|
|
thread.post(...) thread.post(...) → awaitChoice (assistant turn)
|
|
→ renderWhatsAppMessage → Cloud API → thread.resume(value)
|
|
```
|
|
|
|
### Ingress
|
|
|
|
`handleWebhookValue` is the translation layer between the Cloud API webhook
|
|
schema and the engine's domain. It processes each `value` object from
|
|
`entry[].changes[]`, skipping status-update entries. For interactive messages
|
|
(`button_reply` / `list_reply`) it calls `sink.onInteraction`; for all other
|
|
message types (text, image, audio, video, document) it appends the user turn to
|
|
`HistoryStore` and calls `sink.onTurn` with a `conversationKey`
|
|
(`conversationKeyOf(waId)`), `replyTarget`, `userText`, and `user`.
|
|
|
|
### Run / render
|
|
|
|
`thread.runAgent` resolves the conversation's `AgentSession` from the
|
|
`conversationStore` (which reads `HistoryStore` to reconstruct `agent.messages`),
|
|
creates `createRunRenderer(target)`, and runs `runAgentLoop`. The renderer
|
|
(`event-renderer.ts`) subscribes to AG-UI events: it accumulates
|
|
`TEXT_MESSAGE_CONTENT` deltas into a full string, then sends it as a single text
|
|
message when the run completes. This is the key divergence from Slack: there is no
|
|
incremental `chat.update` — the response is buffered and sent once.
|
|
|
|
### Tools
|
|
|
|
When the agent calls a registered frontend tool, the loop validates the args
|
|
(Standard Schema) and invokes `tool.handler(args, ctx)`. `ctx` is the single
|
|
shared `BotToolContext` (`{ thread, message?, user?, signal?, platform }`) — there
|
|
is no WhatsApp-specific context. WhatsApp power is reached only through
|
|
capability-gated `thread` methods (`getMessages`, `postFile`). A render-tool
|
|
handler renders JSX with `thread.post(<Card .../>)`, which goes through the
|
|
engine's action-binding then `renderWhatsAppMessage` → Cloud API.
|
|
|
|
### HITL and interrupts
|
|
|
|
`thread.awaitChoice(<Picker .../>)` posts an interactive message and blocks until
|
|
a `button_reply` or `list_reply` in that conversation resolves it. A captured
|
|
agent interrupt is dispatched to the registered `onInterrupt` handler, which posts
|
|
a picker whose button `onClick` calls `thread.resume(value)`; the loop re-enters
|
|
with `forwardedProps.command`.
|
|
|
|
### Interactions
|
|
|
|
`handleWebhookValue` routes every `button_reply` / `list_reply` directly to
|
|
`sink.onInteraction`. `decodeInteraction` splits the reply id: bare minted ids
|
|
(`ck:...`) are dispatched directly; ids encoded as `${actionId}::${JSON.stringify(value)}`
|
|
are split back into `id` + `value`. The engine resolves the interaction: an
|
|
awaiting HITL waiter, or `ActionRegistry.dispatch` — a hot-cache hit or a
|
|
cold-path re-render rehydration. A miss after restart degrades to "this action
|
|
expired." Because there is no ack deadline in the webhook model (no 3-second
|
|
constraint like Slack), the `ackDeadlineMs` is set to 5000ms to give the
|
|
engine time to dispatch before the webhook response times out.
|
|
|
|
## What differs from Slack
|
|
|
|
| Concern | Slack | WhatsApp |
|
|
| ------------------- | --------------------------------------------------- | ----------------------------------------------------------------------- |
|
|
| Ingress | Socket Mode (outbound WebSocket via Bolt) | HTTP webhook (signed POST); needs a public URL |
|
|
| Egress | `chat.update` streaming; message editing | Buffered single send; no message editing or delete |
|
|
| History | Reconstructed from `conversations.replies` per turn | Held in `HistoryStore`; durable storage is required for persistence |
|
|
| Commands | Native slash commands via Slack app config | Leading-keyword text match; not a native surface |
|
|
| Command persistence | Slash commands appear in the thread history | Commands are NOT persisted at ingress (engine prompt path injects them) |
|
|
| User directory | `lookupUser` resolves names/emails to `<@USERID>` | `lookupUser` always returns `undefined` |
|
|
| Streaming | `chat.update` throttle; live editing | Not supported; buffer + single send |
|
|
|
|
## SDK files at a glance
|
|
|
|
```
|
|
src/
|
|
├── index.ts # public exports
|
|
├── adapter.ts # whatsapp() factory + WhatsAppAdapter (PlatformAdapter impl)
|
|
├── event-renderer.ts # createRunRenderer: AG-UI subscriber → buffered send + interrupt capture
|
|
├── interaction.ts # decodeInteraction (opaque id) + conversationKeyOf
|
|
├── render/
|
|
│ ├── message.ts # renderWhatsAppMessage (IR → Cloud API payloads)
|
|
│ └── budget.ts # WA_LIMITS + truncateText / clampArray degradation
|
|
├── webhook-server.ts # HTTP server: GET verify + signed POST dispatch
|
|
├── webhook-listener.ts # handleWebhookValue: Cloud API webhook → onTurn / onInteraction
|
|
├── client.ts # WhatsAppClient: send messages, upload media, download media
|
|
├── conversation-store.ts # WhatsAppConversationStore: HistoryStore → AgentSession
|
|
├── history-store.ts # HistoryStore interface + InMemoryHistoryStore
|
|
├── markdown-to-wa.ts # GFM Markdown → WhatsApp formatting (bold/italic/code/strikethrough)
|
|
├── download-files.ts # inbound media download → AG-UI multimodal content parts
|
|
├── built-in-tools.ts # defaultWhatsAppTools (empty in v1; no user directory)
|
|
├── built-in-context.ts # formatting + delivery context entries
|
|
└── types.ts # WhatsAppAdapterOptions, ReplyTarget, WhatsAppMessageRef, InboundMessage, …
|
|
```
|
|
|
|
## What's intentionally _not_ abstracted
|
|
|
|
- **No abstraction over the Cloud API.** If you use this package, you're talking
|
|
to Meta's WhatsApp Cloud API.
|
|
- **No template-message sending.** The adapter only replies within the 24-hour
|
|
customer-service window opened by an inbound user message. Proactive messaging
|
|
requires template approval and is not implemented in v1.
|
|
- **History is not platform-sourced.** Unlike Slack, there is no API to read
|
|
WhatsApp message history. The adapter's `HistoryStore` is the source of truth;
|
|
restarts lose history unless a durable `HistoryStore` is provided.
|