A question your console has to keep asking
When an AI assistant answers first and a human takes over later, the console has a problem that sounds trivial and is not: for any given visitor in the list, is the AI currently handling this conversation or not? The answer changes without the agent doing anything, because a handoff can happen while they are looking at somebody else.
The console does not guess this from what is on screen. It asks the server about a specific visitor and gets back a small record: whether an AI session is active, and if a handoff has happened, the reason and a short summary of what the assistant had already established. That summary is the useful part in practice, because it is what saves the agent from asking a question the visitor has already answered.
Knowing how that lookup behaves explains most of the moments where the indicator seems wrong, and all of the moments where it seems slow.
A visitor already talking to a person is never asked about
The first thing the lookup does is check whether it needs to happen at all. If the visitor’s status already says they are in a conversation with an agent, the console answers “not AI” immediately and makes no server call.
This is the right shortcut, and it has a visible consequence: for a visitor who is already with a human, the AI indicator is instant and always negative. There is nothing to wait for and nothing that can fail. If you are testing the behaviour and wondering why one visitor resolves instantly while another takes a moment, this is usually why.
It also means the lookup cost scales with the number of visitors who might have an AI session, not with the size of your visitor list. A busy console full of active human conversations is not generating traffic for this.
The ten-second memory
Answers are cached per visitor for ten seconds. Inside that window the console reuses what it already knows rather than asking again, and a caller can explicitly force a fresh lookup when it needs the current truth rather than the recent one.
Ten seconds is short enough that a handoff surfaces quickly and long enough that scrolling a visitor list does not turn into a burst of identical requests. The practical implication for an agent: the AI indicator is accurate to within about ten seconds, not to the instant. If you are watching a handoff happen in real time, expect a beat before the state changes.
The same window applies to a failed lookup, which is the part worth knowing about. A failure is remembered for ten seconds exactly like a success, so a brief server problem keeps affecting what you see for a moment after it has passed.
Why a failed lookup looks like no AI at all
Every failure path in this lookup produces the same answer: not active. If the console service is unreachable, if the request comes back with an error, if the server cannot say — the record that gets stored says the AI is not handling this chat, with the error text tucked into a separate field alongside it.
For anything reading only the active flag, that makes “we asked and the answer is no” indistinguishable from “we could not ask”. During a service interruption, every visitor reads as having no AI session, which is the same thing the console shows on a perfectly healthy account where AI is simply not involved.
This is a defensible choice rather than a bug. The alternative — showing an unknown state — would put a question mark in front of agents constantly, and the safe failure for an agent is to assume nobody is covering the conversation and pick it up themselves. But it does mean you should not read the AI indicator as evidence about whether AI is working. For that question, use the reporting, which counts conversations rather than sampling a live flag.
It also means a report of “the AI indicator disappeared for everyone at once” is worth treating as a connectivity symptom rather than an AI configuration one.
However many callers, one request
Several parts of the console want this answer about the same visitor at the same time: the list row, the detail panel, whatever is deciding which controls to show. Rather than each of them asking, the first request registers itself and the rest queue up behind it. When the answer comes back, everybody waiting gets it.
The effect is that opening a visitor who is being handled by AI costs one server call no matter how many things on screen are interested. Anything that has subscribed to changes is then told whenever that visitor’s state moves, so the indicator, the panel and the controls change together instead of drifting apart.
When state is deliberately discarded — because a conversation ended, say — subscribers are notified of that too, so nothing is left showing a stale AI badge for a visitor who has gone.
What this means for how you work
Three things follow from all of it. Treat the indicator as recent rather than live: it is accurate to about ten seconds, which is fine for deciding whether to step in and useless for a precise timeline. Do not read it as a health check, because a failure and a genuine no look identical. And when a handoff arrives, read the summary before you type, since that is the field carrying what the assistant already established.
The wider design question — when the assistant should hand over at all, and what it should say when it does — is a configuration decision rather than a console one. Fallback and handoff design covers it, and escalating when a visitor sounds frustrated covers the case where the trigger is tone rather than a failed answer.
How MyLiveChat fits
None of this needs configuring. In MyLiveChat AI chat, the presence lookup, the caching and the request coalescing are how the console behaves out of the box, and there is no setting that changes the ten-second window or the fail-to-negative behaviour.
What you do control is the part either side of it: whether the assistant answers first, when it hands over, and what your agents are expected to do when it does. If your team is still deciding how much of the conversation the assistant should own, when not to use AI in live chat is the more useful place to start than any console setting.