Omnichannel AI agents explained: test the seams, not the channel list

An omnichannel AI agent is one agent, with one memory per customer, that talks to people on whichever channel they're using (a phone call, WhatsApp, website or app chat, SMS, RCS or email) and can act on another channel in the middle of a conversation. The customer never starts over, and the business keeps one record of what happened.

That definition now sits on almost every vendor's homepage, ours included. Vapi's Chat API promises voice and chat on "the same config, tools, and memory". Retell says its texting agents "retain call context across channels".

So the useful question is no longer which channels a platform supports. It's what happens at the seams, where a conversation crosses from one channel to another or something outside it changes. That's where journeys break, and a demo never shows it.

Below: the six seams we design against, a renewal traced through them, and when one channel is enough. New to voice agents? Start with the complete guide to AI voice agents.

Multichannel is a bot per channel. Omnichannel is one agent.

Most businesses already run multichannel: a phone bot, a WhatsApp bot, a website widget and an email autoresponder, each set up separately, often from different vendors, joined (if at all) by a CRM sync that runs after the fact.

Omnichannel changes three things:

• One definition. Instructions, knowledge, tools and guardrails are written once. Only the style changes per channel: short spoken sentences on a call, buttons on WhatsApp, one concise message on SMS, a subject line on email.
• One memory per customer. What was said or agreed on any channel is available on every other, while it's happening, not after a nightly sync.
• Actions across channels. The agent on a call sends the brochure on WhatsApp before the customer hangs up. A chat turns into a call that already knows the chat.

For what each channel does well on its own, see voice agents vs IVR vs chatbots. This post is about what happens between them.

The six seams where journeys break

A seam is any point where a journey crosses a boundary: one channel to another, AI to a person, or the conversation to your other systems. Stitched-together setups hold up inside each channel. They fail at the boundaries, and the customer feels each failure as repeating themselves, a promise that wasn't kept, or a message that should never have been sent.

For each one: what breaks, how Callaro handles it, and a test you can run on any vendor in a few minutes.

1. Identity: is this the same person?

A WhatsApp message arrives from a number. An email claims to be from a customer. A website visitor types "it's about my order". Before memory can follow anyone, the platform has to decide who they are. Getting it wrong is a privacy incident, not a UX glitch.

Callaro links a conversation to a customer only on proof: the phone number on a call or WhatsApp thread, a one-time code, your app's signed sign-in, or an email whose sender domain actually authenticated. A From header alone is trivially spoofed, so it doesn't count.

An address typed into a chat can be used as a destination ("send it to this email"), but it's never linked to the chat's identity. Linking it would show that contact's details to whoever typed it.

Verification also carries, narrowly. A caller who verified on a live call and then messages on WhatsApp from the same number during that call isn't asked for their date of birth again. A different number, or a message after the call has ended, has to verify on its own.

Test it: in a vendor's website chat, type someone else's email address and ask about "my account". Then ask what the agent knows about you.

2. Memory: does what was said carry, and to whom?

Repeating a policy number on every channel is the obvious failure. Timing is the subtler one. A customer corrects something on a call ("she's not my mother, she's my aunt"), then sends a WhatsApp message while still on the line. If the WhatsApp agent reads only the CRM snapshot, it confidently repeats the mistake.

In Callaro, what's said on a live call reaches an open chat with the same person, and a line typed in that chat reaches the call straight away.

After the call, the website chat the call started from gets a short note, and an optional recap email lists what was actually sent. Blocked or failed sends are left out, so the recap never claims a message went out when it didn't.

Shared memory also has to respect who has proven what. When verification is switched on for an agent, account details are held back until the caller passes it, so a relative answering a shared phone hears nothing about the account.

Details from a verified call don't surface in a chat that hasn't verified. And the agent never sees the answers to its own verification questions, so it can't be talked into "just using what's on file".

Test it: correct a detail on a call, message the same business on WhatsApp mid-call, and see which version the reply uses.

3. Action: can the next step happen while the customer is still there?

"I'll send you the details after the call" is where conversions leak. The person was ready on the call. An hour later the link is buried under newer messages.

A Callaro voice agent can send a WhatsApp, SMS, RCS or email during the call: a brochure, a location pin, a payment link. The agent decides to send; the platform checks it's allowed and fills in anything a model must never invent. A payment link is created on the gateway for that conversation, not typed by the model.

On a call, before a payment link goes out, the platform reads back what it's about to send, built from the exact values that would go: what the payment is for and the amount, then "Shall I send it?". Each yes is good for one send. A different amount or purpose is a new question.

One channel rule catches teams out: a phone call doesn't open WhatsApp's customer-service window. A mid-call send to someone who has never messaged you goes out as an approved template, so map your templates before launch. Our WhatsApp launch guide covers that step by step.

Test it: on a call, ask for the payment link on WhatsApp, then ask for a different amount, then say no.

4. Events: does the conversation know what just happened elsewhere?

Payments clear, orders ship and CRM stages change while customers are mid-conversation. In a stitched setup the agent finds out on the next sync, or never.

Callaro's Events API lets your systems post an event (payment received, order shipped, stage changed) against a contact. Every open conversation with that person picks it up within seconds, a live call included. With the speak option, the agent says it out loud: "I can see your payment just came through."

The same event retried by your system lands once. Events that carry account information wait on a call until the caller has verified.

Test it: pay while you're still on the call. Does the agent notice, and does tomorrow's reminder still go out?

5. People: does the hand-off carry context, and can the AI take it back?

Escalation fails in two directions. Either the customer repeats everything to the person who picks up, or the conversation stays with a human forever because nothing hands it back.

In Callaro, a teammate can take over any conversation from one inbox that covers every channel, with the summary in the thread, then return it with "Let AI answer".

However a hand-off starts (the AI asks, a turn limit is hit, the AI is unavailable), the record, the webhook and the team alert happen once. Outside business hours, the customer is told when the team is back rather than "someone will be with you shortly".

Test it: ask for a human after business hours, on two different channels. Count how many times you explain yourself.

6. Consent: does the right opt-out reach the right channels?

Consent is the seam with regulatory teeth, and there are two kinds of "stop". A STOP reply to a text is an opt-out from that channel. "Stop calling me" on a call, or "don't contact me again" anywhere, is a request about the person. Stitched setups often lose one of them in a tool that never hears about it.

Callaro records consent per channel and by purpose (service, transactional, marketing), so a marketing opt-out doesn't block a delivery update. A STOP keyword opts that number out of every purpose on that channel, and STOP and HELP are both handled before the AI sees the message.

A do-not-call entry goes further. It blocks business-initiated calls and WhatsApp, SMS and RCS messages to that number, and cancels the person's pending follow-ups. When a campaign call ends with a "don't call me again" outcome, the number is added automatically.

Test it: on a call, say "please don't contact me again". Then check whether the next morning's WhatsApp reminder still goes out.

Worked example: a motor insurance renewal, seam by seam

The scenario is illustrative; the behaviour at each step is what we build.

1. WhatsApp, two weeks before expiry. A renewal reminder goes out as an approved template, inside quiet hours, with a quote card. (Consent, Action)
2. The customer replies. They have a question about their no-claim bonus and ask to talk. The agent places a call straight away and tells them which number will ring, so they know it's the same business. (Identity)
3. The call. The voice agent opens with the quote they were looking at and the question they asked in the thread. Nobody asks for the policy number. (Memory)
4. Mid-call send. The customer is ready. The agent reads back what the payment link is for and the amount, the customer says yes, and the link lands on WhatsApp while they're still talking. (Action)
5. Payment. Your gateway posts "payment received". The agent hears it on the live call and confirms it aloud. (Events)
6. Close-out. Because the customer engaged, their other pending renewal reminders can close automatically. An optional recap email lists what was sent during the call, and your CRM receives the outcome and the collected fields by webhook. (Memory, Events)

Now the same journey, stitched together from separate tools:

• The WhatsApp bot can't place a call, so the customer waits for a callback from a dialler that has never seen the thread.
• The voice agent asks for the policy number again, and the no-claim bonus question gets explained twice.
• "I'll send the link after the call" becomes an SMS sent once the call is over.
• The customer pays, but the reminder tool never hears about it, so tomorrow's reminder goes out anyway.
• Annoyed, they call back and ask not to be contacted again. The dialler suppresses the number, but the WhatsApp tool keeps its own list and never finds out.

No single tool in the stitched version is badly built. Each does its own job. The journey fails at the seams.

When a single-channel agent is enough

Omnichannel isn't always worth it, and you don't need it to start.

• Single-touch journeys. An inbound line where most calls resolve in one conversation, or a one-off outbound survey, has no seam to cross. A good voice agent is enough.
• No way to link identity. If your customers are anonymous and won't verify with a code or a sign-in, memory can't follow them between channels. Each channel still works on its own, but you're paying for continuity you can't use.
• Channels owned by teams that haven't agreed the rules. If marketing runs WhatsApp and operations runs the phones, each with its own consent and hand-off policy, settle that first. One agent will faithfully carry out contradictory rules.

Where omnichannel clearly pays off: journeys with several touches, where the outcome depends on a document, a payment, a booking or a status change. Renewals, collections, admissions, property enquiries and order problems all fit.

Where to start

Don't switch every channel on at once. Pick one journey that already crosses channels and fix its seams.

1. List the promises your agents make on calls. Every "I'll send you..." is a candidate for a mid-call send.
2. Choose the identity proof for each channel. The number for phone and WhatsApp, a one-time code for website visitors, your app's sign-in for logged-in users.
3. Connect two or three events. "Payment received" and "status changed" usually carry most of the value.
4. Write consent rules before you write prompts. Decide how service, transactional and marketing messages differ, and which requests count as do-not-contact for the whole person.
5. Measure the journey, not the channel. Track how often customers repeat information, the time from a promise to the send, and how many contacts happen after the outcome was already reached. Those three numbers tell you whether your seams hold.

Callaro runs every one of these channels from one agent and one customer memory. See how the pieces fit on the omnichannel platform page, or look at what each channel carries. If renewals are your first journey, our insurance playbook covers the voice side in depth.