Waiting speech that remains truthful when tools are slow

TL;DR: Generate waiting speech from observed operation state, with a bounded message budget and a separate verified-answer path. A timeout, accepted request, or canceled local task does not prove the business outcome, so preserve unknown states and reconcile them before promising success or retrying a write.

---

A caller asks to move an appointment. The agent says, "Your appointment is being updated," while the scheduling request is still waiting for acceptance. A moment later the connection times out. The agent has already promised progress it never observed.

The fix is a speech policy with an evidence boundary. Each allowed phrase states only what the system knows now. Acknowledgment, operation status, and verified outcome remain separate message classes, and silence remains a valid choice when the caller has asked to wait quietly.

This guide gives you a runnable policy reducer and synthetic event tests. It does not publish measured response times, customer conversations, or a private implementation of 60db Agent. Its purpose is to make tool delays understandable without turning uncertain execution into confident speech.

As checked on November 9, 2026, HTTP semantics for 202 Accepted distinguish request acceptance from completed processing. Azure's asynchronous-operation documentation provides a concrete status-monitor pattern. Your own tool adapter must establish the equivalent contract for its service.

Table of contents

1. Define what each phrase claims
2. Model observed operation state
3. Implement a bounded speech policy
4. Test delays and completion races
5. Handle timeout and cancellation honestly
6. Evaluate the caller experience
7. Frequently asked questions
8. Make waiting a verifiable behavior

Define what each phrase claims

A waiting message is a statement about the interaction. Even a short phrase can imply that an operation began, that progress occurred, that a result is imminent, or that success is guaranteed. Treat those implications as part of the interface contract.

"I received your request" describes receipt by the agent. "The service accepted the request" describes an external acknowledgment, if that acknowledgment was observed. "The appointment is confirmed" describes a verified business outcome. These phrases need different evidence.

Avoid vague progress verbs when the adapter exposes only pending state. "I'm finishing the update" asserts a stage the application may not know. A truthful alternative can say that the result has not arrived yet, without guessing how much work remains or when it will finish.

Separate acknowledgment from answer

An acknowledgment can reduce uncertainty about whether the agent heard the caller. It does not shorten the tool operation or supply the requested answer. Measure acknowledgment latency separately from useful-answer latency so adding more speech cannot manufacture a performance improvement.

The voice latency benchmark defines those response boundaries. Use the same distinction in evaluation: record when the caller first hears a receipt message and when the caller first hears verified information that advances the task.

A fast acknowledgment can also interfere with the caller's next words. Keep it short, respect interruption, and avoid scheduling a second waiting clip merely because the first clip finished. The message budget belongs to the operation and conversational state, not to the rate at which audio can be generated.

Silence is a policy outcome

If a caller requests silence until completion, preserve that preference for the current operation under a clear interaction contract. Do not treat an idle timer as permission to override it. A user-requested quiet wait can still have a bounded service deadline and a recovery path.

Different callers need different status surfaces. A voice-only interface may require a concise spoken failure or handoff when the operation cannot finish. An interface with a visible status area can keep pending state available without repeatedly speaking it aloud.

For web interfaces, the W3C status-message guidance explains how status changes can be exposed programmatically without taking focus. Apply that guidance alongside your voice policy rather than assuming a spoken clip makes every status accessible.

Use approved templates for high-risk claims

A small set of reviewed templates is easier to test than unconstrained generation for every wait. Let templates receive only safe structured fields, such as the operation class and an observed state. Avoid passing raw tool errors, private identifiers, or speculative model commentary into speech.

A template can still be misleading if its condition is wrong. The application must select it from observed state, and the selector needs tests. Copy review alone cannot prevent "confirmed" from being emitted after an unknown outcome if the state machine collapses those cases.

Use generated wording only where its range is bounded and evaluated. The business outcome should remain a typed fact supplied to the response layer. A language model can explain that fact, but it should not decide that a timeout means failure just to produce a fluent sentence.

Model observed operation state

Start with the smallest state model that matches the actual tool. Useful states include not started, pending, accepted, running, succeeded, failed, canceled, and unknown. A specific service may expose fewer distinctions, and your adapter should preserve that limitation.

Unknown means the application cannot currently establish the outcome. It can follow a lost response, a disconnected stream, an expired polling request, or a crash during reconciliation. It is an epistemic state: it describes your evidence, not necessarily the service's progress.

A tool returning an HTTP success code can also represent an application-level rejection or an accepted asynchronous job. Validate the response body and the documented status semantics before transitioning the business outcome. Network success alone is insufficient.

Keep request and operation identity separate

One business operation can involve several network requests: initial submission, status polling, retry, and reconciliation. A request timeout should not automatically create a new business operation. Retain the operation identifier or durable idempotency key across those requests when the service supports that contract.

A voice turn is yet another identity. The caller can change the conversational topic while an earlier operation continues. The application needs to know whether it should speak the earlier result now, save it for later retrieval, or route it through a human or other approved channel.

Carry a response epoch into every speech request. An operation can remain real after its current spoken explanation becomes obsolete. That allows a new turn to invalidate old audio without pretending the business operation was canceled.

Require evidence for terminal states

A verified success should identify the operation and the resulting business state. A verified failure should come from the service's contract or an authoritative local validation that proves the operation did not execute. A canceled state should identify which layer acknowledged cancellation.

Local task cancellation has narrower meaning than external rollback. The Python asyncio task documentation describes cooperative cancellation behavior in the local runtime. That mechanism does not prove that an external booking or payment was reversed.

Keep the business-state authority outside the speech timer. A timer can decide to stop waiting and begin reconciliation. It cannot infer the final operation state from elapsed time alone.

Version status observations

If the service provides ordered versions or sequence numbers, use them to reject stale status updates. A late "running" event should not overwrite a verified success. If no order exists, define the permitted state transitions from documented evidence instead of applying every arrival blindly.

Do not force every operation into a monotonic percentage. Some workflows retry an internal stage, wait for approval, or expose no useful progress count. A plain pending state can be more truthful than a smooth progress animation with invented numbers.

The observability guide shows how to preserve operation transitions within a turn trace. Keep request transport events, business state, and speech emissions separate so an incident reviewer can see which observation justified each sentence.

Implement a bounded speech policy

The following policy emits at most a configured number of waiting messages. It requires a matching operation and response epoch, uses an injected clock for tests, and keeps terminal outcomes outside the waiting-message path. All text and times in the fixtures are synthetic design inputs.

Save the example as waiting-policy.py and run it with Python 3. It performs no external calls. The code demonstrates deterministic selection and stale-speech suppression; your tool adapter remains responsible for validating operation observations.

from dataclasses import dataclass

WAIT_TEXT = {
    "pending": "I have your request and am waiting for a result.",
    "accepted": "The service accepted the request; I am waiting for its result.",
    "running": "The service reports that the request is still running.",
    "unknown": "I cannot confirm the result yet. I need to check its status.",
}
TERMINAL = {"succeeded", "failed", "canceled"}

@dataclass(frozen=True)
class Snapshot:
    operation: str
    epoch: str
    version: int
    state: str


class WaitingPolicy:
    def __init__(self, operation, epoch, *, started_ms=0,
                 first_wait_ms=1500, gap_ms=5000, limit=2):
        if min(first_wait_ms, gap_ms, limit) < 0:
            raise ValueError("non-negative policy settings required")
        self.operation, self.epoch = operation, epoch
        self.next_at = started_ms + first_wait_ms
        self.gap_ms, self.limit = gap_ms, limit
        self.count = 0
        self.latest = None
        self.quiet = False
        self.invalidated = False

    def observe(self, snapshot):
        if (snapshot.operation, snapshot.epoch) != (self.operation, self.epoch):
            return False
        if snapshot.state not in WAIT_TEXT and snapshot.state not in TERMINAL:
            raise ValueError("unsupported operation state")
        if self.latest:
            if snapshot.version <= self.latest.version:
                return False
            if self.latest.state in TERMINAL:
                return False
        self.latest = snapshot
        return True

    def due(self, now_ms):
        if self.invalidated or self.quiet or not self.latest:
            return None
        if self.latest.state in TERMINAL or self.count >= self.limit:
            return None
        if now_ms < self.next_at:
            return None
        self.count += 1
        self.next_at = now_ms + self.gap_ms
        return {"operation": self.operation, "epoch": self.epoch,
                "version": self.latest.version,
                "text": WAIT_TEXT[self.latest.state]}

    def may_play(self, message):
        return bool(self.latest and not self.invalidated and not self.quiet
                    and self.latest.state not in TERMINAL
                    and message["operation"] == self.operation
                    and message["epoch"] == self.epoch
                    and message["version"] == self.latest.version)


if __name__ == "__main__":
    p = WaitingPolicy("synthetic-job", "response-a")
    assert p.observe(Snapshot("synthetic-job", "response-a", 1, "pending"))
    assert p.due(1499) is None
    message = p.due(1500)
    assert message and p.may_play(message)
    assert p.due(2000) is None
    assert p.observe(Snapshot("synthetic-job", "response-a", 2, "running"))
    assert not p.may_play(message)
    assert p.due(6500) is not None
    assert p.due(12000) is None
    assert p.observe(Snapshot("synthetic-job", "response-a", 3, "succeeded"))
    assert p.due(20000) is None
    assert not p.observe(Snapshot("synthetic-job", "response-a", 2, "running"))
    q = WaitingPolicy("synthetic-job", "response-b")
    q.observe(Snapshot("synthetic-job", "response-b", 1, "unknown"))
    q.quiet = True
    assert q.due(9999) is None
    q.quiet = False
    pending = q.due(9999)
    q.invalidated = True
    assert not q.may_play(pending)
    assert not q.observe(Snapshot("other-job", "response-b", 9, "succeeded"))
    print("Synthetic waiting-speech fixtures passed")

The fixture timings are policy inputs, not recommended production thresholds or measured waiting tolerance. Choose real thresholds from your interaction needs and evaluation evidence. The limit provides a finite speech budget regardless of how long the external operation remains pending.

The policy consumes a budget slot when it creates a message. If synthesis later fails or the message becomes stale, the slot is still spent. That conservative choice avoids retrying filler indefinitely. A different accounting rule needs tests that prove it cannot create an unbounded loop.

Recheck immediately before playback

The may_play method closes a common race: a waiting message is generated, the tool completes, and the old waiting clip becomes ready after the answer. Check the current operation version and response epoch before admitting that clip to playback.

This cannot retract audio already heard. Where your transport exposes a clear or stop control, use it under the response-invalidation policy. Measure the remaining old audio and keep that boundary visible rather than claiming a local cancellation guarantees immediate silence.

The interruption-safe agent guide supplies the larger playback-ownership model. Waiting speech should use the same response identity and cancellation path as substantive speech so it cannot outlive the turn that authorized it.

Keep verified answers separate

The reducer intentionally produces no success sentence. A separate answer path should consume the authoritative result, validate the fields needed for speech, and generate an answer appropriate to the caller's current context.

For a synthetic booking, that can include the confirmed date, time zone, and operation reference under your disclosure policy. If the service reports a conflict, the answer should offer the valid next step rather than stretching a waiting template into a success claim.

A terminal operation does not always mean the caller heard the result. Track answer generation, admission, and playback evidence independently. A call can end after success but before delivery, which creates a communication task rather than permission to repeat the booking.

Validate snapshot inputs

The sample assumes construction from trusted synthetic objects. At a real boundary, validate operation identity, epoch, integer version, allowed state, and any result proof before calling observe. Type annotations do not validate untrusted JSON.

Do not invent service versions from polling order and then claim they represent service order. A local counter can describe observation order, but stale cached responses still need reconciliation under the service contract. Name the field accordingly if producer order is unavailable.

Keep error details out of templates by default. Raw errors can contain internal hosts, credentials, or customer data. Map them into approved categories with a human-readable next step, while retaining protected diagnostic evidence in its owning system.

Test delays and completion races

A happy-path test confirms only that a waiting message can appear. The important tests exercise times when the message should disappear, remain silent, or change its claim because evidence changed.

Use an injected clock instead of sleeping in tests. Advance it to just before the first threshold, at the threshold, and after the budget is exhausted. Deterministic tests make repeated-message defects easier to reproduce than a real-time loop with variable scheduling.

Test the exact caller preference path. Set quiet mode before the first message, while one is being synthesized, and after a message is queued. A preference honored only by the next timer still allows an already queued clip to violate the requested silence.

Completion during synthesis

Create a waiting-message request, then deliver a verified terminal result before synthesis returns. The completed clip must fail its admission check. Repeat with a new response epoch so both operation completion and conversational invalidation paths are covered.

Also test completion after playback begins. The remaining behavior depends on the transport and interaction policy: interrupt the clip, let a short acknowledgment finish, or prioritize the answer at the next safe boundary. Record that chosen behavior rather than leaving it to callback ordering.

The audio chunk guide explains why queued media duration affects this race. A short text template can still become a long stale-audio queue when it is repeatedly synthesized or admitted ahead of the verified answer.

Multiple tools and one caller

When a turn invokes several tools, do not let each tool own an independent filler timer. The caller hears one conversation. A turn-level speech budget can summarize the relevant pending state without producing overlapping acknowledgments from every operation.

Keep operation-specific truth available beneath that summary. If one tool succeeded and another remains unknown, a generic "everything is processing" can hide the completed result or overstate progress. Choose a concise message from the actual task dependency that is blocking the answer.

A result from an optional tool should not delay an answer that is already complete under the task contract. Define required and optional dependencies in the workflow, then measure why each wait occurred. The waiting-speech layer should not invent dependency policy.

Comparison criteria

A check means the evidence permits the stated claim under the tool contract. A cross means that claim needs additional evidence. Read the table as a speech review aid rather than a universal protocol mapping.

Some services can fail before acceptance, so an observed terminal failure does not always establish the accepted column. The row refers to a failure reported for an already accepted operation. Preserve that qualification in your adapter rather than treating the table as a substitute for its contract.

Unknown outcome and retry

Simulate a service committing a write while its response is lost. The application should enter unknown and reconcile by operation identity. It should not immediately speak "that failed" or create a fresh business operation merely to get a cleaner response.

For services with idempotency support, follow the exact documented scope and retention behavior. Stripe's idempotent-request documentation is a concrete example of a retry contract with specific semantics. Do not assume another service uses the same rules because it accepts an Idempotency-Key header.

Keep retry policy outside the wording template. A sentence saying "I will try again" can commit the product to a retry that is unauthorized, unsafe, or unsupported. Decide the permitted operation first, then state that decision truthfully.

Handle timeout and cancellation honestly

A deadline limits how long the caller or application waits. It does not by itself prove that an external operation stopped. When the deadline expires, choose a bounded recovery path and preserve the uncertainty until authoritative evidence resolves it.

In a browser, AbortSignal.timeout() has documented timing semantics, including active-time behavior. Use the runtime's contract when interpreting a timeout and avoid assuming every timeout is a strict wall-clock bound during suspension.

A timeout can also occur at several layers: HTTP request, operation polling, voice turn, or whole call. Name the expired layer in telemetry. Speaking a generic failure after any one of them can misrepresent the state of the business task.

Caller cancellation and business cancellation

"Stop talking" and "cancel the booking" are different instructions. The first invalidates speech. The second requests a business action subject to authorization and the service's cancellation rules. A voice system should not silently translate one into the other.

If the caller interrupts with a new question, preserve the pending operation identity while changing response ownership. Ask a clarification if the new instruction's relationship to the operation is ambiguous. Use the partial-transcript gate so an unstable recognition fragment cannot cancel an operation prematurely.

A cancellation request can itself have an unknown outcome. Keep the original operation and cancellation operation distinguishable, and reconcile the resulting business state before saying the task was canceled. Local network abort is insufficient proof.

Stopping speech invalidates audio; canceling a business operation requires its own authorized contract.

Handle permission loss during a wait

A tool credential can expire or lose permission while the caller waits. Stop repeated unauthorized requests under the service's failure policy, and distinguish inability to query status from a proven failure of the original action. The pending operation can remain unresolved even though the current credential can no longer inspect it.

Choose wording that describes that limitation without exposing credentials or internal access details. The application can say it cannot confirm the result and needs an approved recovery path. It should not promise a successful update or claim the action was canceled because an authorization check failed.

Reauthentication and a new business request are separate actions. Restore access through the approved flow, then reconcile the existing operation identity before deciding whether another submission is needed. A refreshed token does not make a new operation safe if the first submission may already have committed.

Include a synthetic test where acceptance occurs, status access fails, and a later authorized query reveals success. The expected speech remains uncertain until the final observation. This fixture catches systems that translate every tool error into business failure and then create duplicate actions during recovery.

Reconciliation after the call ends

The call can end while a valid business operation continues. Decide who owns reconciliation and how the verified outcome becomes available under the approved communication policy. Do not assume the voice worker will remain alive to finish a background task.

Use the existing durable task or operation system where one exists. Store the minimal identifiers and state needed to query the outcome, with appropriate access and retention. This is a business continuity requirement, not a reason to build a new orchestration platform for one waiting message.

The shutdown semantics guide describes the distinction between stopping media and draining task work. Preserve that distinction so a cleanly ended call cannot erase an unresolved write outcome.

Handoff with evidence

If a human must take over, transfer the verified state and unresolved question. "Request accepted, outcome unknown, reconciliation key available" is more useful than a transcript saying the agent was "almost done."

Keep private payloads out of a spoken handoff unless the caller and recipient are authorized to hear them. The warm-handoff guide provides a useful boundary for minimizing context while preserving what the next operator needs.

A handoff is not a successful business outcome. Track whether the destination accepted the transfer, whether the caller connected, and whether the original task was resolved under the available evidence. Avoid converting every escalation into a success for the dashboard.

Evaluate the caller experience

Evaluate truthfulness at the sentence level. For every spoken status, identify the state snapshot and rule that permitted it. A reviewer should be able to determine whether the words were supported when they were admitted to playback.

Also evaluate interruption and repetition. A phrase can be accurate but disruptive if it repeats after a request for silence or speaks over the caller. Keep message count, total waiting-audio duration, interrupted clips, and stale-clip rejection alongside task outcomes.

Use synthetic service delays to exercise policy paths, then a consented evaluation set for the interaction experience. Mark synthetic delays as test inputs. They do not establish a provider's latency distribution or a population's waiting tolerance.

Keep the latency report honest

Report acknowledgment, verified-answer, and task-completion timings separately. If a policy reduces silence by adding filler, the answer time may remain unchanged. Both facts matter and should appear together.

Include failed and unknown operations in the denominator. A report that contains only completed answers hides the cases most likely to produce misleading speech. The outcome-metrics guide supplies a framework for keeping pending and unverified outcomes visible.

Do not report a subjective trust score without a defined rubric, evaluator population, and actual observations. A clear protocol for listening and disagreement review is more useful than invented precision. Preserve the reviewed phrases and failure reasons so future revisions can be compared.

Review the phrase against its implied promise

For each template, write the evidence it requires and the promise a reasonable caller can infer. "I am checking" may be acceptable after a lookup starts, while "I am finalizing" suggests a later stage. Review these implications using the actual task context, because the same verb can mean different things for a read-only search and a consequential write.

Use counterexamples in the review. Ask whether the phrase remains true if the request is queued, rejected before acceptance, accepted but stalled, completed with a lost response, or canceled only at the local client. A phrase that fails one of its permitted states needs a narrower condition or more precise wording.

Keep the wording library small. Adding a different phrase for every timer tick creates more claims to review and makes repeated speech harder to recognize as the same policy outcome. Variation can sound natural, but it should not imply new progress when no new evidence exists.

Review translations with the same evidence table. A translation can accidentally add certainty, a completion promise, or a time estimate absent from the source phrase. Use native-language listening review for supported locales, and preserve the intended state and uncertainty in the translation brief.

The multilingual evaluation guide helps define that listening cohort. A translated status policy needs semantic review as well as pronunciation review; intelligible speech can still promise the wrong thing.

Separate service polling from speech cadence

A service can require frequent status checks without requiring frequent spoken updates. Keep polling frequency under the service's documented limits, and speech cadence under the caller interaction policy. Connecting every poll response to a new clip makes the conversation depend on network implementation details.

If a response includes a documented retry interval, honor that interval for the request layer. It does not mean the agent should announce a countdown or promise completion when the interval expires. The next poll can return the same pending state.

Deduplicate status observations that contain no relevant change. A new local poll sequence can make an observation newer without adding knowledge. Decide whether a waiting template should repeat under a time budget, and keep that decision explicit rather than treating every new version number as progress.

Backoff also changes what the system knows. After a long period without a fresh status observation, the last known state can be stale. A truthful message can say that the result is not confirmed, while the application resumes polling or reconciliation under its bounded policy.

Keep polling failures distinct from business failures. Authentication loss, a rate limit, and a transient status endpoint error can prevent observation while the original operation continues. The speech layer should not convert a monitoring problem into a claim that the action itself failed.

Service polling and caller-facing speech cadence have separate limits and owners.

Protect the result from a waiting-message backlog

Reserve the substantive answer's path through synthesis and playback. If several waiting clips are already queued, a fast verified result can still sit behind them. Cancel or invalidate obsolete clips under the supported media policy, and measure answer admission after the terminal event.

The policy should not starve the answer by repeatedly refreshing filler. Test a service that completes immediately after each waiting threshold. A new status clip can be permitted when created and obsolete before it is spoken, so the final admission check is part of correctness.

Bound generated audio duration as well as template count where the application can observe it. A small number of unexpectedly long clips can consume substantial conversation time. Use a reviewed text limit and a listening check before adding a more complex runtime controller.

A caller interruption during waiting speech should follow the ordinary input and response-ownership rules. Stop or invalidate the clip as supported, then determine whether the caller changed the task, asked for silence, or requested business cancellation. Those outcomes need different actions.

Build a minimal incident bundle

When waiting speech misleads a caller in a test, preserve the smallest approved evidence bundle: operation transitions, observation times, selected template, response epoch, synthesis completion, playback admission, and the authoritative result. Use synthetic payloads when reproducing the race.

State the observed failure in terms of the boundary. "Pending wording played after success" is more actionable than "the voice sounded confused." It points to stale-audio admission. "Success wording selected from accepted state" points to the selector or tool adapter instead.

Reproduce both the old behavior and the proposed repair with the same event schedule. A fix that merely shifts a timer may hide one race while leaving the underlying stale-message path open. A version and epoch check can be tested across several schedules without depending on exact real-time sleeps.

Keep production incident content out of broad test fixtures unless it has approved handling. The useful reproduction often needs state and timing rather than the caller's words, appointment details, or tool response body. Preserve protected originals only in their authorized system of record.

Judge each status claim against its admission-time evidence, retaining the later authoritative result separately.

Release criteria and rollback

Require a test that no pending or unknown state produces success wording. Require budget enforcement, quiet-mode suppression, stale-epoch rejection, terminal-state suppression, and outcome reconciliation. Run the deterministic reducer tests before a live voice trial.

Use the voice regression suite to preserve the delayed-callback and lost-response fixtures. A model or voice change should not bypass the same policy because its acknowledgments sound more natural.

Keep templates and selection policy versioned together. Roll back both when a wording change alters the evidence it implies. A template that says "accepted" needs the acceptance condition even if the older template only claimed local receipt.

---

Frequently asked questions

What should a voice agent say while a tool is slow?

It should state only observed facts, such as receipt of the request or the absence of a verified result. Use a bounded message budget and approved wording. Avoid implying progress, acceptance, completion, or a finish time unless the tool contract provides that evidence.

Is I am working on it always truthful?

The phrase can imply active work even when the request is merely queued or its status is unknown. Choose wording tied to the observed state. A local acknowledgment can be accurate without asserting what an external service is doing.

Does HTTP 202 mean the action succeeded?

No. It indicates acceptance for processing under HTTP semantics, while processing can remain incomplete. Follow the service's status-monitor or reconciliation contract to determine the business result. Keep accepted, completed, and succeeded as separate states in the adapter.

Should the agent give an estimated wait time?

Only when it has a justified estimate with a defined workload and uncertainty. An arbitrary number creates a promise the system cannot defend. A concise status message without a finish prediction is preferable when the service exposes no reliable timing evidence.

How often should waiting messages repeat?

Choose a bounded policy from interaction evaluation rather than a universal interval. Respect caller requests for silence and avoid one timer per tool. Track total waiting speech and interruption, since repeated accurate messages can still make the conversation harder to use.

Why separate acknowledgment and answer latency?

An acknowledgment can begin before the tool returns useful information. Reporting only first sound rewards filler even when the caller waits just as long for the answer. Record both boundaries and task outcomes so a speech policy cannot hide unchanged business latency.

What if the caller asks the agent to stay quiet?

Apply the preference to message creation and queued playback for the current operation. Continue the bounded operation and recovery policy without idle speech. Define which necessary failure or handoff messages can still occur under the interaction contract rather than overriding silence on every timer.

Can I generate waiting phrases freely with a model?

Use constrained generation only within a reviewed evidence contract. High-risk status and success claims are easier to test with a small template set selected by typed state. Fluent wording cannot establish that the request was accepted or that an external write succeeded.

What does a timeout prove?

It proves that a particular wait reached its runtime or application deadline. It does not establish the external business outcome. Preserve unknown state where needed and reconcile by operation identity before claiming failure, success, or permission to submit a new write.

Does aborting fetch cancel the business action?

It cancels the local request behavior under the browser and API contract. The remote service may already have accepted or completed the action. Use a documented cancellation endpoint or outcome query when required, and do not describe a local abort as confirmed rollback.

How do I stop stale waiting audio?

Attach operation, response epoch, and state version to the message. Recheck them before playback admission, then use supported clear or stop controls for already queued media under your policy. Measure the remaining old audio because a local flag cannot retract sound already heard.

Should a successful tool result interrupt filler?

Choose and test a specific interaction policy. A short acknowledgment may finish, or the verified answer may take priority if supported. In every case, reject waiting clips that become ready after terminal completion and prevent stale filler from delaying or contradicting the answer.

What if several tools are pending?

Use one conversational speech budget and summarize the dependency blocking the answer. Keep operation-specific states available internally. Independent tool timers can overlap, repeat the same message, and imply that all tools share a progress state when their outcomes differ.

Is an unknown outcome the same as failure?

Unknown describes missing evidence. The action may have succeeded, failed, or remained pending. Treating it as failure can cause duplicate retries and misleading speech. Keep the state visible and follow a bounded reconciliation path appropriate to the service.

Can I retry a write after losing its response?

Only under the service's documented idempotency and reconciliation rules. Preserve the business-operation identity across eligible retries. A fresh key can create a second action, and a spoken promise to retry does not supply the authority or technical safety needed to do so.

What if the call ends before the result arrives?

Keep the operation's durable owner and reconciliation path separate from the media session. The result can require an approved later delivery or human follow-up. Ending a call does not establish cancellation, failure, or successful communication of an already completed action.

What should a human handoff include?

Transfer the verified operation state, unresolved question, and the minimal authorized identifiers needed for reconciliation. Avoid speculative progress language and unnecessary payloads. Track the handoff separately from completion of the original business task.

What do the synthetic tests establish?

They establish deterministic waiting thresholds, budget enforcement, quiet-mode suppression, version checks, terminal suppression, and invalidation in the example reducer. They do not measure real service latency, user patience, audio quality, or a complete distributed cancellation mechanism.

How can I audit truthfulness automatically?

Log the approved template identifier, operation state, version, and playback-admission decision. Assert that success wording is reachable only from verified results. Human review remains useful for implied promises, confusing phrasing, interruption, and whether the caller understands an unresolved outcome.

How does this apply to 60db Agent?

Apply the same external evidence contract to your documented tool integration and caller experience. Verify status, answer, cancellation, and reconciliation behavior in your own tests. This article describes generic policies and makes no private-architecture or measured-performance claim about 60db Agent.

Make waiting a verifiable behavior

Connect a small approved phrase set to observed tool states, impose a finite speech budget, and reject stale messages before playback. Preserve unknown outcomes until the business service supplies enough evidence to resolve them.

Run the synthetic reducer and delayed-completion fixtures before a real voice trial. Add the resulting contract to your workflow tests and compare useful-answer timing alongside truthfulness and interruption outcomes, so responsiveness never depends on an unsupported promise.