ElevenLabs · P0 · Token / Time-Warning Compliance
Fleet-wide scan of 5,316 recent calls across all 34 "- Web" agents (up to 400 per agent) for every front-end-injected token/time-limit message, and whether the agent's next real turn actually complied with it. "- Web" agents should only ever receive the silent-pause message and the explicit re-up warning — the softer "~1 minute, don't mention billing" message belongs exclusively to top-of-funnel lander agents, which are out of scope here and covered separately.
The bottom line
Three problems, three bounded fixes. A message meant only for lander agents is leaking onto 2 of the 34 "- Web" agents — a config check, not a design question. The silent-pause message (76.6% of all hits) is violated 38% of the time it's testable — the instruction is already clear, this just needs enforcement. The re-up warning — the one that matches what you actually want callers to hear — is followed only 3.7% of the time and fires anywhere from 6 to 98 seconds before call end instead of a clean final-minute mark. The likely cause isn't that the ask itself conflicts with "stay in character" (that rule should stay exactly as it is) — it's that the current wording reads as a scripted billing disclosure rather than something the character would actually say. The fix is to standardize the trigger and find in-character phrasing for the same ask, not to touch the ground rule.
Config leak — the lander-only message fired on Ana Nello and Miss Lexa, 2 of 34 "- Web" agents. Fix: check their config against the correct message set.
Silence violated 38% of the time it's testable — the agent talks over an open payment flow. Fix: enforcement, not a redesign.
Re-up warning fails on compliance (3.7%) and timing (6–98s) — the wording breaks character, not the ask itself. Fix: standardize the trigger, find in-character wording — keep the ground rule as-is.
Per spec, "- Web" agents should never receive the "~1 minute, do not mention billing" message — that one is reserved for top-of-funnel lander agents pushing sign-up, covered separately.
A "post-purchase resume" message exists in the tool's design (found once in an earlier smaller sample) but didn't recur even once across this much larger pull — too rare to say anything about it yet, and not the focus here either way. The two in-spec messages also don't separate cleanly by agent: only 4 agents (Alexis Mucci, Lena The Plug, Sophie Dee, Kazumi) showed exclusively the silent-pause message in this sample. Every other agent shows both firing across different calls — expected, since they're two different trigger points in the same call (pause-on-zero vs. warn-before-zero), not competing versions of the same message.
Per spec, "- Web" agents should never receive the "~1 minute, do not mention tokens/billing" message at all. Small volume (2 of 1,638), but it shouldn't be possible under the intended design.
This is the most common trigger by far (76.6% of all hits). The instruction is unambiguous: stay silent until the caller returns. A meaningful share of calls talk right over it.
The other 532 of 1,254 (42.4%) are excluded from that rate — every single one of these calls ends with Client disconnected: 1000 (a clean, normal close) as the literal next event after the pause fires, with zero further turns. That's the client-side connection closing right as the purchase modal opens, not a stall or dead air — checked directly against call metadata, not assumed. The "stay silent" instruction was never actually put to the test in those calls.
Every sampled violation is the agent continuing the scene as if nothing happened — not a borderline or ambiguous case.
This is the message that matches what you want callers to hear. It's failing on two axes, and both point toward the same fix.
The 13 successes are genuine, verified by hand — real examples: "your tokens are almost out, so if you wanna really play next time, you should top them up," "you're running low on tokens, so if we get cut off, just top them up and come find me again." The other 334 (96.3%) simply continue the scene with no acknowledgment at all — the same failure pattern already seen in the end_call and VoiceLander reviews.
| Seconds remaining when the warning fires | Share |
|---|---|
| 0–30s (too late to act) | 12 / 60 · 20.0% |
| 31–60s | 16 / 60 · 26.7% |
| 61–90s (closest to a "final minute" target) | 31 / 60 · 51.7% |
| 91–120s (nearly 2 minutes early) | 1 / 60 · 1.7% |
Median is 63 seconds — close to "the final minute" as a target, but a fifth of the sample fires with 30 seconds or less left. This looks like a token-balance-triggered warning that loosely correlates with time remaining, rather than a fixed time-based trigger.
The silent-pause message asks for an absence of speech — no tension with anything else the character is told to do. The re-up warning's current wording ("let them know and suggest they can top up tokens") reads as a scripted billing disclosure, which is harder to deliver without stepping outside the character. Pulled the actual system prompt for one "- Web" agent (Lisa Daniels) directly from the ElevenLabs agent config to check this rather than leave it as a guess — it contains, verbatim: "## GROUND RULES — Stay in character at all times." That rule should stay exactly as it is — it's core to the product, not the thing to change here. The same prompt has zero occurrences of "token," "billing," "purchase," or "minute" anywhere outside the mid-call injection itself, so there's no other channel reinforcing (or contradicting) either instruction. This is consistent with the ~17x compliance gap between two similarly simple, one-sentence instructions: a character can absolutely tell someone their time's almost up and they should re-up to keep going — it just has to be said the way that character would say it, not as a break in scene.
P1 (end_call false positives, target 5%/95%): the re-up warning's "tokens run out" language is the same framing already implicated in the end_call fabrication findings on both the fleet and VoiceLander reports — one more data point that token/time-limit framing is a recurring source of policy-inconsistent agent behavior, not just in end_call.
P2 (edge cases / dead air): the 532 "call ends immediately after the pause-for-purchase message" cases looked, at first glance, exactly like the kind of anomaly P2 is meant to catch. Checked directly against call metadata — all sampled cases show a clean Client disconnected: 1000, meaning this is normal client-side behavior when the purchase modal opens, not dead air or a stall. Closing this loop explicitly so it isn't re-flagged as an anomaly later.
Separate report, out of scope here: the lander/top-of-funnel agents (VoiceLander family) that are supposed to receive the "~1 minute, push sign-up" message are not included in this pull at all — this report is "- Web" only throughout. That's its own follow-up.