Multi-channel chat: web, SMS, WhatsApp, iMessage and Slack

Part 1

One turn for every channel

Study first

• The adapter pattern: each channel turns what arrives into one shape, { channel, address, text, thread }, and renders what goes back. The agent in the middle does not know which channel it is on, except for a line about how to write.
• Where a conversation lives decides where it can continue. A history kept in the browser cannot be continued from a phone.
• Latency: the web streams, SMS waits for the whole reply. The same turn serves both; only the call that runs it differs.

Build

1. prepare in src/lib/assistant.ts: the web chat's turn taken out of its route, the versioned prompt first so the provider can cache it, then what is known about the person and the conversation trimmed to the context budget. The web streams it; the other channels wait for it.
2. A conversations table and src/lib/history.ts: each conversation with its person and its messages, each message marked with the channel it came by.
3. The web route starts from the server's copy when there is one, so turns taken on another channel are part of the next answer, and updates the copy after each reply. The chat page fetches the server's copy when it opens a conversation and labels each message that came by another channel.

Done when

• A conversation that includes WhatsApp turns reaches the model whole, even when the browser sends only its own older messages and the new question; a turn whose save has not landed yet is kept from the browser's copy.

Part 2

One person across channels

Study first

• Identity across channels is linked by verification, never by guessing. A matching phone number or name is a claim; possession of both accounts is proof.
• A one-time code is the proof: shown in one channel, sent from the other, short-lived, single-use, stored as its hash.

Build

1. linkCode(person, conversation) in src/lib/channels.ts: 8 characters from an alphabet without look-alikes (no 0, O, 1 or I), valid for 10 minutes, stored as a SHA-256 hash.
2. A channels table: each sender on each channel, the person behind it, the conversation it continues, when it last wrote and whether it opted out. A sender who never linked is a person of their own, such as whatsapp:+15105550142.
3. link <code> from a phone or a Slack account links that address to the person and their conversation. A linked WorkBot user gets their role's tools; anyone else gets the customer's.
4. "Continue on your phone" on the chat page shows the code with links that open WhatsApp or the SMS app with the message typed in. Employees link Slack from their settings.

Done when

• A code links once and then expires; a wrong code links nothing; a number that never sent one keeps a conversation of its own.

Part 3

SMS and WhatsApp through Twilio

Study first

• Twilio's webhook signature for a form-encoded request: HMAC-SHA1 of the exact URL it called followed by each parameter, name then value, sorted by name, keyed with the account's auth token. Twilio's SDKs ship a validator; the check is a few lines either way.
• Respond fast, process asynchronously (Day 18). Twilio needs an answer within seconds; a model's turn takes longer.
• Outbound: the Messaging API, status callbacks (queued, sent, delivered, undelivered, failed), and retries that do not resend a message the provider accepted.
• WhatsApp's rules: a customer's message opens a 24-hour window for free-form replies; outside it, only an approved template. A business needs the customer's opt-in before it writes first, and STOP must be honoured on every channel.

Build

1. src/lib/twilio.ts: the signature check, computed over the configured public URL, because behind a proxy the server sees a different one; and one function that sends through the Messaging API with a status callback.
2. /api/webhooks/twilio: check, then hand the message to Inngest under Twilio's message id, so a redelivery is the same run, and answer with empty TwiML at once.
3. src/inngest/channel-reply.ts: the turn, the reply queued in outbound, the send, then memory extracted from the exchange, each a step.
4. deliver in src/lib/outbound.ts: a message that already has the provider's id is not sent again. A 429 or a 5xx is recorded and retried; anything else fails for good with the provider's code. WhatsApp outside the window sends the approved template, without variables here, or fails with that reason. /api/webhooks/twilio/status records Twilio's word on each message.
5. STOP, UNSUBSCRIBE, CANCEL, END and QUIT silence an address until START.

Done when

• A signed message reaches the workflow and an unsigned or altered one does nothing; a send whose id is stored is not repeated; a provider failure retries and is reported; WhatsApp's window holds in both directions.

Part 4

Slack through the Chat SDK

Study first

• One codebase, many platforms: the Chat SDK has adapters for Slack, Teams, Google Chat, Discord and others behind one API of threads, mentions, posts and cards.
• Serverless operation: Slack expects an answer within 3 seconds and redelivers when it does not get one, so the handler runs after the response and duplicate deliveries are dropped.
• The SDK keeps state between requests: followed threads, a lock per thread, deduplication keys, queues.

Build

1. src/lib/chat-state.ts: the SDK's state interface over one table of WorkBot's, each operation one statement.
2. src/lib/bot.ts: a mention starts a thread the bot follows, and each message in it continues the conversation; the thread is the conversation, and the author's linked account sets the role. A reply that used tools goes as a card naming them.
3. /api/webhooks/slack, served by the SDK, and a Slack app manifest in docs/channels.md.

Done when

• The route answers Slack's address check and refuses an unsigned event, and a mention in a thread is answered in that thread with the conversation kept.

Part 5

A reply for each channel, and a person when needed

Study first

• Channel constraints: SMS takes plain text, WhatsApp bold, Slack threads and cards. Tell the model, and enforce it on what comes back.
• Human handoff: escalate to a person on any channel with the transcript, so nobody asks the customer to start again.
• Know who is writing. A stranger texting the business number is a customer; a signed-out visitor on the web might be staff.

Build

1. A line per channel telling the model how to write, and render, which strips markdown for SMS, converts Markdown bold to WhatsApp's and holds each length limit.
2. hand_off in src/lib/handoff.ts, offered on every channel: a request for the team that looks after customers, with the reason, the conversation and where to reply.
3. On SMS and WhatsApp the model is told an unlinked sender is a customer: answer from the customer-facing documents, do not send them to an internal team, hand off when they need a person.

Done when

• A customer who asks for a person on WhatsApp gets a request filed with the transcript, and the next turn knows it was filed.

Part 6

Run it on the dev server

Build

1. Set APP_URL, a TWILIO_AUTH_TOKEN of your own to sign the test messages with, and point the Inngest dev server at the app.
2. On the chat page, ask about a delivery, take a code, then post messages to /api/webhooks/twilio signed as Twilio signs them: link <code>, a follow-up, a damaged-goods complaint. Every model turn is real; nothing proves delivery to or from Twilio.
3. Open the chat page again and /admin/channels: the WhatsApp turns on the web, who has linked, each message sent and why it did not leave the machine.

Done when

• The transcript reads as one conversation across two channels, with each tool call and hand-off in place.

Part 7

What an account adds, and iMessage

Study first

• iMessage has no public API for business. Apple Messages for Business runs through Apple's approved messaging providers, with webhooks in and an API out. SMS reaches nearly every phone and is the fallback, with sender rules that vary by country and number type.

Build

1. In docs/channels.md, list what going live needs: a Twilio account and numbers, the webhook URL in Twilio's console, a WhatsApp sender approved by Meta, a template for outside the window, opt-in collected before WorkBot writes first, and a Slack app installed with the manifest.
2. Write down what is not built: iMessage, quiet hours, typing indicators, attachments, a page or alert when a hand-off arrives (it waits in the team's requests), and a person replying from WorkBot to the channel it came from.

Done when

• Someone with the accounts can turn each channel on from the environment alone, and knows which claims stay unproven until then.