Architecture
One agent. Multiple channels.
A channel is a transport, not a product. Everything that makes an agent useful - its knowledge, its rules, its tools - sits below the channel and is shared by all of them.
The architecture
Most "omnichannel" claims mean several bots that were configured similarly. This one is structural: the agent is the unit of configuration, and a channel is a way of reaching it. Add the phone to an agent that already answers web chat and nothing about its knowledge or behaviour has to be touched.
- Phone / SIPWeb voiceWeb chatWhatsAppTelegramEmail summary
- InstructionsKnowledgeLanguage & voiceDeclared toolsSummary format
Configured once. A channel does not get its own copy of any of this.
- Outbound webhookTool callsEmail summary
Identical regardless of which channel the conversation arrived on.
- CRMCalendarHelpdeskShopERP
What is genuinely shared
| Shared | Not shared |
|---|---|
| Knowledge - one body, maintained once. | Conversation history between channels. A caller who chatted yesterday is a stranger on the phone today. |
| Instructions, rules and limits. | Identity. The web knows whatever your app knows; the phone knows a number, sometimes withheld. |
| Declared tools. | Media. Voice has no way to show a link, an image or a table. |
| Language configuration and voices. | Latency tolerance. Silence on a call is uncomfortable; a two-second pause in a chat is invisible. |
| The conversation summary format and the outbound webhook. | Setup effort. The widget is a script tag; a phone number can need regulatory verification. |
There is no cross-channel conversation memory. Nothing links a web chat to a later phone call from the same person - no shared customer record, no thread. If continuity matters to you, it is your system that has to provide it: match on the phone number or email in the webhook delivery, and hand the context back in through a per-session prompt or a tool.
The channels
Phone
AvailableA number bought in the dashboard or your own trunk routed to bitpull. The channel with the least setup on your side and the most regulation on the platform side.
Website - voice and chat
AvailableThe hosted widget as one script tag, offering spoken conversation, text chat, or both. Same agent as the phone.
Your own application
AvailableCreate a session over REST and join the room yourself. Nothing about the interface is prescribed.
WhatsApp and Telegram
Assisted setupThe same agent and knowledge answering messaging, sharing one minute pool with the other channels. Set up with the bitpull team.
Email summary
AvailableNot a conversation channel - an output. Every finished conversation summarised to an address, configured per agent.
Designing one agent for several channels
The shared layer is a feature until an instruction only makes sense on one channel. Four rules keep it from becoming a problem:
- Write for the ear, not the eye. Voice is the constraining channel. A prompt that works spoken also works in text; the reverse is rarely true.
- Never assume a medium. "I will send you the link" is a broken promise on a phone call. Say what to do instead.
- Read the channel, do not branch on it. A single agent with a rule for the awkward case beats two agents whose knowledge drifts apart within a month.
- Split only for a real difference in job. An out-of-hours emergency line and a sales chat are two agents. German and English support are one agent with two language configurations.
Why this matters for an integration
Because it changes what you have to build. Your webhook consumer handles one payload shape whether the conversation arrived by phone or by chat - the channel field tells you which, and everything else is the same. Your tool endpoint is called identically. The knowledge you maintain serves all of them.
The work you do once is the mapping into your own systems. The work you do per channel is setup, and it is small: a script tag, or a number.