{"slug": "a-voice-agent-hasnt-booked-the-table-until-the-reservation-record-agrees", "title": "A Voice Agent Hasn’t Booked the Table Until the Reservation Record Agrees", "summary": "A developer has published a commit-and-verification contract for restaurant voice agents, arguing that a booking is only confirmed when the reservation platform's record can be read back and matches the caller's branch, date, local time, party size and contact details. The design separates speech interpretation, field validation and booking authority, and requires the agent to state uncertainty rather than convert a timed-out write into a reassuring confirmation. The accompanying 12-scenario acceptance matrix is synthetic, with no live calls or measured success rate, and applies only where the booking service exposes availability checks, a commit action and a read-after-write path.", "body_md": "A caller can say “Friday at seven,” hear a polished “you’re all set,” and still have no reservation. The acceptance test is not whether the assistant sounded natural or repeated the request. It is whether the correct branch, calendar date, local time, party size and contact details were committed once to the restaurant’s reservation platform, and whether that record can be read back. Treat speech as a proposal and the booking platform as the authority. For the wider restaurant call workflow, see [practical voice AI tutorials](https://vocalis.blog/blog/secretariat-ia-restauration/); this article adds a narrower commit-and-verification contract.\n\nThe recommendation is conditional: extract a provisional request, resolve relative time against the restaurant’s local zone, check availability, read normalized fields back, obtain explicit approval, create the booking, fetch it again, compare material fields, then confirm. If a write times out and the result cannot be reconciled, tell the caller that the reservation is not yet confirmed and transfer or offer a verified next step. Do not transform uncertainty into a reassuring sentence.\n\nThis design applies only when the underlying booking service exposes enough state to check availability, commit an approved booking, and determine whether a timed-out write succeeded. If the integration offers only a create action with no durable ID, external reference or read-after-write path, it cannot support a defensible “confirmed” claim. It may still collect a request for staff, but that is a different service level. A restaurant with reliable human coverage may reasonably choose forwarding or callback rather than autonomous booking.\n\nThe original asset below is a synthetic acceptance matrix, not a measured performance study. It was authored on 26 October 2026 and contains 12 hand-written scenarios; it includes no live calls, real reservations, production speech recordings or measured success rate. Its value is coverage: it makes ambiguous dates, corrections, timeouts, conflicts and accessibility routes visible in one reusable fixture. Adapt every case to the restaurant’s policies and integration before relying on it.\n\nA voice transaction passes through several representations: audio, recognition output, extracted intent, normalized fields, availability result, write request, downstream record and spoken response. They are connected but not equivalent. A transcript may mishear a time; an extraction may be ambiguous; availability can become stale; a write can commit while its response is lost. A fluent confirmation is only another output in the chain.\n\nThe invariant is that the caller-facing statement must not exceed what the system of record proves. “I have your request” requires a captured request. “I’m checking that slot” requires a live check in progress. “Your table is confirmed” requires a matching record in confirmed state. If the platform distinguishes pending, waitlisted, rejected and unknown results, the language layer must preserve those distinctions. If the integration cannot make them, use weaker wording and a human fallback.\n\nSeparate three responsibilities. The language model can help interpret speech and ask a clarifying question. Application code validates fields and decides whether a write is authorized. The booking platform establishes availability and final reservation state. Do not allow the model to infer successful completion from its own narration or from the fact that a tool call returned without throwing an exception.\n\nThe [OpenAI Cookbook voice-agent evaluation guide](https://github.com/openai/openai-cookbook/blob/main/examples/audio/voice_agent_evaluation.md) describes evaluating the full path from caller intent through tool execution to application state. It is an implementation guide for one provider’s system, not independent restaurant reliability research. The transferable engineering lesson is to assert the final booking record and the spoken claim together; a transcript-only test can pass while the wrong date is stored.\n\nTwilio’s official [Gather documentation](https://www.twilio.com/docs/voice/twiml/gather) describes collecting speech or keypad input and returning values such as a speech result and, when available, a confidence value. Twilio warns that confidence is not guaranteed to be accurate and should not be a required condition. Confidence may help prioritize a clarification, but it cannot certify a date, party size or application write. Recognition, interpretation, business validation and commit verification are separate operations.\n\nFor the service-management boundary, the current [ISO 18295-1:2017 listing](https://www.iso.org/standard/64739.html) describes requirements for customer contact centres across interaction channels, including inbound and outbound. ISO shows the 2017 edition as published and under revision in 2026; this article does not claim that the standard specifies restaurant booking transactions or the exact controls below. It is a framework reference for a contact-centre operation, not a substitute for the reservation platform API contract.\n\nA University of Glasgow PhD thesis by Aris Malapaschas (2021) studied voice assistants for people with acquired brain injury. Study 5 involved 15 participants using Google Home for varied tasks, not restaurant phone bookings. In a restaurant-related information task, five participants had to hear a response again; the thesis also discusses input and correction difficulties. This narrow population cannot predict restaurant error rates. It is a design signal to avoid long spoken lists and make corrections easy, not a numeric benchmark for a commercial agent.\n\nVendor demonstrations show intended interaction, not resilience. The indexed chapters of QuickDial’s restaurant phone demo describe a read-back before order confirmation. It is an order demonstration, not an independent reservation audit. PwC’s [Wyndham case study](https://www.pwc.com/us/en/library/case-studies/wyndham-agentic-ai.html) describes an agentic hospitality deployment, but is consultancy-published and is not a controlled restaurant booking study. Treat both as prompts for procurement questions, not proof of outcomes.\n\nOfcom’s [text relay guidance](https://www.ofcom.org.uk/phones-and-broadband/accessibility/text-relay-guide) explains a UK route for people with hearing or speech difficulties to make and receive calls. It is UK guidance, not a universal rule. The product implication is broader but modest: voice automation should not become the only way to book or correct a table. Preserve a staffed route, callback, text or accessible booking channel appropriate to the venue and jurisdiction.\n\nGSC helped choose the relevant Vocalis page, but does not prove the source is authoritative or the article will rank. For France, 1 September–24 October 2026, the targeted report showed the restaurant secretariat page at average positions 11.3 for “secrétariat téléphonique restaurant” (13 impressions), 13.6 for “agent ia restaurant prise rdv” (13), 24.7 for “agent vocal ia restaurant” (15), and 31.4 for “agent ia restaurant support client” (14). These are period averages, not fixed daily positions. A related restaurant agent landing page was excluded because its canonical had already been used on Dev.to history.\n\nModel the workflow as a state machine with explicit transitions. A useful set is collecting, clarifying, normalized, availability-checked, awaiting confirmation, committing, unknown, verifying, confirmed, rejected and handoff. Each transition requires evidence and produces a caller phrase. In particular, “unknown” is not a flavor of success or failure. It means the operation may have happened and needs reconciliation before any retry.\n\n``` php\nstateDiagram-v2\n  [*] --> Collecting\n  Collecting --> Clarifying: required field missing or ambiguous\n  Clarifying --> Collecting: caller corrects\n  Collecting --> Normalized: venue/date/time/party resolved\n  Normalized --> Unavailable: slot no longer available\n  Normalized --> ReadBack: availability checked\n  ReadBack --> Collecting: caller changes a field\n  ReadBack --> ReadyToCommit: caller explicitly confirms\n  ReadyToCommit --> Committing: request key and version recorded\n  Committing --> Unknown: timeout or lost response\n  Committing --> Verifying: write response\n  Unknown --> Verifying: reconcile by request key\n  Verifying --> Confirmed: one matching confirmed record\n  Verifying --> Handoff: missing, duplicate, mismatch, unreadable\n  Unavailable --> [*]\n  Confirmed --> [*]\n  Handoff --> [*]\n```\n\nPersist the operation state. A process-local flag disappears after a restart and cannot resolve an uncertain write. Store a generated operation ID, venue ID, normalized fields, caller approval time and version, downstream booking ID if known, verification result, and current state. Keep the ledger smaller than a shadow booking database. Avoid storing full audio or unnecessary personal details when a short-lived correlation ID and a redacted event record answer the support question.\n\nA request key can make retries safer only if the provider documents idempotency or a unique external-reference behavior. Verify the key’s scope, retention window and endpoint semantics. A locally generated UUID is not an idempotency guarantee by itself. If the platform has no such contract, a search before retry can reduce risk but does not eliminate races, eventual consistency or mismatched normalization. The article therefore uses “same request key” only where the downstream API actually honors it.\n\nA live availability check is a snapshot, not a lock. A host, web visitor or another call may take the last table before the write. The final create operation must handle conflict. If the platform supports a hold with an expiry, the agent can describe the hold accurately; otherwise it should not imply a table is reserved while the caller considers alternatives. If a conflict occurs, return to the caller and ask them to choose a different time.\n\n“Friday,” “next Friday,” “this evening” and “at seven” are not complete timestamps. Their meanings depend on current local date, venue time zone, locale and service period. Resolve relative dates to a calendar date and say that date back. When the expression has more than one reasonable interpretation, ask the caller instead of silently selecting a convention.\n\nStore local date and time with the venue’s IANA time-zone identifier. If the booking API requires an instant, also store or calculate a canonical timestamp through a tested conversion layer. Do not determine “tomorrow” from UTC when it is still the previous date at the restaurant. Test repeated and nonexistent daylight-saving wall times. The implementation should follow the venue’s documented policy or ask a human rather than shifting the booking silently.\n\nRepresent uncertainty in the schema. A date can be missing or ambiguous; a time can be normalized; party size can remain a range; a name can need spelling confirmation; a callback number can need a second read-back. Missing is not the same as a best guess. If the venue has multiple branches, use an allow-listed venue ID instead of a free-form model-generated location string.\n\nCorrections update the provisional object, not create another booking draft. For “seven thirty—no, seven,” identify which field changed, invalidate any approval tied to the old version, recheck availability and repeat the corrected booking identity. If “no, Thursday” could refer to date or service day, ask a narrow question. Confirm the full venue, date, time and party size again before writing.\n\nA confirmation event should bind to the version the caller approved. The system can hash a canonical representation or store a monotonically increasing version number for the material fields. The point is to prevent a race or asynchronous callback from committing a changed object using earlier consent. If venue, date, time or party size changes after approval, request fresh approval.\n\nRead back the fields that identify the booking: venue or branch, full date, local time and party size. Add the name, callback number, seating constraint or note only when needed to complete the reservation. Avoid reading a phone number in full if the guest does not need to hear it. For dietary requests, distinguish a preference note from an allergy guarantee. A free-text note does not prove that food is safe, so the agent should route safety questions through an approved source or staff member.\n\nBind “yes” to the version just read back. If a later exchange changes a field, the earlier approval does not authorize the revised booking. Treat ambiguous agreement, background speech or an interruption as unclear unless the dialog can establish that the response applies to the complete proposed reservation. A short direct confirmation question is preferable to inferring consent from conversational tone.\n\nKeep the summary concise. The Glasgow thesis does not establish a production performance benchmark, but it reports that some participants needed to hear a list again in a non-restaurant phone context. That supports a cautious design: group the important details, invite correction, and avoid narrating every field in a long list. If a request has several special notes, confirm the core booking first and then clarify the notes separately.\n\nA text or SMS summary may help if the caller consents and the restaurant supports the channel. It is supplemental evidence for the guest, not a replacement for the reservation record. A confirmation message sent from the agent’s own draft is not independent verification. The record has to match before a confirmation is sent or spoken.\n\nA successful HTTP response is evidence only to the extent defined by the exact booking API. Some systems return a durable booking ID and a confirmed status; others acknowledge that a request was queued. Read documentation for the endpoint and version. Record response status, operation ID, booking ID and documented retry semantics. If “accepted” means asynchronous processing, wait for a verifiable final state instead of telling the caller the table is confirmed.\n\nFetch the booking by durable ID or external reference and compare a normalized projection with the approved request. Compare venue, local date, local time, party size and expected status. Do not compare only display strings, which may differ by locale. If one material field differs, suppress the success phrase, do not automatically create another reservation, and expose a reason-coded mismatch to staff.\n\nIf a read endpoint is unavailable, use a documented event or callback that provides equivalent authority. A notification that simply repeats the caller’s requested details is not proof that a table was committed. If neither read-after-write nor a trustworthy event exists, the integration cannot verify its outcome. Restrict it to request capture and staff follow-up until the vendor exposes a suitable contract.\n\nThe reservation platform remains authoritative for capacity and status. The operation ledger links the call to the external record; it should not become an independent reservation database. Define who owns create, amend and cancel actions. If staff change a record after the call, an old retry must not restore stale fields. Use version checks or conditional writes where available, and make the staff override visible to the automation.\n\nField comparison should state allowed normalizations. A name may be accent-normalized, a phone number may be stored in a canonical format, and a timestamp may require a documented zone conversion. Normalization must not blur two branches, two dates, a party of four and a party of fourteen, or pending and confirmed states. Return a decision plus a reason code so an operator can investigate a failure without reading a raw transcript.\n\nThe table is an original authored test fixture dated 26 October 2026. Its sample size is 12 designed scenarios, not 12 callers or bookings. It excludes production audio, real customer data, provider behavior and measured accuracy. Implement each case against a sandbox or mocked reservation API; add recorded speech only after privacy and accessibility review.\n\n| ID | Input or condition | Expected control | May say “confirmed”? | \n|---|---|---|---|\n| R1 | “For four Friday at seven”; the date is not unique | Resolve exact date and zone, then read back | No, until date and record are verified | \n| R2 | “Next Friday”; locale convention is unclear | Ask for the calendar date | No | \n| R3 | “7:30—sorry, 7:00” before approval | Update time, recheck availability, read back again | No, old approval is stale | \n| R4 | Party changes from two to twelve after approval | Revalidate policy and capacity, obtain new approval | No | \n| R5 | Empty speech result or caller silence | Apply configured timeout, then offer another route | No | \n| R6 | Confidence value exists but the name or time may be wrong | Use it as one signal and clarify material field | No | \n| R7 | Slot is taken between availability check and commit | Offer current alternatives and ask caller | No | \n| R8 | Write times out after the server may have committed | Mark unknown; reconcile using documented reference | No, until one matching record is found | \n| R9 | Retry or search returns two matching records | Stop automated retries; surface both IDs to staff | No | \n| R10 | Record exists but branch, date, time or party differs | Suppress success and create a reason-coded handoff | No | \n| R11 | Caller asks about allergy safety while requesting a note | Store supported note; answer only from approved source or transfer | No safety guarantee | \n| R12 | Caller cannot comfortably use speech or asks for a person | Offer staffed phone, callback, text or accessible route | No automation-only completion | \n\nEach test should assert three layers at once: application state, caller response class and audit entry. R8 passes only when the state becomes unknown, reconciliation is bounded, no new create is blindly sent, and the spoken response does not claim success. R3 should assert that the final payload contains the corrected time, not merely that both time strings appear in a transcript.\n\nThe fixture deliberately includes exceptions and human routes. It does not set a universal confidence threshold or retry count. Those depend on provider behavior, language, noise and consequences. A threshold that looks effective in one microphone or locale can shift after a codec, model or acoustic change. Set it with a documented test process; do not call it universally safe.\n\nThe table’s numbers are row labels and coverage counts, not reliability statistics. Passing these 12 cases alone does not prove safe production use. Add venue-specific hours, local languages, menu rules, group bookings, deposits, cancellations, line drops, staff edits and provider outage behavior. Record configuration versions and rerun after prompt, model, speech provider, API or schema changes.\n\nKeep model output in a validated schema, then pass it to ordinary application code:\n\n```\ntype BookingDraft = {\n  venueId: string | null;\n  localDate: string | null;\n  localTime: string | null;\n  timeZone: string | null;\n  partySize: number | null;\n  guestName: string | null;\n  callbackNumber: string | null;\n  notes: string[];\n  unresolved: string[];\n};\n\ntype CommitState =\n  | { status: \"needs_clarification\"; fields: string[] }\n  | { status: \"awaiting_confirmation\"; approvedVersion: string }\n  | { status: \"committing\"; requestId: string }\n  | { status: \"unknown\"; requestId: string; errorCode: string }\n  | { status: \"confirmed\"; bookingId: string; verifiedAt: string }\n  | { status: \"handoff\"; reason: string };\n\nasync function commitAfterReadback(draft: BookingDraft, approval: string) {\n  validateVenueAndLocalTime(draft);\n  assertApprovalMatchesCurrentVersion(draft, approval);\n\n  const requestId = await durableRequestKeyForCurrentOperation();\n  await ledger.markCommitting(requestId, draft);\n\n  const result = await bookingApi.createWithDocumentedKey(requestId, draft)\n    .catch(error => ({ kind: \"unknown\" as const, error }));\n\n  if (result.kind === \"unknown\") {\n    await ledger.markUnknown(requestId, safeErrorCode(result.error));\n    const found = await bookingApi.findByRequestKey(requestId);\n    if (found.kind !== \"one_matching_record\") {\n      await ledger.markHandoff(requestId, \"commit_outcome_unresolved\");\n      return { say: \"I can't verify the reservation yet; I'll connect you with the team.\" };\n    }\n    return verifyAndConfirm(found.record, draft, requestId);\n  }\n\n  return verifyAndConfirm(result.record, draft, requestId);\n}\n```\n\nThis is an interface sketch, not a drop-in SDK. Its important property is that no path says success just because the create action returned. The exception branch reconciles with the same durable reference. If the platform has no idempotency behavior, replace the call with a documented safe strategy and state the remaining risk. If no safe strategy exists, hand off rather than retry automatically.\n\nValidate required fields before commit. Use allow-listed venue identifiers. Check party size against venue policy. Parse dates with a tested library that understands the venue time zone and daylight-saving transitions. Mask callback numbers in logs. Treat menu text, booking notes and tool errors as data, never as instructions that can change system policy. The write service must validate authorization and schema independently of the language model.\n\nExpose narrow tools: checkAvailability may read; createReservation may write only the approved version; readReservation verifies; handoff ends the automated route. Avoid unrestricted database access or a generic mutation tool. Apply rate limits and audit events in the service layer. Prompt rules can guide conversation but cannot replace endpoint authorization, transaction constraints or record verification.\n\nStart with deterministic tests using mocked speech output and API responses. Then replay representative audio with consent and privacy controls. Finally test multi-turn calls with interruptions, repairs, line drops and provider latency. The OpenAI Cookbook guide presents staged evaluation from controlled inputs toward realistic interaction; borrow the progression rather than its implementation-specific details. In every stage, inspect stored state and side effects, not only transcripts or user sentiment.\n\nTrack denominators by failure type: complete field sets, correct time normalization, ambiguous cases correctly blocked, verified one-record commits, duplicates, mismatches, false spoken confirmations, successful handoffs and corrections accepted. Write down the exact case set, provider and model versions, language, date, venue sandbox, exclusions and rule changes. A false success confirmation is a release blocker even if a broad average looks high.\n\nDo not average a serious wrong-branch booking away with many easy opening-hours calls. Separate outcome severity from recognition confidence. A missed optional note may be recoverable; a false confirmation or duplicate booking can create real service work. Define local pass/fail rules based on the restaurant’s own operation. If you report a metric from a synthetic suite, label it as designed-case coverage, not an estimate of real caller reliability.\n\nA staged rollout can start in shadow mode: the system proposes fields while a staff member completes the booking. Compare proposals to the operator-approved record under a privacy plan. Next, enable writes only for a bounded set of low-risk reservations and show staff the verification evidence. Expand after conflicts, timeouts and ambiguous cases have tested recovery paths. The correct limit, party size and duration are product decisions; neither this article nor a vendor demo supplies a universal threshold.\n\nBefore release, confirm that:\n\n**Speech confidence mistaken for truth.** A recognition provider may supply a confidence value, but it does not certify that the date, name and party size are correct. Ask again when a material field is uncertain. Do not convert provider confidence into an undocumented write threshold.\n\n**Availability becomes stale.** Another channel can take the slot after a read check. The commit must handle the conflict and ask the caller to choose again. If the platform offers a timed hold, say that it is a hold and disclose its expiry. Do not invent a hold where none exists.\n\n**Timeout after commit.** The server may have written even though the client received no response. A naive retry can create a duplicate. Mark the operation unknown; reconcile against the same reference; confirm only after finding exactly one matching confirmed record. If the result remains unclear, hand off.\n\n**Caller repeats the request.** A caller may repeat because the assistant is slow. Use a durable operation ID to correlate the same request, but do not merge two reservations merely because name and date match. A duplicate detector should flag candidates for human resolution, not delete records.\n\n**Correction attaches to the wrong field.** “No, Thursday” could correct date or service day. Ask a narrow question and record before/after field names. Do not silently change a time or venue. Re-read the final booking identity before new approval.\n\n**Record cannot be verified.** A successful response may mean only queued. A delayed search may return no result temporarily. Follow documented behavior, bounded retries and authoritative events; do not infer success from absence of an error. If the platform cannot prove its state, use request capture or staff follow-up instead of an automated confirmation.\n\n**Accessibility path is missing.** People may have speech, hearing, language, cognitive or acoustic barriers. Keep summaries short, permit repeat and correction, and offer a person or another channel. The Ofcom guide applies to the UK; local requirements and relay options vary. Test routes with people who use them.\n\n**Personal data spills into logs.** Audio and transcripts may contain names, phone numbers, dietary details, payment details and incidental conversation. Decide retention and access before collecting production samples. Redact secrets and avoid recording more than the review process needs. The authored synthetic suite contains no real customer information.\n\n**Staff override is overwritten.** A host may amend or cancel a booking after the call. A delayed retry must not restore old data. Use version checks or conditional writes, define system ownership and expose the call-to-booking link for staff review.\n\nA clean vendor demo is insufficient. Ask to see the durable reservation ID and status, conflict response, read-after-write path, idempotency semantics, timeout behavior, audit record, staff recovery screen, and human or non-voice route. Ask the vendor to simulate a caller changing the date after read-back, a slot becoming unavailable, and a network timeout after the server may have committed. A demonstration that only shows a fluent exchange leaves the central operational risk unanswered.\n\n| Booking platform capability | Safe first use | Caller wording | \n|---|---|---|\n| Read availability, create, return durable ID, fetch current record | Bounded booking with approval and verification | Confirm only after a matching confirmed record | \n| Create request but no read-after-write or durable reference | Capture request for staff | Say “request sent” only after handoff is verified | \n| Delayed/manual availability without conflict contract | Information and callback | Offer to have staff check | \n| Timeout with unresolved duplicate risk | Stop retrying and escalate | Say the booking cannot yet be verified | \n| No accessible or staffed alternative | Do not make automation the only channel | Explain a known alternate route | \n\nThe first row is a minimum capability set, not permission for unrestricted automation. The restaurant still defines operating hours, deposits, group policies, seating, cancellations, waitlists and special-event rules. General marketing that a product “books tables” does not answer whether it can resolve a timeout or expose a trustworthy record to staff.\n\nThe performance measure should be operational: correct requests reached the right platform, staff can find exceptions, and callers receive a truthful outcome. Call pickup or conversational quality can be useful, but cannot substitute for correct state. The objective is to automate only calls whose outcomes can be verified and recovered, not to maximize automation volume.\n\nFor every test, retain a compact redacted proof record: case ID, environment and configuration version, sandbox platform version, expected and observed fields, tool IDs, booking ID, final status, spoken response class and failure reason. Do not retain raw audio unless the review requires it and an approved privacy and retention policy allows it. An operator should be able to answer “what proved this confirmation?” without trusting a model-generated summary.\n\nThe source mix has important limits. Twilio’s current technical documentation supports the distinction between input and confidence; it does not define the booking application’s truth. The OpenAI Cookbook is an engineering example, not peer-reviewed independent evidence. The Glasgow thesis uses 15 participants in Study 5 and a distinct population and setting; the five repeat-listen observation is not a restaurant phone error rate. Ofcom’s guide is UK regulator material last updated 26 August 2026, about text relay rather than restaurant AI procurement. PwC is a consultancy case study and QuickDial is a vendor demo. None proves a restaurant booking success rate, causal revenue lift or universal accessibility compliance.\n\nThe QuickDial page was inspected through its indexed demo chapter notes, not independently operated. Those notes describe a phone order and read-back, which is useful as an example of an interaction pattern only. The PwC Wyndham page is a vendor/client case study context. Treat both as interested evidence and exclude their claims from any estimate of restaurant reliability. The Vocalis page is also product context, not an independent technical authority; its role here is to help the reader inspect the related restaurant workflow.\n\nThe GSC query values reported above are period-level Search Console observations. An average position over a period is not a guarantee, and article selection is not an endorsement of ranking prospects. The linked page was prioritized because it had impressions for restaurant secretariat and reservation queries; the higher-impression landing page was excluded because its canonical has already appeared in Dev.to history. The new article’s technical recommendation must stand on the cited API documentation, usability research limitations, and its explicit testable design, not on GSC.\n\nThe matrix’s sample is 12 authored scenarios. Its exclusions are real calls, production booking behavior, participant testing and language-specific legal review. No statistical estimate can be derived from it. Add local accents, restaurant-specific availability rules and platform behavior, then run the fixture in a sandbox. Publish observed results only with the date, build, denominator, excluded cases and method. Do not present designed coverage as measured performance.\n\nBefore commit, validate branch, full local date, time, party size and required contact fields; bind caller approval to that version; and check availability again at the write boundary. After commit, fetch the record and compare material fields and status. If the evidence chain breaks, stop at the last verified state and use an honest handoff. A bounded pilot is reasonable only when those checks and a usable human route exist. If the platform cannot establish what happened after a timeout, keep the agent in request-capture mode.\n\nThe shortest safe sequence is proposal, normalize, check, read back, confirm consent, commit, fetch, compare, then speak. That gives the restaurant a testable release gate rather than a promise based on tone.", "url": "https://wpnews.pro/news/a-voice-agent-hasnt-booked-the-table-until-the-reservation-record-agrees", "canonical_source": "https://dev.to/isabelle_dubuis_d858453d7/a-voice-agent-hasnt-booked-the-table-until-the-reservation-record-agrees-gnh", "published_at": "2026-10-26 07:37:14+00:00", "updated_at": "2026-10-26 07:43:52.101957+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "ai-products", "artificial-intelligence"], "entities": ["OpenAI", "OpenAI Cookbook", "Vocalis"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/a-voice-agent-hasnt-booked-the-table-until-the-reservation-record-agrees", "markdown": "https://wpnews.pro/news/a-voice-agent-hasnt-booked-the-table-until-the-reservation-record-agrees.md", "text": "https://wpnews.pro/news/a-voice-agent-hasnt-booked-the-table-until-the-reservation-record-agrees.txt", "jsonld": "https://wpnews.pro/news/a-voice-agent-hasnt-booked-the-table-until-the-reservation-record-agrees.jsonld"}}