Before Your Voice AI Answers a Real Call, Run This 12-Gate Launch Review

A voice agent can sound ready long before it is operationally ready. The demo answers a clean question, the synthetic voice is pleasant, and the transfer to a human works once. None of those results proves that the system can survive a noisy line, an ambiguous identity, a repeated request, a provider outage, a hostile caller, or a customer who simply wants to know whether they are speaking to a machine.

The useful launch question is not “Does the bot sound human?” It is: can the operator prove that every call enters through an allowed route, uses the minimum necessary data, discloses the automated interaction, takes only authorized actions, escalates at the right moment, preserves usable evidence, and fails safely?

This guide converts an existing seven-control deployment checklist into a twelve-gate acceptance review for production voice AI. It is designed for a support line, appointment desk, switchboard, collections workflow, or lead-qualification line. The same method works whether speech recognition, synthesis, telephony, orchestration, and business tools come from one vendor or five.

The conclusion is deliberately stricter than a normal software release: a voice agent should not receive broad authority on day one. Start with a narrow call class, measured disclosure, read-only tools, a visible transfer path, and a defined stop condition. Earn additional authority after real evidence accumulates.

The release decision: four states, not one launch button

Every review should end in one of four explicit states. This prevents a team from treating “not ready for autonomous writes” as “the entire project failed,” or treating “the demo worked” as approval for all calls.

State	What the system may do	Typical evidence
Shadow	Listen to test or consented calls and produce recommendations without affecting the live conversation	Transcript accuracy by scenario, latency distribution, redaction checks
Assist	Suggest answers or next steps to a human agent	Human acceptance rate, correction categories, privacy controls, source traceability
Bounded autonomy	Handle named intents and a small set of reversible actions	Intent-specific success, tool authorization, transfer success, retry and rollback tests
Deny or rollback	Receive no new calls, or fall back to humans and a recorded message	Triggered stop threshold, named incident owner, preserved evidence

Do not use one global status called “production.” A system can be production-ready for business hours and read-only appointment lookup while remaining unapproved for outbound campaigns, payments, complaints, medical information, or account changes. The unit of approval is the call journey plus its authorized action set.

Map the real call path

The product screen usually hides the most important dependencies. Draw the complete path before testing:

flowchart LR
    A[Caller and phone network] --> B[Carrier or SIP edge]
    B --> C[Disclosure and consent gate]
    C --> D[Speech recognition]
    D --> E[Dialogue and policy runtime]
    E --> F{Intent and risk}
    F -- Allowed read --> G[Business tool gateway]
    F -- Write or sensitive --> H[Human approval or transfer]
    F -- Unknown or hostile --> I[Safe refusal]
    G --> J[CRM, calendar, ticketing]
    H --> K[Human queue]
    E --> L[Speech synthesis]
    L --> A
    B --> M[Call metadata]
    D --> N[Redacted transcript]
    E --> O[Decision trace]
    J --> P[Outcome and reversal record]
    M --> Q[Retention jobs]
    N --> Q
    O --> Q
    P --> Q

Every arrow is a failure and data boundary. The carrier can route incorrectly. Speech recognition can transform a name, amount, or date. The dialogue layer can choose the wrong intent. A tool can accept a duplicate action. Synthesis can omit a warning because the response was interrupted. A queue can report a successful transfer even though no person answers.

The map also exposes processor and retention sprawl. Audio may exist in a carrier recording, a speech provider buffer, an application trace, a quality-management export, and a support ticket. “We do not store calls” is not credible until every component is checked.

Gate 1 — define the allowed call envelope

A voice agent needs a written envelope: who may call, why they call, when the service operates, which languages are supported, which intents are in scope, and which outcomes are permitted. “Handle customer service” is not an envelope. “Answer order-status questions for authenticated retail customers and transfer all changes” is one.

Create an intent table with four columns: intent, required evidence, permitted response, and maximum action. Include negative space. For example, the system may explain opening hours but must not interpret a contract; it may collect an appointment preference but must not diagnose a symptom; it may state an invoice balance but must not negotiate a settlement.

Test callers who fall outside the envelope: wrong language, third party calling for someone else, blocked number, employee testing from an internal line, minor, distressed caller, abusive caller, and a caller asking the system to ignore its rules. A safe system identifies the boundary quickly and moves to a deterministic refusal or transfer.

The operating owner must approve this envelope. Product, privacy, security, legal, customer operations, and accessibility specialists may contribute, but one named person needs authority to suspend the journey.

Gate 2 — disclose automation before meaningful collection

The caller should learn that the interaction is automated before the system asks for sensitive or decision-relevant information. The disclosure must be audible, understandable, and short enough that people do not tune it out. It should also explain recording or transcription when those occur, and provide a practical alternative when policy or law requires one. For EU deployments, the European Commission's official AI transparency overview states that Article 50 transparency rules apply from 2 August 2026 and include informing individuals when they interact with an AI system; scope and implementation still require case-specific review.

The FCC has treated AI-generated voices as artificial voices under the US Telephone Consumer Protection Act framework. Its 2024 announcement also reiterated that telemarketing robocalls can require prior express written consent. That does not create a universal rule for every inbound call or every country; it demonstrates why teams must classify the call, jurisdiction, direction, purpose, and consent basis instead of relying on a generic “AI is allowed” statement.

Test the disclosure in these conditions:

• the caller speaks during the opening message;
• the call starts with voicemail or an interactive voice response system;
• the caller asks, “Are you human?” at any point;
• audio is interrupted by packet loss;
• the caller changes language after the greeting;
• the system resumes after a transfer failure;
• an outbound call reaches a shared or wrong number.

The system should never claim to be human. If a caller asks, the answer should be direct. A pleasant voice does not justify ambiguity. Record which disclosure version played, whether it completed, and which continuation signal followed. Do not infer consent merely because the caller did not hang up unless accountable specialists have approved that basis for the exact scenario.

Gate 3 — minimise audio, transcript, and metadata

Voice creates three related but different records: the waveform, the transcript, and call metadata. Each has a purpose and risk. Raw audio can reveal health, emotion, background conversations, accent, and other information that a transcript omits. A transcript can make the content searchable and easier to distribute. Metadata can reveal relationships, timing, location signals, and behavioural patterns.

For each record, answer:

1. Is it required to deliver the call or only useful for quality analysis?
2. Can a shorter buffer replace long-term storage?
3. Which fields can be removed or pseudonymised?
4. Who can retrieve it, and through which audited path?
5. When does its deletion clock start?
6. Does a vendor use it for product improvement or model training?
7. How can a caller exercise applicable access, correction, objection, restriction, or deletion rights?

The UK Information Commissioner’s Office emphasizes that individual rights apply across AI development and deployment, including prompts, outputs, training, and fine-tuning data. For a voice system, the practical lesson is broader: a rights workflow must locate relevant call IDs across audio, transcripts, summaries, model traces, quality samples, and downstream tickets. Keeping one searchable transcript while forgetting the quality export is not a complete process.

Minimise before the model call. Redact credentials, payment data, health information, and other restricted classes unless the approved journey genuinely needs them. Minimise again before logging. A trace can prove that an appointment tool was called without copying the caller’s full spoken address into three systems.

Gate 4 — measure speech recognition by consequence

One average transcription score hides the errors that matter. A system may transcribe ordinary conversation well while repeatedly corrupting names, postal codes, medication names, account numbers, dates, currencies, and negation. The review should weight an error by consequence. A recent research synthesis on real-time voice-agent evaluation reaches a compatible conclusion: component latency or transcription quality alone does not establish a grounded task outcome, and timing, recovery, and backend-state verification need to be reported together.

Build a test corpus that represents actual acoustic conditions without turning production calls into an uncontrolled dataset. Include accents, speaking rates, mobile compression, speakerphone echo, background television, children, traffic, quiet speech, interruptions, code-switching, proper nouns, and similar-sounding numbers.

Score at least four layers:

• utterance understanding: did the system capture the intended request?
• critical entities: were names, dates, quantities, identifiers, and negatives correct?
• dialogue recovery: did it ask an appropriate clarifying question?
• action outcome: did the final tool call contain verified values?

The agent must read back consequential values before acting. A confident transcript is not evidence that the caller said it. Use explicit confirmation for account changes, appointments, addresses, amounts, and consent choices. When the caller rejects a read-back twice, transfer instead of looping.

Gate 5 — make the policy layer deterministic

The model may classify an intent and propose an action. It should not be the final authority for a tool call. Put a deterministic policy check between the dialogue runtime and the business tool.

The following executable JavaScript example evaluates a call action against journey, verification level, risk, and retry state:

const journeys = {
  "order-status": {
    minVerification: 1,
    tools: { orders: ["read"] },
    approval: []
  },
  "appointment-change": {
    minVerification: 2,
    tools: { calendar: ["read", "update"] },
    approval: ["calendar:update"]
  }
};

function authorize(call) {
  const journey = journeys[call.journeyId];
  if (!journey) return { allow: false, reason: "journey_not_registered" };
  if (call.verificationLevel < journey.minVerification) {
    return { allow: false, reason: "identity_not_sufficient" };
  }
  const operations = journey.tools[call.tool] || [];
  if (!operations.includes(call.operation)) {
    return { allow: false, reason: "operation_not_allowed" };
  }
  if (call.retryCount > 0 && !call.idempotencyKey) {
    return { allow: false, reason: "unsafe_retry" };
  }
  const action = `${call.tool}:${call.operation}`;
  if (journey.approval.includes(action) && !call.approvalId) {
    return { allow: false, reason: "human_approval_required" };
  }
  return { allow: true, reason: "policy_match" };
}

console.log(authorize({
  journeyId: "appointment-change",
  verificationLevel: 2,
  tool: "calendar",
  operation: "update",
  retryCount: 0
}));

Run policy outside the prompt. Use short-lived workload credentials, not a shared master key. Bind the decision to the call ID, caller verification state, journey version, exact operation, payload hash, and expiration. If the model changes the payload after approval, invalidate the approval.

This is where a narrow deployment becomes safer and faster. Teams can add a new read-only intent without granting write authority across the platform. The policy denies an unknown combination even if the agent can technically construct the request.

Gate 6 — authenticate without turning the call into an interrogation

Authentication should match the consequence. Public opening hours need none. A delivery status may require a low-risk account signal. An address change, payment, account closure, or disclosure of sensitive records needs stronger verification and often a different channel.

Do not use information that is both easy to know and useful to disclose as the only proof of identity. Date of birth, postal code, or the last digits of a number may already be exposed. Avoid asking callers to speak a password or full payment credential. Consider a push notification, one-time link, or existing authenticated session for higher-risk steps.

Separate identity proofing from conversational confidence. The fact that the agent recognizes a returning caller’s voice, number, or history does not automatically establish authority. Caller ID can be spoofed; voice cloning increases the reason to avoid voice alone as a high-impact authenticator.

ENISA’s threat reporting notes that synthetic audio and AI-generated content have entered the daily arsenal of threat actors, while fraud and impersonation remain material categories. This evidence argues against designing the system as if the voice channel were inherently trustworthy. It does not mean every caller is malicious. It means the control should be resilient when a persuasive caller is not the account holder.

Gate 7 — design interruption and turn-taking as safety functions

Latency is not only a user-experience metric. It changes behaviour. When the system responds too slowly, callers repeat themselves, disclose more information, or assume the line failed. When it interrupts, it can suppress a correction, a refusal, or an emergency cue.

Measure end-to-end latency from end of speech to audible response, not just model generation. Keep the median, high percentiles, and worst observed cases by route. Break the measure into carrier, speech recognition, orchestration, tool, model, and synthesis components. A good average cannot excuse a long tail that makes the dialogue unusable.

Test barge-in. The caller should be able to interrupt routine speech, but not in a way that prevents mandatory disclosure from ever completing. Decide how the system handles overlapping voices, long silence, background speech, hold music, and a caller who says “stop.” A stop request should have priority over a model’s plan.

Set loop limits. After repeated non-understanding, failed verification, or the same clarification, transfer or end safely. Do not let a model improvise indefinitely because each extra turn increases cost, frustration, and data collection.

Gate 8 — make transfer an end-to-end outcome

Many systems report “transfer initiated” as success. The caller experiences success only when the right human context receives the call and can continue without forcing the story to restart.

A transfer test should verify:

• the destination queue is correct for language, intent, and hours;
• the caller hears an accurate wait or fallback message;
• the human receives a concise, redacted summary and verified facts;
• uncertain or model-inferred facts are clearly labelled;
• the call recording and disclosure state remain correct across systems;
• failure returns to a safe route rather than a dead line;
• the original agent cannot continue acting after handoff;
• the outcome is observable from caller to human acceptance.

Define transfer triggers before launch. Examples include explicit request, repeated misunderstanding, high-impact action, distress, complaint, vulnerability, legal threat, unsupported language, authentication failure, and provider degradation. The human route must have capacity. A perfect transfer policy connected to an unstaffed queue is not a control.

Gate 9 — control outbound calls separately

Inbound support and outbound contact have different expectations and legal constraints. Do not copy an inbound configuration into campaigns. Classify informational reminders, service messages, collections, sales, political calls, and emergency notifications separately.

For every outbound journey, verify the source of the number, permission or other approved basis, suppression lists, local calling hours, calling identity, disclosure, opt-out capture, frequency caps, and wrong-party handling. A model should not persuade a person to reverse an opt-out. The suppression event must reach the dialer before the next attempt.

Use a campaign-level kill switch and daily caps. Detect abnormal answer, complaint, transfer, and hang-up patterns. If a carrier, script, or list changes, run a small canary batch. Do not measure success only as completed calls; include complaints, wrong-party disclosures, opt-outs, repeat attempts, and downstream corrections.

The FCC example is a jurisdiction-specific warning, not a global compliance checklist. European, national, and sector rules differ. The operator needs qualified advice for the actual countries, call types, and recipients. The engineering control is to encode the approved classification and block calls that lack it.

Gate 10 — test security against the voice threat model

Voice agents combine public input with privileged tools. Treat every utterance, retrieved document, DTMF sequence, and transfer note as untrusted. A caller may explicitly ask the system to reveal instructions, call an unlisted tool, repeat another customer’s information, or encode commands inside a document the agent retrieves.

Threat tests should cover:

1. prompt injection spoken directly;
2. injection in a CRM note or knowledge article;
3. tool enumeration and hidden instruction requests;
4. attempts to cross tenant or account boundaries;
5. replayed verification answers;
6. spoofed caller identity;
7. synthetic or cloned voice used as social pressure;
8. denial of service through long calls or tool loops;
9. data exfiltration through read-back or transfer summaries;
10. compromised provider credentials;
11. malicious changes to routing, prompts, or voices;
12. support staff overriding policy without traceability.

Rate-limit by journey and action, not only by phone number. Apply payload schemas and allowlists at the tool gateway. Redact secrets from prompts and traces. Monitor new destinations and tool combinations. A prompt that says “never reveal private information” is useful behavioural context, but it is not an access control.

Gate 11 — define evidence, retention, and rights workflows

The incident team must be able to reconstruct a call without creating an uncontrolled archive of raw conversations. Design a minimum evidence event:

• pseudonymous call ID;
• timestamp and route;
• disclosure version and completion state;
• journey and policy version;
• verification level, without copying secrets;
• intent decision and confidence band;
• tool name, operation, payload hash, and result;
• approval or transfer reference;
• model and speech-service configuration versions;
• final outcome, retry count, and reversal status.

Set separate retention for raw audio, transcript, summary, model trace, tool event, quality sample, and business outcome. Start each clock from a defined event such as call closure, case resolution, or contract end. Test deletion with a synthetic caller across every store.

The ICO’s guidance is valuable precisely because it resists a narrow “model only” view. Individual rights can touch input, output, training, fine-tuning, and deployment data. For operators, this means vendor contracts and architecture must support discovery and action. If a vendor cannot locate or delete a record, document that limitation before launch and decide whether the journey remains acceptable.

Do not retain every transcript forever “for improvement.” Create a separate, approved quality-sampling purpose. Select representative calls, minimise them, restrict access, set a short review window, and record why the sample entered the dataset.

Gate 12 — rehearse failure and rollback

The final gate is a live exercise. Disable the model provider, delay the tool, reject a credential, overload the transfer queue, return malformed JSON, interrupt speech synthesis, and simulate a carrier route failure. Observe what the caller hears and what the system does.

The safe fallback depends on the journey. It may be a human queue, a callback request, a status page, a voicemail with limited collection, or a clear instruction to use another channel. It should not be a confident fabricated answer.

Define automatic stop thresholds for severe events: cross-account disclosure, unauthorized write, repeated wrong-party contact, missing disclosure, runaway calling, broken opt-out, or inability to transfer high-risk calls. For softer degradation, reduce authority: switch from autonomy to assist, from writes to reads, or from open conversation to deterministic routing.

Test rollback as a complete operation. Reverting orchestration code while leaving a new tool schema, prompt, routing table, or vendor setting in place can preserve the fault. Record the release bundle and dependency versions. Name the person authorized to stop traffic at any hour the system operates.

A scorecard that does not reward the wrong thing

A launch dashboard should show user outcome, safety, and operations together. Do not optimize solely for containment rate, average handling time, or call cost. Those metrics can improve when the system discourages callers, refuses transfers, or ends difficult calls.

Use an intent-level scorecard:

Dimension	Example measure	Release interpretation
Task outcome	Correct resolution confirmed by system of record	Must be measured by journey, not globally
Critical entity accuracy	Correct names, dates, amounts, negatives	High-consequence errors receive greater weight
Disclosure	Completed and understood before collection	Any systematic gap blocks affected route
Authentication	Correct accept and reject behaviour	False acceptance carries higher consequence
Tool safety	Unauthorized and duplicate actions	Severe events trigger stop, not averaging
Transfer	Human accepts call with useful context	Initiated transfer alone is insufficient
Caller effort	Repeats, turns, correction, abandonment	Segment by intent and acoustic condition
Privacy	Redaction, retention, rights completion	Evidence must span all processors
Reliability	Latency distribution, outage fallback	Use high percentiles and failure scenarios
Human quality	Reviewer corrections and escalations	Zero corrections can signal rubber-stamping

McKinsey’s customer-care analysis describes uneven results from early generative-AI adoption despite clear potential for efficiency and experience. That is the contradiction a launch review must retain: the technology can improve service, yet benefits do not arrive merely because a model is added. Process design, risk selection, data, human roles, and operational integration decide whether the value appears.

Do not invent a target because it sounds standard. Establish a baseline with the existing human or IVR journey, define the minimum acceptable result for each risk dimension, and use confidence intervals or sample counts when reporting outcomes. A one-day pilot with twenty friendly callers does not establish reliability for a public line.

Failure modes that pass demos

The graceful demo, hostile production

The test script uses short sentences and perfect audio. Production contains names, corrections, accents, background voices, anger, silence, and unsupported requests. The remedy is a scenario corpus built from real journey shapes, plus edge cases and adversarial tests.

The disclosure that disappears

The opening disclosure exists, but barge-in, routing, voicemail, or resumed sessions bypass it. Treat disclosure completion as a state required before collection and action. Test every entry route.

The helpful agent that over-collects

The system asks broad questions “to help” and stores details irrelevant to the journey. Constrain prompts, entity schemas, and logs. Measure unexpected data classes in transcripts and tool payloads.

The correct intent, wrong identity

The caller genuinely wants an address change but is not authorized for the account. Keep intent and identity decisions separate. Match verification strength to consequence.

The transfer to nowhere

The application marks the task successful when the carrier begins a transfer, while the caller reaches a closed queue. Measure human acceptance and completed context handoff.

The retry that doubles the action

A slow response causes the agent to submit the booking, refund, or message twice. Require idempotency keys, reconcile tool outcomes, and block unsafe retries.

The redacted transcript with unredacted traces

The customer-facing recording policy is respected, but observability captures full prompts and tool results. Scan every store and make redaction part of the logging library.

The human gate that cannot refuse

Reviewers see only a model summary or face a queue too large to inspect. Show final action and evidence, track edits and rejections, and route only genuinely consequential cases.

The vendor change that bypasses acceptance

A new voice, model, transcription engine, or tool schema changes behaviour without review. Pin versions where possible and run regression gates on declared change events.

The metric that hides harm

Containment rises because callers abandon the line. Average call time falls because complex callers are disconnected. Pair efficiency with resolution, complaint, repeat contact, transfer, and correction metrics.

The technical proof pack

The release packet should let another operator reproduce the decision. Include:

1. Call envelope and excluded intents.
2. Architecture and data-flow diagram with processors and regions.
3. Disclosure, consent, recording, and outbound classification decisions.
4. Data inventory and retention schedule for audio, transcripts, metadata, traces, samples, and outcomes.
5. Agent identity, credentials, tools, operations, and policy rules.
6. Authentication matrix by action consequence.
7. Test-corpus description, scenario counts, acoustic conditions, and limitations.
8. Critical-entity, outcome, latency, transfer, and safety results by journey.
9. Adversarial security cases and remediation evidence.
10. Rights-request and deletion rehearsal.
11. Provider outage, queue failure, retry, rollback, and kill-switch rehearsal.
12. Release identifiers, owners, residual risks, and next review date.

Keep factual support near the claim. The FCC ruling on AI-generated voices supports a specific US regulatory point, not a worldwide ban. The ICO analysis of individual rights in generative AI supports lifecycle and rights considerations, not a statement that one architecture is automatically compliant. The ENISA threat-landscape evidence supports the reality of impersonation and AI-enabled threats, not a claim that all synthetic voices are attacks. The McKinsey review of generative AI in customer care supports the observation that value and adoption are uneven, not a guaranteed return.

The implementation starting point is the existing guide to voice AI deployment. This adaptation goes beyond its launch controls by connecting each gate to an executable acceptance decision, an evidence packet, and a fallback state.

A 14-day acceptance sprint

Days 1–2: bound the journey

Choose one call class, list allowed and denied intents, classify direction and jurisdiction, define disclosure, identify data classes, and restrict tools to read-only where possible. Name the operational stop owner.

Days 3–4: instrument the path

Add call IDs, policy decisions, disclosure state, verification state, tool outcomes, transfer acceptance, latency spans, and redacted traces. Confirm that monitoring itself does not create uncontrolled copies.

Days 5–6: build the scenario corpus

Cover representative acoustic conditions, critical entities, unsupported requests, interruptions, identity failures, prompt injection, wrong-party contact, and accessibility needs. Declare expected outcomes before running tests.

Days 7–8: test tools and recovery

Run every permitted and denied operation. Exercise idempotency, timeout, partial success, retry, reconciliation, approval, transfer, reversal, and provider outage. Fix control boundaries, not just wording.

Days 9–10: rehearse privacy and security

Trace one synthetic caller across all stores, complete access and deletion workflows, inspect vendor exports, test redaction, revoke credentials, and run adversarial calls.

Days 11–12: run shadow traffic

Observe consented or test calls without taking autonomous action. Compare proposed outcomes with human decisions. Review errors by consequence and journey, not only aggregate accuracy.

Days 13–14: open bounded autonomy

Enable the smallest reversible action set for a limited traffic segment. Watch severe-event alerts, transfers, repeat calls, corrections, and caller effort. Hold a daily release decision. Expand only when evidence supports the next authority level.

Fourteen days is a review cadence, not a promise that a complex system becomes safe in two weeks. A regulated, multilingual, high-volume, or high-impact journey may require much longer, a formal assessment, or a design change. “Do not launch this action” is a valid result.

Final launch checklist

• [ ] The approved call envelope names allowed and excluded journeys.
• [ ] Inbound and outbound routes have separate classifications.
• [ ] The automation and recording disclosure completes before meaningful collection.
• [ ] The system answers honestly when asked whether it is automated.
• [ ] Audio, transcript, metadata, traces, quality samples, and outcomes have distinct purposes and retention clocks.
• [ ] Critical entities are confirmed before consequential actions.
• [ ] Authentication strength matches the action consequence.
• [ ] The agent has a unique workload identity and short-lived, scoped credentials.
• [ ] Tool authorization is enforced outside the model.
• [ ] Unknown tools, operations, journeys, and unsafe retries are denied.
• [ ] Write actions are idempotent or staged and reversible where possible.
• [ ] Barge-in, silence, overlap, latency, and loop limits are tested.
• [ ] Transfers are measured through human acceptance and context delivery.
• [ ] Wrong-party contact, suppression, opt-out, and frequency caps are verified for outbound calls.
• [ ] Prompt injection, spoofing, cross-account access, and exfiltration scenarios are tested.
• [ ] Logs are redacted but sufficient to reconstruct a call.
• [ ] A synthetic rights request and deletion complete across every registered processor.
• [ ] Provider outage and queue failure produce a safe caller experience.
• [ ] Kill switch, credential revocation, rollback, and restoration are rehearsed.
• [ ] Metrics include resolution, harm, caller effort, correction, and reliability—not only cost or containment.
• [ ] Residual risks, owners, stop thresholds, and the next review date are recorded.

Final decision rule

Launch only the authority you can observe and recover. If the system cannot disclose itself reliably, verify identity proportionately, refuse an unauthorized action, complete a real transfer, and reconstruct a failure, it is not ready for autonomous calls.

The best launch evidence is not a recording of one flawless conversation. It is a set of difficult scenarios in which the system behaves predictably: it asks for confirmation when a number is uncertain, refuses a forbidden tool, transfers when the caller requests a person, respects an opt-out, and falls back cleanly during an outage.

Start there. Then widen the call envelope one journey and one reversible operation at a time. That pace may look slower than switching on every feature, but it is faster than recovering from silent misrouting, repeated unauthorized calls, or a system that no one can explain after the fact.