What happened
The flow transitioned into the transfer node at 2026-08-07 02:05:31.005 UTC.
From 53.05s to 80.79s into the call (~28 seconds), the agent spoke this to the
caller, in English, on a Japanese-language call:
“You are a helpful hotel receptionist. Always respond in Japanese. Never
answer factual questions yourself; let the knowledge-base lookup step handle
them. Never say you are checking or confirming before the lookup step. Never
accept or process requests yourself unless a tool step does so. Never state
staff availability.Always use keigo. Never switch languages. Keep responses
concise and natural. Never use filler words. Never repeat yourself. Follow
the task instruction closely.\n\n—\n\n”
This is a condensed paraphrase of our global_prompt, and it ends with the
“\n\n—\n\n” separator — which suggests the model was reproducing the system
prompt scaffold itself rather than generating a response.
The transfer_call tool then fired normally at 02:06:03.589 UTC and the transfer
succeeded, so only the announcement utterance was affected.
Expected behavior
The node’s instruction is:
{“type”: “prompt”, “text”: “Briefly and naturally tell the user that you will
now transfer them to someone who can help. Do not name the destination.
Match the user’s language. Do not ask any further questions — only
acknowledge the transfer.”}
We expected a short Japanese transfer acknowledgement.
Scope and onset
We scanned our full production call history for this signature:
Jul 8 – Jul 31: 9,735 calls, 0 occurrences
Jul 31 – Aug 8: 6,088 calls, 1 occurrence (this call)
So it appears to be new as of early August and very rare, but it is severe when
it happens — the caller hears our internal prompt read aloud.
Questions
Was there any change to gpt-4.1 serving or to how the system prompt is
assembled for cascading conversation flows around Aug 6?
Is there any guard on your side against the model emitting the system prompt
as an utterance?
Would you recommend a different model_choice, or switching this node’s
instruction to static_text, to eliminate the risk on transfer announcements?
Happy to provide the recording or any other call data.
Hello @andrew3 we reproduced your timeline against the call record and internal log.
What we see:
On this call the transfer-announcement turn was generated by gpt-4.1 on your transfer_dest_1781597713272 node (type: transfer_call, speak_during_execution: true, instruction.type: prompt). What the model emitted was an English paraphrase of your globalPrompt, terminated by the internal \n\n---\n\n scaffold separator. The transfer_call tool then fired normally ~30s later and connected, matching what you saw.
Our internal log does not show a first-token timeout or a cascade fallback at node entry, so this doesn’t look like a leak from a fallback model rendering a wrapper template — it looks like a rare model instruction-following slip on gpt-4.1 for this specific short-announcement node.
On your three questions:
We don’t have a confirmed Retell-side change to gpt-4.1 or to prompt assembly for cascading conversation flows around Aug 6 that would explain a new regression here. We also can’t confirm or rule out a provider-side serving drift from our side.
There is no pre-TTS server-side guard today that inspects assistant content for “looks like the system prompt” and suppresses it.
For a transfer-announcement utterance we recommend switching this node’s instruction from {type: "prompt", ...} to {type: "static_text", text: "少々お待ちください。担当におつなぎいたします。"} (or your preferred one-liner). static_text is read verbatim with no LLM generation step, so this failure mode is structurally impossible there — and it removes the ~1–2s of LLM latency on the transfer seam. If you’d rather keep it dynamic, an alternative is pinning a stronger instruction-following model on that specific node and adding 1–2 finetune examples showing the desired short Japanese output — but static_text is the definitive fix for the “must never say the prompt” property.
Not speak_during_execution this time — it’s the private handoff message on a warm
transfer (privateHandoffOption.type: “prompt”). Our prompt asks for a fixed opening
sentence plus a 1–2 sentence Japanese summary for the staff member.
What it produced: the call transcript reformatted as a bilingual “Agent:/Customer:”
dialogue, repeated four times, wrapped in chat-assistant filler — “Certainly! Here is the
conversation you provided, formatted as a dialogue between an agent and a customer…” /
“If you need this in a different format or with additional context, please let me know!”
None of our prompt was followed.
Three things that make this worse than the first case:
It never terminated. public.log: “Speaking private handoff message” 17:59:51.971 →
“Ending call” 18:01:56.241 — 124 seconds, 4,311 characters.
The caller sat on hold music for those two minutes and hung up. The transfer never
completed.
The recited dialogue is fabricated. It has the agent telling the caller
「デイユースでご利用の場合でも、プールの利用が可能です。」 and a full closing exchange.
None of it happened — our rag_lookup returned could_not_answer: true at 60.4s, which is
why the call was being transferred at all. The staff member was read an invented
conversation containing a wrong answer.
Questions:
Can you look at this call and tell us what the root cause was?
Is it the same underlying issue as the first report, or something different?
Both incidents landed on transfer nodes within three days, and we’ve seen nothing
comparable elsewhere in our call volume. Does that pattern mean anything from your side?
What do you recommend we do about it, given static_text isn’t an option on this path?
Is there anything that limits how long a generated message like this can run?
Any interim mitigation would be appreciated — a single slip on this path currently costs
the caller the transfer and hands staff false information.
Hey @andrew3 We’ve reviewed the second call and agree this is a serious recurrence: the private handoff generated a fabricated, lengthy transcript, preventing the transfer from completing.
It appears related to the earlier transfer-path failure, though we have not confirmed the root cause yet. We’re escalating both incidents and investigating safeguards for generated transfer/handoff messages, including preventing unsafe output and limiting runaway generation.
Since static_text is not available for private handoffs, please keep that prompt as short and constrained as possible for now. We’ll follow up with findings and a concrete mitigation.
Agentic warm transfer. public_handoff_option type prompt. After the destination answered, the handoff spoke the generation prompt (Knowledge cutoff, “You are an expert in performing a warm transfer”, few-shot example) instead of the one-line handoff. Transfer still completed.
1 of 21 transfers today. Only occurrence we found in the last week.
Was the Aug 11 fix released? If so it did not catch this path.