Voice agent warm handoff: preserve the task context

TL;DR: A reliable voice agent warm handoff transfers responsibility, relevant context, and a working audio path to a human before the automated participant leaves. Model the transfer as a durable state machine, require evidence that the destination accepted it, and preserve a fallback whenever an external result is uncertain.

A transfer request is a promise to the caller. Meeting that promise requires more than dialing another number: the receiving person needs to understand the unresolved task, the caller needs to know who can hear them, and your application needs to survive events arriving late or twice.

The protocol foundations separate these concerns. RFC 3515 defines SIP REFER and the mechanism for reporting the referenced request's progress; RFC 5589 describes transfer call flows, including consultation, rather than declaring that every accepted signaling message proves a useful human conversation happened.

This guide proposes a vendor-neutral design you can adapt to your telephony platform. It complements the SIP audio troubleshooting guide and call tracing model, and it makes no claim that a specific 60db Agent workspace exposes every operation described here.

Published: November 9, 2026. Last updated: November 9, 2026. Protocol references and vendor documentation were checked for this edition; examples are illustrative architecture, not measured transfer benchmarks.

Table of contents

1. Define the responsibility being transferred
2. Choose the media topology
3. Make transfer state explicit
4. Build a context contract the human can trust
5. Coordinate audio and conversation
6. Recover from partial failure
7. Protect business writes and access boundaries
8. Test the complete handoff
9. Measure delivery without hiding failed callers
10. Frequently asked questions
11. Put the contract into one real workflow

Define the responsibility being transferred

A warm handoff is complete when the destination has accepted responsibility and can continue the unresolved task. Your definition should say how the application observes that condition, because an answered call can reach voicemail, an automated attendant, a silent endpoint, or a person who cannot handle the request.

Begin with one concrete business workflow. Suppose an automated service can collect a requested appointment change but must route certain exceptions to a scheduling specialist; the handoff should preserve the requested change and its verification status without asserting that the appointment has already changed.

Separate the caller's task from the current call. A task can outlive a failed transfer, while a call can end before the task reaches a resolution, so a single completed flag cannot represent both accurately.

The useful ownership question is narrow: who is responsible for the next promised action right now? Before acceptance, the automated service or its operations queue owns the task; afterward, the receiving human team owns it under an agreed workflow.

Write that ownership change into durable state. A transient conference event is useful evidence, but it is a poor substitute for an explicit assignment record that a restarted worker can inspect.

Define the conditions that trigger a handoff before tuning its phrasing. A caller request, failed identity verification, unsupported action, repeated misunderstanding, or unavailable downstream service can all warrant escalation, but they imply different context and different permissions.

A requested human conversation should not depend on proving that the model failed first. Product policy should define the routing behavior, and the runtime should enforce any availability or eligibility boundaries without pretending the requested destination is available when it is not.

Keep the caller informed about the actual stage. "I am checking whether the scheduling team is available" is a different statement from "You are connected to the scheduling team," and only the second requires acceptance plus a live communication path.

You also need an exit definition. If no specialist answers, success may be a consented callback request, a documented alternative channel, or returning control to the automated service; report that fallback by its own name rather than recording a completed warm transfer.

The outcome metrics guide explains why task completion and routing completion need separate denominators. Apply the same discipline here so that operations staff can distinguish a useful escalation from an attractive transfer percentage.

One design decision deserves early attention: whether the human can decline. A real consultation path usually needs a refusal state, because connecting the wrong specialist and removing the automated participant leaves the caller with a person who never accepted the task.

Finally, assign an operational owner for transfers that finish in an uncertain state. Without that owner, an exception queue becomes storage for abandoned promises rather than a recovery mechanism.

Destination answer alone cannot authorize release of the automated participant.

Choose the media topology

Choose between a provider-managed transfer and an application-controlled bridge based on the control you need during consultation. The choice determines where you can observe participants, recover a failed attempt, isolate a private consultation, and prove that the caller still has audio.

A blind transfer sends the caller toward a destination without a preceding consultation. An attended transfer includes consultation, while a conference bridge can keep the original participant available until the destination accepts; provider terminology varies, so verify behavior rather than relying on the product label.

Twilio's warm transfer guide describes consulting another agent and leaving the customer with that agent. Its conference documentation exposes participant and conference controls, illustrating why a bridge can support hold, join, and leave operations separately.

Those capabilities have operational costs. While consultation proceeds, multiple call legs may remain active, audio recording boundaries may change, and the application must ensure that leaving one participant does not end the whole conference unintentionally.

A SIP REFER path can move call control toward another system. That can reduce your direct involvement after transfer, but it also changes which observations remain available and who is responsible for diagnosing a destination-side failure.

Do not treat REFER and a conference as interchangeable API options. They create different ownership boundaries, and a provider may implement additional restrictions on external numbers, caller identity, authenticated trunks, or transfer destinations that you must check in its current documentation.

The table compares architecture properties, not named vendors or measured reliability. A checkmark means the topology permits the property under the stated implementation, not that configuration alone guarantees it.

For a custom browser architecture, a handoff may involve an operator console rather than a telephone number. That still needs participant identity, permission checks, audio readiness, and a durable task assignment, even when no SIP transfer occurs.

The transport comparison is useful when the caller and the receiving operator use different media surfaces. Avoid assuming that a browser connection event establishes telephone media readiness at the far end.

Describe the chosen topology in a sequence diagram before implementation. If nobody can point to the event that allows the automated participant to leave, the transfer contract is incomplete.

Make transfer state explicit

A transfer state machine turns ambiguous callbacks into controlled transitions. Keep states understandable enough that an operator can reconstruct a failed call without reading model output.

For a retained bridge, a useful progression is requested, preparing, dialing, consulting, accepted, bridged, and released. Add terminal outcomes for decline, timeout, cancellation, and unresolved external status rather than forcing every event into success or failure.

The states describe your application, not the provider's entire call lifecycle. A destination call can be answered while the application remains in consulting, because the human has not accepted the task or the caller has not yet joined.

flowchart TD
    A[Request recorded] -->|Context authorized| B[Prepare destination]
    B -->|Dial accepted| C[Wait for answer]
    C -->|Human available| D[Private consultation]
    D -->|Human accepts| E[Join caller]
    E -->|Media verified| F[Release automation]
    C -->|Busy or deadline| G[Restore caller]
    D -->|Decline| G
    E -->|Media failure| G
    G -->|Caller agrees| H[Fallback task]
    A -->|Caller cancels| I[Cancel attempt]

Each transition needs an expected prior state and an attempt identifier. A late callback from an earlier attempt must never advance a newer attempt, even if both belong to the same call and destination team.

Use a stable transfer identity plus a separate attempt number. The identity tracks the caller's escalation request; the attempt distinguishes retries, alternative destinations, and repeated provider commands without conflating their results.

Make event handling idempotent. If destination_answered arrives twice, the second copy should preserve the current state rather than repeat a context announcement, add another participant, or write a second CRM note.

The event delivery contract matters. Twilio Event Streams documents retries and duplicate events; that contract applies to Event Streams, and you should inspect the separate contract for any other callback mechanism you use.

Store provider identifiers privately so events can be correlated, but avoid placing them in public reports or user-facing summaries. The general article schema can use abstract names while a real deployment maps them to its authorized provider records.

Define the timer owner for every waiting state. A dialing timeout belongs to the transfer attempt, a consultation timeout belongs to human availability, and an overall caller wait deadline belongs to the user experience.

Use monotonic time for in-process elapsed durations and durable wall-clock deadlines for recovery after restart. A restarted worker cannot reuse an old process's monotonic clock, so storing only that value makes its deadline uninterpretable.

A transition should commit before initiating the next externally visible step, or the step should be reconciled through a durable command record. Otherwise a crash can leave a human being called with no application record of why, or a caller placed on hold with nobody responsible for restoring them.

For a small implementation, an existing transactional database and job queue are often enough. The architectural requirement is durable ownership and safe retry, not a new orchestration framework.

Build a context contract the human can trust

Transfer context should distinguish observed facts, caller statements, and unverified model inferences. A fluent summary that blends those categories can make the receiving human more confident while making the actual decision less reliable.

Start with structured fields that support the next action. Include the reason for escalation, requested task, confirmed entities, pending questions, completed actions, unresolved actions, and the status of any authorization checks required by the workflow.

Keep a short readable summary alongside the structured record. Humans need a quick orientation, while applications need fields they can validate and route without interpreting prose.

A vendor-neutral context record might contain schema_version, task_reference, handoff_reason, requested_action, verified_fields, unverified_fields, action_receipts, and pending_questions. These are suggested application fields, not a 60db Agent API schema.

An action receipt should identify what the system observed from the owning service. "Change requested" and "change committed" must be separate statuses; a tool timeout does not justify either a success assertion or an automatic second write.

Summaries need provenance at a useful level of granularity. A field can say that a requested date came from the caller and remains unconfirmed, while a current appointment status came from an authorized system lookup at a recorded time.

Avoid turning the entire transcript into the default context payload. It may contain irrelevant personal data, mistaken recognition, conversational digressions, and instructions that the receiving system must treat as untrusted content.

The handoff should support uncertainty without becoming unreadable. A compact warning such as "Requested time needs confirmation" tells the human what to verify next; a raw confidence score without calibration or explanation does not.

Version the context contract. If an operator console expects authorization_status but an older producer sends only a Boolean named verified, an empty field must not silently inherit the most permissive interpretation.

JSON Schema's object reference explains property constraints and required fields. Use schema validation for shape, then apply business validation separately because a well-formed object can still name an unauthorized task or contain an unsupported action.

The recipient should acknowledge the context version or explicitly open a supported fallback view. Sending a context packet is a delivery attempt, while receiving an acknowledgment establishes that the destination had a chance to use the intended contract.

Bind the accepted context to a revision. If the caller changes their request while waiting, either update and re-acknowledge the summary or tell the human that a newer caller correction remains pending.

That revision rule prevents a subtle failure. A specialist can accept a summary about rescheduling, the caller can then say they want cancellation instead, and an unversioned handoff can leave both parties believing they agreed to the same task.

For multilingual callers, preserve the original language preference and identify which fields were translated. The multilingual evaluation guide covers why names, dates, and amounts require semantic verification beyond readable translated prose.

A caller correction can invalidate accepted context; acknowledge the new revision before acting on it.

Coordinate audio and conversation

Audio coordination determines whether a technically successful transfer feels safe and understandable. The application must decide who can hear each participant at every stage and ensure the spoken explanation matches that topology.

A private consultation usually means the human and automation can exchange context while the caller hears hold audio or a clear waiting message. A conference-wide announcement is different because the caller hears the same summary and can correct it immediately.

Choose deliberately. Private consultation can reduce repetition, while a shared summary offers a direct opportunity for correction; your policy, accessibility needs, and task sensitivity determine which is appropriate.

Do not whisper sensitive context into an endpoint that has only answered. Establish the intended recipient through the supported operator workflow before exposing protected information, because an answered external number does not prove that the authorized specialist is listening.

Place the caller on hold only after the hold operation is acknowledged or its effect is otherwise observable. If you start a private summary before the media topology changes, the supposedly private exchange can leak into the caller's audio.

The reverse operation matters too. An unhold request followed immediately by an introduction can produce a clipped first sentence when media restoration lags behind control-plane acknowledgment.

Define an audio readiness criterion appropriate to your platform. It may combine participant state, media connectivity, and a human acknowledgment, but it should avoid promising perfect audio solely from a signaling response.

Keep automated speech under a single owner during transfer. A normal assistant response, hold announcement, consultation summary, and greeting should not race independently to the same output stream.

The interruption state machine provides the related turn ownership rule. Transfer announcements need the same cancellation and stale-audio protections as ordinary assistant speech, especially when the caller changes their mind during a destination attempt.

Make cancellation language specific. If the caller says "Wait, do not transfer me," stop starting new destination work, reconcile any call already placed, restore the caller's appropriate audio state, and say what happened without pretending the external call never existed.

Human takeover also needs an output fence. Once the human owns the conversation, old model responses and delayed tool narrations must not resume through a retained socket merely because a background task completed.

A short closing introduction can establish the new roles: who has joined, what task they received, and whether the automated participant is leaving. Avoid scripted certainty about resolution, since the receiving human may still need to verify details before acting.

Accessibility changes the timing requirements. Some callers need longer response windows, alternative language support, or a repeat of the introduction; a transfer timeout should account for the workflow rather than treating every quiet interval as abandonment.

Hold audio deserves testing under the real transport. A local audio file that sounds fine in a browser can behave differently after telephony transcoding, level adjustment, or repeated playback, so listen through the actual caller route.

Recover from partial failure

The most useful failure policy restores a coherent caller experience while preserving uncertainty about external actions. Transfer systems fail between steps, so recovery must handle combinations rather than a single exception handler.

If the destination is busy or does not answer, restore the caller and describe the available fallback. Do not keep extending the same wait without a stated limit or hide multiple unsuccessful attempts behind generic hold audio.

If the human answers and declines, record the reason separately from technical failure. Routing to the wrong skill group is operational evidence, and retrying the same destination may only add cost and frustration.

If the caller disconnects during consultation, stop attempts that depend on their continued participation. The human may still need an authorized follow-up task, but that is post-call work with its own policy rather than permission to keep the original media session open.

If the automated participant loses its connection after the human accepts, the bridge should follow the predeclared participant policy. A design that ends the whole conference whenever automation leaves defeats the intended handoff.

If the human's media fails after caller join, retain enough control to recover while the bridge still exists. Once all control has been released, recovery may require a separately authorized callback or an operational task, and the system must acknowledge that limitation.

Timeouts deserve careful wording in state. A command that timed out is an unknown result until reconciled, not proof that the provider did nothing.

A safer pattern stores command_pending, queries or observes the provider's current state through supported interfaces, and then chooses a next action. If the external service offers no reliable reconciliation path, send the task to an operator rather than blindly repeating a non-idempotent command.

Distinguish event ordering from event meaning. A late ringing event does not undo an accepted handoff, and a late participant_left event for an earlier attempt must not remove the active human participant.

Your transition function can enforce those rules with expected-state checks and attempt matching. Keep the transition log concise enough that an operator can see which evidence was accepted and which was ignored as stale.

A restarted worker should recover from durable state before issuing commands. Rebuild active attempts, reconcile participant membership, and restore deadlines; do not infer the correct state from the most recent line of an unordered callback log.

The shutdown semantics guide covers another boundary: live media must stop when its participant contract ends, while durable follow-up work may continue independently. A transfer failure is a reason to exercise that boundary, not to bypass it.

Treat fallback capacity as part of production readiness. A callback queue with no staffing, service deadline, or assignment owner does not preserve the caller's task just because the database accepted a row.

Protect business writes and access boundaries

Handoff is a concurrency boundary between two actors that may both be capable of changing business data. Without an ownership rule, the automated service and the receiving human can each perform the same action while believing the other has not started.

Freeze or explicitly partition pending writes during transfer preparation. Read-only context lookup can continue where authorized, but a human should not receive a summary that says "pending" while an unattended model task commits the action a moment later.

If a write is already in flight, attach its receipt or uncertain status to the context. Give the receiving human a visible reconciliation instruction instead of hiding the ambiguity behind a clean summary.

Use business-operation identifiers for deduplication. A transfer retry has its own attempt identifier, but an appointment change should retain the same operation identity across agent and human handling when they are continuing the same authorized action.

Stripe's idempotency documentation is a concrete example of an external service defining retry semantics. Its behavior is provider-specific; the general lesson is to verify the target service's contract rather than assuming that adding an arbitrary header makes every write safe.

For local state, commit the ownership change transactionally. PostgreSQL documents row-level locking, which is one available tool for coordinating concurrent updates, but an application still needs a defined invariant and a short transaction scope.

Do not hold a database lock while waiting for a person to answer. Record a bounded ownership lease or state transition, release the transaction, and reconcile later events under the same version checks.

Access should narrow at the destination boundary. A scheduling specialist may need requested dates and appointment status without needing unrelated payment history or a raw recording of identity verification.

Keep human-facing summaries separate from model instructions. Caller utterances and retrieved text remain data, so a sentence inside a transcript saying "ignore the previous rules" must not gain authority when copied into the operator-assistant context.

The workflow enforcement guide explains where that control belongs: authorization and action eligibility should be checked outside the prompt at the tool boundary. Transfer does not erase those checks or upgrade a participant's permissions.

Recording permissions require their own owner. A conference can change which participants are present and which audio channels are recorded, so policy should define whether and how recording continues after automation leaves.

Only expose context through authenticated channels with appropriate retention and audit controls. A convenient public URL in a transfer header can become an unintended access path, and a short opaque reference still needs authorization when resolved.

Keep one current write owner and preserve operation identity while agent and human coordinate.

Test the complete handoff

Test the state machine separately from the live telephony path. Deterministic replay proves your transition rules; consented end-to-end calls prove that the provider mapping and media behavior match those rules.

A useful replay fixture describes initial state, events, expected state, commands emitted, and prohibited commands. Keep fixtures synthetic so they can be shared with developers without moving customer transcripts into a test repository.

Start with the successful path, then remove one acknowledgment at a time. Drop context delivery, destination acceptance, caller unhold acknowledgment, and automation release confirmation to see whether the system preserves a coherent owner.

Repeat events and reorder adjacent events. Your assertions should prove that a duplicate answer does not duplicate a summary, a stale attempt does not join the caller, and a late callback cannot revive a canceled transfer.

Test user steering during every waiting state. A caller can change the requested task, choose a different team, withdraw permission, or hang up, and each event needs a defined effect on existing attempts.

Include human-side failures. Test a person who answers but rejects, a console that opens old context, a human who disconnects during the introduction, and a destination that sends valid signaling while delivering one-way audio.

The real-call regression harness can host these scenarios with controlled audio and explicit business assertions. Keep the pass criteria observable: which participant heard which prompt, which operation happened, and which task owner remained afterward.

Use a sandbox or dedicated test destination, never unsolicited calls to live staff or customers. Ensure tests clean up their own conference participants and queued tasks, because a test that leaves a live leg behind creates both operational noise and cost.

A minimal deterministic assertion is often enough to expose a design problem. If a transfer is canceled in dialing, delivering a late acceptance event must leave it canceled and emit no command that joins the caller.

The following runnable Python fixture checks a narrow transition invariant without a telephony SDK. Save it as transfer_replay.py and run python3 transfer_replay.py; it uses synthetic event identities and does not model or call a 60db Agent API.

from dataclasses import dataclass, field

@dataclass
class Attempt:
    identity: str
    state: str = "dialing"
    seen: set[str] = field(default_factory=set)
    commands: list[str] = field(default_factory=list)

    def apply(self, identity, event_id, kind):
        if identity != self.identity or event_id in self.seen:
            return
        self.seen.add(event_id)
        if self.state == "canceled":
            return
        if kind == "cancel":
            self.state = "canceled"
        elif kind == "accepted" and self.state == "dialing":
            self.state = "accepted"
            self.commands.append("join_caller")

canceled = Attempt("attempt-b")
canceled.apply("attempt-b", "e1", "cancel")
canceled.apply("attempt-b", "e2", "accepted")
assert canceled.state == "canceled" and canceled.commands == []
active = Attempt("attempt-b")
active.apply("attempt-a", "old", "accepted")
assert active.state == "dialing"
active.apply("attempt-b", "e3", "accepted")
active.apply("attempt-b", "e3", "accepted")
assert active.commands == ["join_caller"]
print("transfer replay checks passed")

This fixture protects cancellation, attempt matching, and duplicate suppression only. Production handling still needs durable storage, authenticated events, provider reconciliation, and media checks; the fixture deliberately keeps those external responsibilities outside its claim.

Build that assertion into the transition test before connecting a provider. Once the state logic passes, map real callback payloads to the same internal event vocabulary and verify that invalid or unauthenticated payloads are rejected.

Run a restart drill. Persist an attempt in consultation, stop the application deliberately, restart it, and verify that it reconciles existing participants rather than dialing another specialist by default.

Finally, inspect the receiving human's experience. A transfer can satisfy every machine assertion while leaving the operator with a summary that omits the one unresolved question needed to help the caller.

Measure delivery without hiding failed callers

Measure the funnel from escalation request to useful human ownership. A provider's destination-answer count is useful transport data, but it does not measure context availability, acceptance, media quality, or eventual task resolution.

Define the denominator before collecting a dashboard. Include all eligible handoff requests, then label refusals, capacity limits, caller cancellations, technical failures, successful fallbacks, and completed transfers as separate outcomes.

Measure wait from the caller's observable experience. A timer that begins only after context preparation hides preparation delay, and a timer that ends at destination answer hides consultation and unhold delay.

Useful spans include request-to-hold explanation, request-to-destination answer, answer-to-acceptance, acceptance-to-two-way conversation, and request-to-fallback restoration. Report sample counts and percentile definitions alongside those values.

Join those timings to failure categories without publishing protected call details. Aggregate reporting should preserve enough cohort information to diagnose routing or media problems while suppressing identifying combinations.

The latency measurement guide explains the clock boundary problem. Cross-service timestamps can help reconstruct a transfer, but claims about what a caller heard require playback or appropriately qualified media evidence.

Track context defects through human review. Ask whether the summary identified the correct task, preserved uncertainty, included completed action receipts, and avoided irrelevant sensitive data; do not reduce those dimensions to a single uncalibrated model grade.

Measure caller repetition carefully. Some repeated questions are necessary verification, while others reveal missing context, so the review rubric needs to distinguish those cases before an automated counter becomes a product target.

Include cost per useful escalation. Parallel call legs, human consultation time, unsuccessful attempts, and fallback work all belong in the model described in cost per successful call.

Capacity planning should use concurrent attempts and consultation duration, not just completed transfers per hour. A burst of unanswered destination calls can consume resources while producing few completed handoffs.

Keep any published benchmark bounded by its test conditions. The design in this article provides a measurement plan; it does not establish a transfer success rate, a latency claim, or comparative product performance.

Frequently asked questions

What makes a voice agent handoff warm?

A warm handoff includes consultation or explicit context sharing with the receiving person before responsibility fully transfers. The exact media topology varies, so define acceptance and caller continuity rather than relying on the label alone.

Is an answered destination call enough to release automation?

No. Answering establishes a call state, while useful handoff requires an appropriate recipient, accepted responsibility, and a working communication path; voicemail and automated attendants can answer without satisfying those requirements.

Should every handoff use a conference bridge?

No. A retained bridge is useful when you need consultation and controlled recovery, while a supported transfer contract may fit a simpler route; choose according to the ownership and fallback guarantees you need.

Can SIP REFER preserve application context?

Context transfer depends on the systems and supported mechanisms around the SIP transfer. REFER itself does not define your business summary, recipient permissions, or task ownership contract, so verify those separately.

What should the human receive first?

Send the unresolved task, reason for escalation, verified details, pending questions, and receipts for completed actions. Keep the first view short enough to scan and make uncertain or stale information visible.

Should the entire transcript go to the human?

Only when the task, access policy, and recipient workflow justify it. A structured summary often reduces irrelevant exposure, while an authorized transcript view can remain available for details that require inspection.

How do I handle a caller correction while waiting?

Create a new context revision and invalidate acceptance of the stale task where necessary. Require the receiving side to acknowledge the changed request before it acts on the earlier summary.

What happens when the specialist is busy?

Restore the caller's appropriate audio state and explain the available fallback. Record busy separately from no answer or technical failure so routing and staffing decisions use accurate evidence.

Can the caller cancel a transfer?

Your workflow should define cancellation during every waiting state. Stop new commands, reconcile external work already started, and prevent late callbacks from reconnecting the caller to a canceled attempt.

How do I avoid duplicate CRM notes?

Give the business update a stable operation identity and make the receiving endpoint deduplicate it. Transfer attempt identifiers alone are insufficient because several attempts can belong to the same escalation request.

Does a transfer timeout mean the transfer failed?

A timeout means your application did not receive the expected result within its deadline. Reconcile external state before retrying a command that may already have created a participant or changed the call route.

Who owns an unresolved transfer after restart?

A durable task or attempt record should name the owner and recovery state. The restarting worker then reconciles provider state and deadlines rather than guessing from callback arrival order.

How should hold audio be tested?

Listen through the actual supported caller route and codec path. Verify that introductions are audible after unhold, that cancellation stops stale speech, and that no supposedly private consultation reaches the caller.

What should happen when the caller hangs up?

End caller-dependent media and cancel unnecessary destination attempts. Any authorized follow-up task should continue through a separate post-call contract with a durable owner and bounded retention.

Can a human and agent both keep tool access?

They can only do so safely with explicit ownership or partitioned operations. A transfer must not leave two actors free to commit the same pending action without a shared deduplication and authorization rule.

How much does warm transfer cost?

Calculate it from your actual provider billing, overlapping call legs, consultation time, and fallback handling. No universal per-transfer price captures those differences, and this guide presents no measured cost claim.

Which transfer metric should lead the dashboard?

Use accepted, usable human ownership among eligible requests, with technical and fallback outcomes shown separately. Destination answer rate remains a supporting metric because it does not establish successful task continuation.

How do I test duplicate transfer callbacks?

Replay the same event identity and payload against the same persisted attempt. Assert unchanged business state and no repeated external command, then repeat with out-of-order events from an older attempt.

Does this design guarantee legal compliance?

No. Engineering controls can enforce a policy contract, but disclosure, recording, identity verification, and retention requirements need definitions from the responsible policy owners for the actual use case.

How should I evaluate this with 60db Agent?

Verify the documented transfer, context, event, and outcome surfaces available to your workspace, then run consented tests against those contracts. Treat unavailable or unobservable stages as explicit limits rather than assuming an API or inbound capability exists.

Put the contract into one real workflow

A reliable handoff begins with a clear promise: the next person can continue the caller's task, and the caller remains informed while responsibility changes. The media topology, context record, transfer state, and business-operation ownership should all support that same promise.

Start with one supported destination and one fallback. Write the accepted states, identify the observation that permits automation to leave, and prove that late events cannot revive a canceled attempt or duplicate an irreversible action.

Then test the caller and receiving operator together. A completed signaling flow is only one part of the experience; context usefulness, two-way audio, recoverable waiting, and an honest final outcome are the evidence that the workflow works.

The current 60db Agent documentation excludes browser transfer, and its tools and webhooks contract describes outbound destination bridging and application-handled stream transfers. Those public contracts do not establish universally available private consultation or contextual briefing; qualify those capabilities in your workspace.

For a 60db Agent evaluation, bring that contract to the documented surfaces available in your workspace. Run a consented transfer drill, capture the observable timeline, and fix the first ownership ambiguity before expanding routing complexity.