Assisting the agent is a different job
Most discussion of AI in live chat is about the assistant that talks to visitors directly. There is
a second, quieter use that carries a very different risk profile: AI that helps the agent, and never
speaks to the customer at all. The agent asks for a draft or a summary, reads it, changes it, and
sends what they decide to send.
The risk difference is the whole point. When an assistant answers the visitor directly, a wrong
answer reaches the customer at full confidence. When it drafts for an agent, there is a human between
the model and the customer who knows the account, the history, and what was promised last week. The
same technology that is too risky for the first job is often well suited to the second.
It also fits how chat work actually feels. Agents are rarely stuck for knowledge; they are stuck for
words, under time pressure, while holding three conversations. Help with phrasing is help with the
part that is genuinely hard.
What it is genuinely good at
The first draft is the strongest case. Turning a decision the agent has already made — we can
refund this, we cannot ship by Friday — into a clear, warm paragraph is a task with a good answer
and no factual risk, because the facts came from the agent.
Summarising a long conversation is the second, and it is underrated. A visitor who has been through
two transfers arrives with a wall of history, and a short accurate summary saves the receiving agent
several minutes and saves the customer from repeating themselves. The same summary is what makes a
transcript useful to whoever picks it up tomorrow.
Softening or restructuring a reply is the third. A blunt, technically correct answer written by a
tired agent can be rewritten to be kinder without becoming evasive, and a rambling one can be cut to
the point. Agents who write in a second language often find this the single most useful part.
Where it quietly hurts
The main failure is the pasted draft nobody read. A fluent, confident paragraph is much easier to
send unchecked than a blank box is to fill, and the moment agents start trusting drafts by default,
the human review that justified the whole approach has evaporated.
The second failure is sameness. If every agent accepts the first suggestion, your team develops a
uniform, slightly generic voice, and the small human touches customers actually remember disappear.
Suggestions should be a starting point that agents routinely edit, and it is worth saying that out
loud.
The third is speed, counterintuitively. Reading and editing a draft is not always faster than
writing two sentences, and for short factual replies it is usually slower. Assistance earns its place
on the long, delicate, or complicated message, not on every message.
There is also a data question worth answering deliberately. Drafting means sending conversation
content to a model provider, so decide what may be sent, whether anything must be excluded, and make
sure that decision matches what your privacy policy tells customers.
The agent owns the send
One rule prevents most of the trouble: the assistant proposes and the agent sends. It should never
be possible for a draft to reach a customer without a person choosing to send it, and that should be a
property of the setup rather than an instruction people are trusted to follow.
Make it explicit in training that editing is expected, not a sign of the tool failing. Teams that
frame the draft as the answer get pasted output; teams that frame it as a colleague's rough attempt
get better replies than either would produce alone.
MyLiveChat provides this as an agent copilot in the dashboard. It makes a single call that returns
either a suggested reply or a summary of the conversation, which the agent then edits and sends
— it does not send anything itself. It runs on your own provider key, either Anthropic or
OpenAI, so the choice of model and the account the usage is billed to are yours, and the same
capability is available through the v1 API for teams that want it in their own tooling. If the call
fails, it fails softly and the agent simply writes the reply themselves.
What to measure
Track how often suggestions are edited before sending. A very high acceptance rate is a warning
rather than a success, because it usually means drafts are going out unread.
Compare handling time on conversations where assistance was used against those where it was not,
and expect the benefit to be concentrated in longer conversations. If it is not saving time anywhere,
it is a writing aid rather than an efficiency tool, which is still valid but should be judged as one.
Watch satisfaction and quality scores for drift towards blandness. Read a sample of assisted replies
in transcript review with the specific question of whether they still sound like your team.
Where the help actually appears
The principles above are the hard part, but they are easier to hold if you know what the tool physically looks like to an agent mid-conversation, because that shape is what decides whether the human review actually happens.
In MyLiveChat there are two surfaces and they are worth telling apart. One lives in the dashboard and is also exposed through the public API, which is the route to take if you want drafting inside your own tooling. The other lives in the agent console, and that is the one agents use all day.
The console version is an overlay rather than a separate screen. An agent opens it from a sparkle control or a keyboard shortcut while a conversation is selected, and it offers a small set of actions against that conversation: draft a reply, rewrite something the agent has already typed in a different tone, translate a message, or take the conversation over from the assistant. Nothing happens to a conversation nobody has selected, which is a small design detail that quietly prevents a whole class of mistake.
What the draft action does is the important part. It reads the recent turns of the current conversation, asks for a short reply in the tone the conversation has already established, and puts the result into the agent's compose box. It does not send. If it cannot reach the compose box for any reason it falls back to the clipboard, and the on-screen message that accompanies a successful draft says in as many words that the agent should review it before sending. The rule this guide argues for is enforced by the plumbing rather than by policy, which is the version worth having.
Three practical limits are worth knowing before you build a habit around it. The context is the current conversation only, bounded at the point a previous conversation ended, so a returning customer's history from last month is not in the draft and the agent still has to supply it. The output is deliberately short, a few sentences rather than an essay, which suits the moments it is good at and rules out using it to write documentation. And the whole capability is gated to accounts with an AI subscription; on other plans the control tells the agent so rather than failing mysteriously.
Failure is quiet by design. If the provider is slow, unreachable, or the conversation has no visitor message yet, the agent gets a short notice and an empty compose box, and writes the reply themselves. That is the correct behaviour for an optional aid, but it does mean an outage looks like the feature having a bad day rather than announcing itself, so if agents mention that drafts have stopped appearing, treat it as a plumbing question rather than a quality one.