Channels and integrations: one event format behind every channel
The Reach layer of the Agent Engine, which we deploy separately for each client rather than run as a shared service. Website chat, WhatsApp, phone calls and email each have their own rules, so each gets an adapter that translates it into one internal event. Routing, retrieval and guardrails are written once, and your CRM, helpdesk or calendar connects through its own API with its own scoped key.
Most businesses meet customers in more than one place. The first assistant is usually built for the website, and the second channel arrives as a copy: a separate WhatsApp bot with its own prompt, its own answers and its own bugs. Six months later the two disagree about the returns policy, and fixing one does not fix the other.
Channels also differ in ways that matter to the logic. WhatsApp allows free-form replies only inside a customer-service window and needs approved templates outside it. A phone call needs short turns and has to cope with interruptions. Email arrives in threads full of quoted history and signatures. Web chat can show buttons and links. Handling those differences inside the business logic is how assistants become tangled.
The Reach layer keeps channel rules at the edge. Each adapter knows its channel; the layers behind it see one event shape and return one reply shape, which the adapter renders back in the channel’s own terms.
What each channel adapter takes care of
Channel
What the adapter handles
What the business logic never sees
Website chat
A session id per tab, rich replies with buttons, links and citation chips, reset and delete
Widget markup and browser storage
WhatsApp Business Platform
The customer-service window, approved templates outside it, media messages, opt-in and opt-out
Template ids and the webhook payload format
Phone calls via Twilio
Speech to text and back, turn-taking and interruptions, transfer to a staff number, the AI disclosure at the start
Audio streams and telephony events
Email
Thread matching, stripping quoted history and signatures, attachments
MIME parsing and mailbox credentials
Webhooks and forms
Signature checks, schema validation, de-duplication of repeated deliveries
Each sender’s own payload format
How it works
The mechanisms, and their alternatives
Mechanism 01
The channel-adapter contract
Every adapter turns an inbound message into the same event: who sent it (a hashed identity, with the channel’s own id kept separately), which conversation it belongs to, the text and any attachments, what the channel can do (buttons, media, an open messaging window) and a delivery id. The reply comes back as a structured object with text, optional choices and citations, and the adapter renders it: buttons on the web, a numbered list or a template on WhatsApp, short spoken sentences on a call.
What's the alternative? A separate bot per channel
Separate bots are quicker to launch one at a time and can suit a single short campaign. For anything long-lived, two copies of the logic drift apart, and every fix, evaluation and guardrail has to be done twice.
Mechanism 02
Inbound webhooks verified before anything acts
Every inbound call from a channel or a system is checked against the sender’s signature or shared secret, validated against a schema and de-duplicated by its delivery id before it reaches the router. Senders resend webhooks they think failed, so the same message can arrive twice; the delivery id turns the second copy into a no-op rather than a second reply.
What's the alternative? Trust a secret-looking URL
Accepting any request to an unguessable endpoint is common in quick automations. Anyone who learns the URL can then inject messages or fake events, so we do not ship it, internal tools included.
Mechanism 03
Your systems through their own APIs
CRMs, helpdesks, calendars, booking tools and databases connect through their official APIs, with one scoped credential per integration issued from accounts in your name. Reads and writes become tools in the orchestration layer, with the same schemas, approval rules and idempotency keys as any other tool. Where a system has no API, a structured export or a database view is agreed during scoping; we do not scrape a logged-in session.
What's the alternative? An integration platform as the hub
Routing every system through n8n, Make or Zapier gives your team a visual place to see and change connections, and we build that way when the team will own the flows. It adds another system in the path, with its own limits and pricing, so busy or latency-sensitive paths often call the API directly.
Mechanism 04
One conversation across channels, only on proof
A customer who starts on the website and continues on WhatsApp is treated as the same person only when the system can tell: a verified phone number or email, a signed-in account, or a link the customer clicks to connect the two. Then the history and the open case follow them. Without that proof the channels stay separate, because guessing identity from a name is how one customer sees another’s order.
What's the alternative? Merge on similar details
Fuzzy matching joins more conversations and looks smoother in a demo. A single wrong merge shows personal data to the wrong person, so the bar is proof, not likelihood.
Mechanism 05
Channel rules enforced at the edge
Messaging windows and template approval on WhatsApp, length and formatting limits, how a call handles silence and rate limits on outbound sends are enforced by the adapter, not remembered by the model. When a reply cannot be delivered as written, for example because a WhatsApp window has closed, the adapter reports it back so the flow can switch to an approved template, another channel or a person.
What's the alternative? Ask the model to write for each channel
Prompting the model to reply “in WhatsApp style” works for tone and fails on the hard rules, such as windows and templates, which are not matters of style. Rules go in code; tone can go in the prompt.
Defaults
Defaults we ship
One adapter per channel, each emitting the same internal event and rendering the same reply object.
Signature or secret checks, schema validation and delivery-id de-duplication on every inbound webhook.
One scoped credential per connected system, issued from accounts in your name and recorded for rotation.
Writes to your systems as tools, with schemas, idempotency keys and approval rules.
Identity joined across channels only on proof: a verified number or email, a sign-in, or a link the customer confirms.
The AI disclosure delivered in each channel’s own way: a line in the widget, the first WhatsApp message, the opening sentence of a call.
Recorded opt-in before any outbound or template message.
Limits
Limits, stated plainly
Each channel brings setup steps we do not control, such as WhatsApp Business verification, template review and phone-number provisioning; the provider sets those timelines.
The assistant on this website runs on web chat only; its WhatsApp channel is not live yet. In client builds, WhatsApp runs on the client’s own WhatsApp Business account.
Rich replies degrade: a set of cards on the web becomes a short list on WhatsApp and a spoken choice on a call, so flows are designed for the plainest channel first.
Systems without an API, or with tight rate limits, set the pace of an integration; we work within their limits rather than around them.
Voice adds latency and transcription errors that text channels do not have; that handling is specific to the voice agent builds.
Configuration
What the configuration looks like
One inbound WhatsApp message as an internal channel event (Sample data: illustrative shape).
{
"event_id": "evt_01JA7Q…",
"delivery_id": "wamid.HBgL…", // repeated webhooks share it: processed once
"channel": "whatsapp",
"capabilities": { "buttons": false, "media": true, "window_open": true },
"conversation_id": "cv_7f3a…",
"sender": { "id_hash": "sha256:9c1e…", "verified": "phone" },
"message": { "type": "text", "text": "Is my order out for delivery?" },
"received_at": "2026-10-18T09:14:03Z"
}
Can we add a channel later without rebuilding the assistant?
Yes, that is what the adapter contract is for. A new channel is a new adapter plus channel-specific tests, and the routing, knowledge, tools and guardrails behind it are reused. What remains is the channel’s own setup, such as number registration or template approval, and any flows that only make sense there.
Which channels can a build reach?
Website chat, WhatsApp through the WhatsApp Business Platform, phone calls through telephony such as Twilio, email, and inbound webhooks from forms and your own apps. Other channels are possible through their APIs and are scoped per project; we name only tools we build with, and the integrations section describes each one.
Do customers have to repeat themselves when they switch channels?
Not when the system can prove it is the same person, for example a verified WhatsApp number that matches the one on their account, or a link they click from the web chat. The open conversation and its context then follow them. Without proof, a fresh conversation starts rather than risk joining two different people.
How do you connect to the CRM or helpdesk we already use?
Through its API, with a credential issued from your account and scoped to the objects the build needs, for example reading contacts and creating tickets. Each read and write becomes a tool with a schema and an approval rule. If the system has no API, we agree a structured export or a database view during scoping.
What happens when one of our systems sends the same webhook twice?
The second copy is recognised by its delivery id and acknowledged without running again. Senders resend when they did not get a timely response, so duplicates are normal traffic rather than an error, and the check happens before the event reaches any step that could reply or write.
Can one build serve staff in an internal tool and customers on the website?
It can share the engine, not the configuration. Internal and public audiences get separate entry points with their own retrieval filters, tools and guardrails, so staff can see internal sources and customers cannot. In practice it is two assistants on the same layers, which keeps a permissions mistake from crossing over.
Next step
Have a workflow in mind? Let’s scope it together.
Book a free 30-minute strategy call. Bring one process you want to automate and we will talk through scope, integrations and a sensible first step.
