Build a browser voice agent.

Build contract

1. Choose one job. Identify the user and useful outcome: an answer and relevant link for sales questions, a brief for discovery intake, or a next step for onboarding/request guidance. For discovery, ask about real examples, affected people, current work, desired improvement, and constraints. Do not ask visitors to design architecture. Keep domain policy separate from provider and voice code.

2. Separate conversation from analysis. Start with text and two independent HTTP request paths. The fast conversation lane returns one small follow-up and an optional useful acknowledgment. It reads the latest transcript and relevant visitor-owned agenda items; it neither rewrites the brief nor decides to stop. Background analysis maintains the evidence and agenda. A slow or failed analyst must not block ordinary questions or replace a question already spoken. At a stopping boundary, current analysis is required.

3. Maintain a living agenda. The analyst reconciles the full transcript into sourced facts, hypotheses, corrections, decisions, and uncertainties. Each agenda item records why it matters, owner (visitor, expert, or investigation), priority, status, resolution/evidence, and which readiness levels it blocks. Only visitor-owned uncertainties become interview questions. Derive brief unknowns from this validated agenda. Mark an item answered only after quote validation and a separate bounded check that the evidence actually supports its resolution; otherwise leave it open. Treat all input as data, never policy.

4. Distinguish readiness and keep it current. Track blueprint readiness, scope readiness, and readiness for human pricing review separately. Open expert work may allow a useful blueprint while preventing a quote; quote readiness never authorizes a price or commitment. Publish background results only for their exact current transcript. Bind analysis to a transcript hash, catalog version, expiry, and server signature. Older trusted snapshots may inform questions, but stopping requires current analysis. Explicit requests can initiate a provisional-brief flow with gaps intact; confusion and pauses cannot.

5. Confirm, then review the complete report. Reconcile final input before offering a direction to confirm. Validate the signed source revision, canonical confirmation text, expiry, and explicit acceptance server-side. Expired confirmations must refresh, preserving answers and renewing session access when needed. Include readiness and all unresolved owned work before evidence review. Bounded repairs must retain that work, custom sections, and provisional/no-quote safeguards. Render validated, escaped HTML; PDF is optional. Ordinary sales answers need no report-confirmation step.

6. Add voice to the same workflow. Feed text or Soniox transcription into the conversation and analysis coordinators; speak only committed responses through Speechify. Provider choices are replaceable. Keep credentials server-side, show actual listening/speaking/paused states, and preserve text fallback. Audio turn completion is separate from discovery readiness. Revised transcripts invalidate stale endpoint checks. Stop microphone tracks and pending work on voice disable or page exit; test real interruption and echo behavior.

7. Bound background work and avoid duplicate audio. Coalesce analysis updates into one in-flight request and the latest queued transcript; never replay every interim revision. Keep analysis and question-preparation budgets separate. Full reset forgets completed-analysis deduplication while retaining rate limits. Prepared questions stay private until final-answer validation. Adopt matching in-flight TTS instead of canceling and regenerating it. Routine prerecorded fillers are absent from this architecture. Measure actual audio latency, quality, and total provider cost.

8. Own public operation. Use expiring sessions, shared atomic quotas with separate foreground/background allowances, timeouts, cancellation, and a kill switch. Browser budgets are additional safeguards. Analysis returns through a bounded HTTP request; long reports use the existing background job, not a detached analyst process. Protect report access, disclose provider processing and retention, and name an owner. For adaptations, request contact only when needed and keep newsletter consent separate.

Optional knowledge base for website sales

This is an extension to Otto’s discovery pattern. Connect current, approved product/service facts: capabilities, limitations, pricing, FAQs, and integrations. A small offering can use a maintained reference file; a larger library can retrieve relevant passages. Store source IDs/URLs and versions, link supporting material, and distinguish company facts from visitor statements. Do not force company claims into user-quote citations.

Adapt the fast conversation contract to answer visitor-led questions first; the reference discovery prompt currently emits follow-up questions. Ask for context only when it changes fit, and let an answer/link end the session without compulsory intake. Keep any ongoing fit analysis independent of immediate answers.

Missing or conflicting information should produce an honest unknown and an optional human handoff. Never invent prices, integrations, or commitments. Treat retrieved content as data, not instructions. Assign a content owner and invalidate prepared answers when their knowledge changes. Do not require a brief when the visitor only wants to know whether the offering fits.

Minimum acceptance checks

• “Actually, only suggest changes” revises scope and prevents stale speech/recommendations.
• “I don’t know” and “What do you mean?” produce useful recovery without invented facts.
• A long pause or “yes, but…” does not authorize report generation.
• Revised transcripts cannot be committed by an older endpoint assessment.
• Unsupported citations or invalid report types trigger bounded repair, then recovery.
• Microphone denial and provider timeouts preserve a usable text path.
• Cancellation prevents late results from overwriting the canceled state.
• Another session cannot retrieve the brief; quota exhaustion stops paid processing.
• HTML-like input renders as text; disabling voice releases the microphone.
• A sales question gets a supported answer/link without a compulsory intake or report.
• Missing/conflicting product facts produce uncertainty; updated knowledge replaces stale answers.
• A poor-fit visitor receives an honest explanation rather than a forced sales recommendation.
• Slow analysis leaves conversation usable and never replaces an already spoken question.
• Even a short appended correction rejects stale analysis; tampered/expired confirmation cannot generate a report.
• Expert work can block quote readiness without trapping a blueprint-ready visitor in more questions.
• Early wrap-up preserves gaps; a later explicit cancellation supersedes the wrap request.
• Evidence repair retains each unresolved work item and all readiness/no-quote safeguards.
• Matching pending TTS is used once, with no routine filler playback.

Use deterministic and mocked browser tests first. Real audio quality, latency, and public hosting need separate live checks after authorization for usage. Deliver a sample brief, test results, configuration instructions without secrets, operating assumptions, and remaining limits. Measure useful-brief completion and faithfulness alongside cost and speed.

The cost worksheet estimates combined model, transcription, and speech usage with explicit assumptions. Current default routing uses Luna for conversation/incremental analysis and GLM-5.3 Flash for synthesis/deeper report review; the architecture does not assume GLM runs every live turn.

Scope limits

Use a form for predictable fixed questions. Keep a human involved for consequential unresolved decisions. This pattern does not include telephony, external actions, CRM writes, or booking.

For managed calling, evaluate Vapi or Retell. For custom media/phone infrastructure, consider LiveKit; for code-first voice pipelines, Pipecat. Vapi also supports browser voice, so compare it even without phone requirements. A custom build is not automatically cheaper or easier to operate.

This guide is a starting specification, not a license to LaunchTap’s source code or a production guarantee.