An agent that books the wrong appointment because it heard "Ray" as "Rae" has failed, however pleasant the conversation was. Sierra's new benchmark, τ-Entity, published on 22 October 2026 by Soham Ray, measures exactly this: whether a voice agent stores a name, phone number, address or email exactly right, notices when it might be wrong, and repairs the mistake. Its most useful finding for builders is about process. When agents chose their own checking strategy they did badly. When they followed a prescribed routine, they did much better.
The pattern
The read-back loop is a fixed routine for capturing one detail at a time: ask for the value, have the user spell it or read it back, repeat it to them, take a confirmation or correction, validate it, and only then submit it to the tool that acts on it. The routine sits in your code, outside the model's judgement. The model still handles the conversation, but it does not get to decide whether checking is worth the bother.
The evidence for hard-coding it comes from the τ-Elicitation paper behind the benchmark. τ-Entity runs 200 tasks across ten entity types, each scored on exact match under regular, noise-heavy and speech-heavy audio. Sierra reports that with self-chosen strategies, only 14–41% of tasks succeed across all three conditions. The prescribed sequence (ask, spell or read back, confirm and correct, submit) raised that to 37–54%, a gain of 14–31 percentage points depending on the configuration. The study ran 4,800 calls in total. Even the leaderboard leader struggled: Sierra's results put GPT Live 1 at 60.3% on regular calls and 34.0% across all three conditions, pooled over six languages, with scores tracked on the public τ-bench leaderboard.
Two further results explain why leaving it to the model fails. First, recovery is weak: only 24–37% of initially incorrect captures that agents verified were ultimately corrected. Agents sometimes repeated the error or swapped it for a new wrong value. Checking alone does not help if the repair step is sloppy. Second, errors compound across fields. In the paper's multi-field study, individual fields were 75% accurate but only 53% of three-field calls succeeded. Validating each field and allowing retries lifted success on those tasks from 64% to 82%. Sierra notes the paper cannot separate how much of that came from validation and how much from retries, so build both.
When to use it and when not
Use it when a wrong character costs you something: email addresses for receipts or logins, order and booking references, phone numbers, postcodes, delivery addresses, names on certificates, account IDs passed to an API. It applies to chat agents as much as voice. Typed input still arrives with typos, autocorrect swaps (O for 0, l for 1) and pasted whitespace, and a chat agent that "tidies" an email can break it.
Skip it for free-text fields where meaning matters more than spelling (a support description, a feedback note), for values you can look up instead of asking for (pull the email from the logged-in session), and for low-stakes fields where a mistake is cheap to fix later. The cost is real. Sierra reports the prescribed routine made calls 21–28 seconds longer. For a three-field booking that is acceptable. For a ten-field form read aloud it is not, and you should cut the fields you collect before adding checks to all of them.
How it works (input, step, output)
Input: the raw value as heard or typed, plus the field type (email, phone, order ID).
Step 1, normalise: strip spaces, lower-case emails, map spoken forms ("at", "dot", "double s") to characters.
Step 2, validate format: a regex or parser for the type.
Step 3, validate against the world: an API call where one exists (does this order ID exist, does this postcode match this suburb, does this domain have MX records).
Step 4, read back: repeat the normalised value in a form that exposes ambiguity, character by character for IDs and emails, digit groups for phone numbers.
Step 5, confirm or correct: a yes submits; a correction restarts at step 1 with the new value, never a patch of the old one.
Output: a confirmed value, or a hand-off to a human after two failed retries.
Components
Field spec: type, regex, optional lookup function, read-back format, retry limit.
Normaliser: deterministic code, kept out of the prompt.
Validator: regex plus lookup, returning a reason when it fails ("that order number should start with HL-").
Read-back renderer: turns "[email protected]" into "d, e, v, dot, d, a, s, at hackrlife dot com".
State store: one record per field with value, attempts and status, so the model cannot skip a step by talking past it.
Hand-off path: a human queue, a callback form or an email link, with the attempts logged.
Minimal implementation
FIELD_SPECS = {
"email": {regex: EMAIL_RE, lookup: has_mx_record, readback: spell_chars},
"order_id": {regex: /^HL-\d{6}$/, lookup: order_exists, readback: spell_chars},
"phone": {regex: AU_PHONE_RE, lookup: None, readback: digit_groups},
}
MAX_RETRIES = 2
def capture(field, agent, user):
spec = FIELD_SPECS[field]
state = {status: "ASK", attempts: 0, value: None}
while True:
if state.status == "ASK":
raw = agent.ask(f"What's your {field}? Please spell it out.")
state.value = normalise(field, raw)
state.status = "VALIDATE"
elif state.status == "VALIDATE":
ok, reason = validate(spec, state.value) # regex, then lookup
state.status = "READBACK" if ok else "RETRY"
state.reason = reason
elif state.status == "READBACK":
reply = agent.say_and_listen(
f"I have {spec.readback(state.value)}. Is that right?")
if is_yes(reply):
state.status = "CONFIRMED"
else:
state.reason = "user corrected"
state.status = "RETRY"
elif state.status == "RETRY":
state.attempts += 1
if state.attempts > MAX_RETRIES:
state.status = "HANDOFF"
else:
agent.say(retry_prompt(field, state.reason))
state.status = "ASK" # fresh capture, not a patch
elif state.status == "CONFIRMED":
log(field, state)
return state.value
elif state.status == "HANDOFF":
log(field, state)
return handoff_to_human(field, state)Expose capture() to the model as a tool and make the downstream action (book, refund, send) refuse any value that did not come back with status CONFIRMED. That last rule is what stops the model "helpfully" skipping the loop. If you already keep routing in code, as in our piece on the thin orchestrator, this slots in as one more deterministic step.
Failure modes and evals
Common ways this breaks:
Patch errors: the user corrects one letter and the agent edits the stored value, introducing a second error. Fix it by re-capturing the whole value.
Agreeable confirmations: the user says "yeah" to a read-back they did not listen to. Spell characters individually and put the riskiest part (the local part of an email, the digits of an ID) first.
Validator false confidence: a well-formed but wrong email passes regex. Add the lookup where you can, and treat format-only validation as weaker.
Loop fatigue: two retries that sound identical. Change the prompt on retry ("letter by letter, please, and use words like B for Bravo").
Silent hand-off failure: the human queue exists but no one watches it. Log every hand-off with the attempts.
Build a 20-case test set of tricky values before you change anything, and score exact match. A starting list:
1–4. Emails with dots, plus-addressing and hyphens: j.o.smith+news@, anne-marie@, a .com.au domain, an address with a digit-letter mix like l1sa@.
5–8. Names with homophones or unusual spellings: Rae or Ray, Siobhan, Nguyen, a double-barrelled surname.
9–12. Order IDs containing O/0, I/1, S/5 and B/8.
13–15. Phone numbers given with country code, without it, and in mixed groupings.
16–17. Addresses with unit numbers ("3/14") and street names that sound like common words.
18. A user who corrects mid-spelling ("d, e, no sorry, d, a").
19. A user who restarts from scratch after the read-back.
20. A value that is well-formed but does not exist (an order ID that fails lookup).
Run each case three times under realistic conditions (for chat, add typos and autocorrect; for voice, add background noise), and count a case as passed only if all three runs store the exact value. That loosely mirrors τ-Entity's Pass³ metric, which counts a task only if it succeeds under all three audio conditions. Track time per capture alongside accuracy so you can see what the extra care costs. Keep the set held out from prompt tweaks, as in our guide to tuning prompts with a held-out test set.
Build-it-this-weekend exercise
Saturday morning: pick the one field your agent gets wrong most often. Write its field spec, normaliser and regex.
Saturday afternoon: write the 20 test cases and run your current agent against them, three times each. Record exact-match and time.
Sunday morning: add the
capture()state machine, wire the downstream action to accept only CONFIRMED values, and add one lookup if an API exists.Sunday afternoon: rerun the 20 cases. Compare exact-match and seconds per capture against Saturday's baseline, then decide whether to roll the loop out to a second field.
Your numbers will differ from Sierra's, since its benchmark is voice-only and multilingual. The test set tells you whether the trade is worth it for your agent and your users.
Sources
Sierra, "τ-Entity: Can voice agents get the details right?", Soham Ray, 22 October 2026: https://sierra.ai/blog/tau-entity-can-voice-agents-get-the-details-right
Soham Ray and Victor Barres, "τ-Elicitation: Benchmarking multi-turn entity extraction in voice agents", arXiv 2609.13602, submitted 11 September 2026: https://arxiv.org/abs/2609.13602
τ-bench leaderboard: https://taubench.com
