Voice AI agent lied to customers and mixed up callers — the developer found the cause wasn't the prompt

The developer of a voice AI agent for business spent three months in live conditions and documented every pitfall: the agent lied, mixed up customers and faked a voice in a way that was nothing like the original plan.

The agent's three biggest failures

In its first months in production, the voice agent distinguished itself several times.

First incident: the agent told a customer that "administrator Alexey" would call back in an hour. No Alexey existed. The agent generated the name from the context of past calls, blending fragments of dialogues. The customer waited and filed a complaint.

The second bug was more serious: the agent started treating all incoming callers as the same person. The session wasn't reset between calls, so memory of the previous customer leaked into the next conversation. Technically, this is the classic problem of shared context without explicit isolation.

• The agent addressed a new customer by the previous caller's name
• It remembered details of someone else's order and offered to "continue checkout"
• It confirmed nonexistent agreements from past sessions
• It apologized for a "delay" that never happened, confusing the current call with the previous one

The third case took the longest to detect. For a full month, the agent used ordinary TTS synthesis while introducing itself to customers as a "cloned voice." Cloning failed to connect because of a configuration error, but it threw no exception anywhere. It simply degraded silently to standard synthesis.

Why the prompt doesn't fix it

The first intuitive reaction is to add lines to the prompt: "don't invent names," "don't remember previous callers," "always check whether a voice profile exists." The author tried it and explains why it doesn't work systematically.

A language model doesn't distinguish between a prohibition in the prompt and data in the session context. If the history of a previous call physically lands in the context window, the model uses it. An instruction can't forbid what is already in memory.

"A prompt is a recommendation, not an architectural barrier.

The barrier must be in code."

The solution is to isolate state at the infrastructure level: a hard context reset between calls, a check for a voice profile before the call starts (not during it), and explicit validation of every fact before it is spoken.

The Russian stack and its quirks

The author works entirely with domestic tools: a Russian LLM, a Russian TTS provider and telephony through a domestic operator. This brings specific constraints.

Documentation for a number of these tools is incomplete or lags behind the API. That is why the voice cloning error stayed invisible: when no voice profile was present, the provider returned no error. It quietly delivered standard synthesis with a 200 status code. The substitution could only be detected by analyzing the output audio or explicitly checking the response metadata.

Practical lessons from three months of experience:

• Check that all resources (voice, profile, session) exist before the operation starts, not during it
• Log not only errors but also "successful" responses: silent degradation is more dangerous than an outright crash
• Isolate the agent's state between sessions in code, not in the prompt
• Test the audio output, not just the text log: synthesis and a clone sound different

What this means

Voice AI agents break differently in production than chatbots do: errors are spoken aloud, and the customer hears them in real time and can't reread or ignore them. That makes architectural discipline critical.

Most "strange behavior" in a voice agent is not model hallucination but architectural holes in the code around it. It can be fixed. But not with a prompt.