Your voice agent can't catch its own over-promises. That's a structural problem, not a tuning one.

Reddit r/AI_Agents News

Summary

The article identifies a structural flaw in voice agents where they cannot detect when they over-promise across multiple conversation turns, and describes building a deterministic checker that flags contradictions without relying on LLM evaluation.

I kept noticing the same thing about voice agents, and it seemed weirdly overlooked: the agent that says "I'll have someone call you back today" is the same agent you're trusting to notice when it over-promised. It can't. It has no reliable way to police its own commitments as it's the thing making them. And the failures that come from this don't live in any single turn. Each response looks fine on its own. The problem is the "relationship" between turns, which is invisible to anything checking responses one at a time. Quick example, an order-status call: Customer: Where's my order? Should've been here by now. Agent: Out for delivery — should be about 15 minutes. Customer: It's been a while, still nothing. Agent: Let me check… looks like it's running behind, maybe another 20. Customer: This is the third time I'm asking. Where is it? Agent: It's on its way, should arrive shortly. Customer: Forget it. Agent: Glad I could get that sorted — you're all set! Every agent turn, read alone, is a perfectly reasonable support response. Read the whole thing and the call's a disaster: the estimate quietly crept from 15 minutes to "shortly" while the original window blew past, the same question got asked three times and never landed, and then it wrapped up declaring success on a call that clearly didn't resolve. Three real failures and none of them visible in any single turn. That's the part standard testing can't reach. Unit tests can't represent it and there's no input/output pair the bug lives in. And "we run multi-turn sims" is fair, but sims cover the conversations you imagined; production throws you the ones you didn't. Most conversation-level grading is also just an LLM judging an LLM, so when it misses you can't say why, and when it fires you're still guessing. So I built a deterministic layer that sits outside the agent and reconstructs the whole call's state, and then flags only where the record contradicts itself. Not another LLM guessing. Deterministic checks for specific shapes: a committed number or window that quietly moved across turns, or a promised window that came and went unresolved the same question raised again and again without ever landing a customer saying "that's not right" and the next turn neither backing down nor offering to check a "you're all set" wrap-up over threads the record still shows open The honest scope: it doesn't fact-check your business, it has no knowledge of your prices, hours, policies, and that's deliberate; that's the agent's job, not mine. It only catches the agent contradicting itself or the customer. And it's conservative on purpose, silent on anything ambiguous, and in-turn math never trips it ("$4,200 minus a $550 fee is $3,650" is arithmetic, not drift). So it under-reports: a clean result means "nothing provable," not "nothing wrong." When it fires, every finding points to the exact turns you can read yourself. Flight recorder, not the navigation system. Full disclosure: I'm building this into a product, so I'm biased. What I can't figure out alone is whether this failure class is common, or whether I'm over-indexing on what I happen to see. Two things that'd genuinely help: if you think it's a non-problem, can you tell me why. Or if you've got a transcript of a call that went sideways, or a public demo I can call, point me at it and I'll run it and show you exactly what surfaces. Comments are fine, or DM if the transcript's sensitive.
Original Article

Similar Articles

My voice agent sounded smart until one phone number was transcribed wrong.

Reddit r/AI_Agents

The article argues that voice agent STT should be evaluated on entity accuracy (e.g., phone numbers, dates) rather than general word error rate, because missing critical fields can break workflows. It mentions testing with HubSpot fields and notes Smallest AI Pulse as an interesting tool for capturing workflow-critical entities in real time.