Quick answerA customer messaging your chat agent and calling your voice agent at the same time is a different problem from a customer switching from chat to phone sequentially, and it needs its own detection logic: identify the customer across channels in real time (not after the fact), recognize that two active sessions exist simultaneously rather than assuming the second one is a continuation, and either merge the two into one coordinated thread or explicitly tell the customer you have noticed both and ask which one to continue.
Why simultaneity is a distinct problem from a channel switch
Keeping Conversation Context When a Customer Switches from Chat to Phone solves for a customer who finishes with one channel and picks up on another, sequentially. The system there can safely assume the earlier session has ended and carry its context forward. Simultaneous, concurrent conversations break that assumption entirely: both sessions are live at once, so treating the second one as a continuation of the first (or ignoring the first entirely) produces two different agents giving the customer two different, uncoordinated answers to what is really one situation. This is also distinct from recognizing a repeat-contact "frequent flyer" pattern, which is about noticing a pattern across separate sessions over time, not two sessions that are open at the same moment.
Detection has to happen during the conversation, not after
Most identity-matching systems are built to reconcile sessions after the fact, useful for reporting and analytics but too slow to catch a live simultaneity problem. Concurrent-session detection needs to run at session start: as soon as a new channel session begins, check whether an existing session for the same identified customer is already active, using whatever identifier is available on that channel (an account lookup on chat, caller ID or an account PIN on voice). If a match is found while the first session is still open, that is the trigger, not a downstream analytics job.
Decide: merge, or explicitly split
Once a live match is detected, two reasonable responses exist, and which one is right depends on what the customer is doing in each channel. If both conversations are clearly about the same issue, the cleanest fix is coordinating them behind the scenes into a single logical thread, similar in spirit to the coordination layer used when a single request spans multiple specialist agents, except here the coordination is across channels rather than across specialist domains. If the two conversations are about genuinely different things (a billing question on chat, a technical issue on the phone), it may be correct to let both proceed independently, but the agent on each channel should still be aware the customer has another session open, so neither one assumes exclusive attention.
From the team
We build production AI systems for startups.
LLM pipelines, RAG, and agent workflows that hold up under real traffic — not just in the demo.
Avoid the two most common failure modes
The first failure mode is silent duplication: both channels proceed as if the other does not exist, and the customer gets two different answers to what turns out to be the same question, which damages trust in either channel giving a reliable answer at all. The second is over-correction: aggressively merging every concurrent session regardless of topic, which can strand a customer mid-conversation on one channel when the system prematurely folds it into an unrelated thread on the other. Tune detection to the actual topic overlap, not just the fact of simultaneity.
What this requires operationally
This depends on a shared, real-time customer identity layer across channels, which is a bigger infrastructure lift than most channel-specific features. If that shared layer does not exist yet, the same channel-by-channel variance in behavior described in AI Agent Behavior Varies by Channel: Bug or Acceptable Design Tradeoff? is worth resolving first, since concurrent-session detection is only as good as the identity matching underneath it.
FAQ
How common is true simultaneity versus a fast sequential switch? Less common than sequential switching, but not rare, particularly for account-critical issues (a payment failure, a locked account) where a customer reasonably tries every channel at once rather than waiting for one to respond.
Should the agent tell the customer directly that it detected another open session? Generally yes, briefly and without making it sound like a warning, since customers are often unaware they have two channels open at once and a short acknowledgment prevents confusion when answers start to diverge.
Does this apply to internal agents as well as customer-facing ones? Yes, an employee opening two simultaneous sessions with an internal AI tool has the same duplication risk, though the identity matching is usually simpler since internal users are typically already authenticated.