“Tell us about your project” asks quite a lot of someone who isn’t sure what the project should be.
They might know that their team keeps copying information between three tools. Or that an AI experiment looks promising but nobody trusts it with the real workflow. They may be wondering whether to replace a subscription, add an agent, or leave the software alone.
A good first conversation should help them work that out.
That is the job behind Otto, the voice-and-text discovery agent I’ve been building for LaunchTap. It asks about the situation, follows consequential details, and turns the conversation into a brief the visitor can use with or without us.
The useful part is the change from “I have an idea” to “Here is a direction, why it might help, and what we still need to find out.” Voice is one way to get there.
It also suggests a broader website sales pattern: let visitors ask what they need to know, in their own words, and quickly work out whether your product or service is for them. Otto uses the conversation for discovery intake. A version connected to product or service knowledge could help with the questions that come before that.
Start with the problem
Imagine someone explaining that their inventory records are unreliable.
Asking them which confidence threshold should trigger an automated database update would push the design problem back onto them. A more useful question is: what happens when a record is wrong?
That answer might reveal a minor inconvenience, a repeated shipping mistake, or a consequential decision that needs review. The implementation should follow from that context.
Otto’s discovery policy makes this distinction explicit. The visitor describes what happens now, who is affected, what better would look like, and the constraints they know. Otto is responsible for proposing a direction and identifying what needs validation.
It can explore an internal AI workflow, bespoke software, or a SaaS strategy question. It should also be able to conclude that AI or a custom build is a poor fit. A conversation that only leads to the service you sell is a weak discovery tool.
What we built
Otto uses Soniox for streaming transcription, a configured language-model provider for discovery and report generation, and Speechify for spoken responses. The browser provides the interface, microphone handling, and playback. There is a text path through the same discovery workflow.
The custom work sits around those components: how a conversation progresses, how corrections invalidate earlier work, what belongs in the brief, and when the system is allowed to move forward.
That is the meaningful sense in which this was built from scratch. I did not build a speech recognizer or train a voice model.
A voice platform is a legitimate option for this kind of project. Vapi, for example, supports web integration as well as phone calls and lets developers choose components. The decision isn’t explained by saying these platforms only do telephony.
For Otto, the case for a custom implementation is the close relationship between the conversation and the product on screen. The same state needs to control the visible question, spoken question, evolving understanding, confirmation, and final document. Owning that workflow makes its behavior directly inspectable and changeable.
That flexibility comes with work: browser audio behavior, stale responses, interruption handling, provider failures, abuse controls, and upgrades. I haven’t established that this approach is cheaper or faster than configuring a platform. It is a design choice to test against the job, rather than a general recommendation to build your own voice infrastructure.
Intelligence and response time
Voice puts a tight budget on how long someone can comfortably wait. A model that produces an excellent written analysis after a long pause may be a poor choice for every conversational turn.
That makes model choice and task size important, but it doesn’t justify saying most voice platforms use unintelligent models. ElevenLabs recommends evaluating latency and task complexity, offers a range of models, and supports custom LLM endpoints. ElevenLabs model options
OpenAI’s Realtime models accept and produce audio directly; they aren’t simply a small text model hidden behind a voice. OpenAI also publishes a chat-supervisor example pairing a realtime conversational agent with a more capable text model for harder work. Splitting those responsibilities is an established pattern. Realtime model, OpenAI’s example
Otto applies that principle to discovery. It gives different jobs different response-time requirements, then defines exactly how their results can affect the conversation.
Choosing the models
The configured model is GLM-5.3 Flash, which is distinct from full GLM-5.3. I selected it as a practical cost/capability tradeoff for the deeper work: synthesizing a direction and reviewing the resulting brief. That is a product choice, not a claim that it outperforms every model available through a voice platform.
In the current OpenRouter route, Otto’s short conversational responses, incremental agenda analysis, and lightweight checks default to GPT-5.6 Luna. GLM-5.3 Flash handles final synthesis and the deeper report audit. Those choices are separately configurable. The architecture can accommodate a different analyst or report model without rebuilding the microphone and playback experience.
The published non-promotional GLM-5.3 Flash rate on the reviewed OpenRouter provider listings is $0.15 per million input tokens and $0.50 per million output tokens. Some routes currently offer temporary discounts. That makes repeated report work inexpensive enough to evaluate, but price alone cannot establish reasoning quality. Model and provider pricing
The practical question is whether it preserves corrections, separates evidence from assumptions, and produces a useful brief at an acceptable cost. The project includes evaluations for those behaviors; there isn’t a controlled model comparison establishing a universal intelligence-per-dollar winner.
Three jobs, different timing
The newer design has two independent lanes during conversation and a report step after confirmation.
The conversation lane returns one small follow-up, with an optional useful reflection. It doesn’t rebuild the whole brief or decide whether discovery is complete. The analysis lane reconciles the transcript into a living agenda: what we know, what remains uncertain, why it matters, and who should resolve it. The report step assembles and checks the deliverable after the visitor accepts a direction.
That separation is the main latency decision. Ordinary follow-ups can continue while analysis works. A final readiness check can take longer, with a visible explanation of what Otto is doing. We haven’t made deeper reasoning instantaneous; we’ve placed it where the interaction can accommodate it.
Several supporting decisions make that separation useful:
- Coalesce background work. Keep one analyst request in flight and the latest queued transcript, with explicit budgets. Don’t launch a complete analysis for every new transcribed word.
- Make freshness a condition of action. An older agenda can inform a question, but stopping needs current analysis. Signed transcript revisions and expiring confirmations prevent old conclusions from authorizing a new brief.
- Prepare without speaking prematurely. Generate a likely follow-up during the visitor’s answer, then validate it against the finished answer. Corrections can discard it.
- Reuse audio already in progress. When prepared speech matches the committed response, adopt that TTS stream rather than canceling it and paying the latency of another request. Routine prerecorded fillers have been removed.
- Protect the final result. Include readiness and unresolved work before evidence review. Repairs must retain that work and its meaning, rather than quietly producing a cleaner-looking but incomplete brief.
These are engineering choices developed for Otto, not claims that nobody else has used the underlying techniques. A recorded local check produced a complete follow-up question in 1.69 seconds; that was text generation, not end-to-end audio latency. Real-device speech-end-to-audio percentiles remain the measurement that matters.
What the custom workflow adds
The advantage is the discovery behavior we have implemented and can inspect:
| Otto behavior | Why it matters |
|---|---|
| A living agenda with visitor, expert, and investigation owners | Visitors aren’t trapped answering technical questions that belong to the delivery team |
| Separate blueprint, scope, and quote readiness | We can offer a useful direction while being honest that pricing still needs investigation |
| Transcript-bound stopping and explicit confirmation | A late correction can change the direction before the system acts on it |
| Evidence checks and preserved unresolved work | The brief shows what still needs to happen, with responsibility attached |
| Shared state across voice, text, and the on-page brief | The conversation leads directly into a usable website artifact |
Selecting a voice and writing a system prompt doesn’t supply this entire application contract. A managed platform may provide components for building it; it would still need to be configured, extended, and tested for this specific outcome. Model choice, knowledge bases, tools, and low-latency speech are not exclusive to Otto. ElevenLabs, for example, already provides those building blocks. Platform overview
For a straightforward website sales assistant, those bundled capabilities may be the better starting point. Our text-mediated pipeline also means the reasoning models receive a transcript rather than the original sound; it does not give them direct access to every vocal cue. Custom ownership brings control and an ongoing integration workload.
Details that make it useful
The end of a speaking turn is different from the end of discovery
“I don’t know” can be a complete answer. It doesn’t mean the information is now known. A pause can mean someone is thinking. It doesn’t mean they’ve approved a recommendation.
Otto separates audio turn-taking from the question of whether there is enough information to propose a useful direction. It can rephrase, ask about an example, or preserve an unknown. It should stop asking when a useful provisional brief is possible, rather than insisting that every field be filled.
It can prepare while listening without committing to an unfinished thought
A conventional sequence waits for speech to finish, transcribes it, asks a model what to say, and then generates audio. Those waits can add up.
Otto can begin preparing a follow-up from an interim transcript. That work stays private until the answer is committed. If the final answer matches, the prepared result may be reused. If it changes, the system validates the response or plans again. Corrections can invalidate preparation entirely.
Consider: “We need the agent to update the records—actually, it should only suggest changes.” A response prepared before that correction must not get to decide the next step.
This is a useful latency technique, with a correctness constraint attached. It is not evidence of a universal response-time guarantee. A meaningful measurement would include actual speech-end to first response audio, failed interruptions, question quality, and provider cost across real sessions.
The brief distinguishes what was said from what was inferred
Otto maintains separate facts, hypotheses, unknowns, corrections, and decisions. Facts need an exact supporting quote from a user message. Corrections should remove superseded claims and affect the recommendations built on them.
At the end, Otto proposes a direction and asks the visitor to confirm it. Report generation and a separate evidence review follow that acceptance. If review still fails after a bounded repair attempt, the system offers recovery rather than presenting the unchecked report as finished.
This improves traceability. It does not prove a visitor’s statement is true, and a second model can still miss a problem. The brief is a useful starting document whose assumptions need validation.
Voice remains optional
Typing should remain available if a microphone is unavailable, a provider fails, or the visitor simply prefers text. A visible listening state matters. So does stopping microphone tracks when the visitor disables voice or leaves.
The animated presence is a nice part of the experience, but the underlying states need to remain understandable without it. If you build your own version, get the conversation, correction handling, and output working before spending time on the visual treatment.
Where this pattern fits
Help website visitors work out whether you’re a fit
A visitor might ask, “Can this work with the tools we already use?” or “We already built something—can you help us maintain it?” They should be able to get a useful answer, ask a follow-up, and find the relevant product page or next step without first booking a call.
That could make this a useful sales experience directly on a website. Answer the visitor’s question first. Ask for context when it would help assess fit. Be willing to explain a limitation or say the offering probably isn’t right for them. Sometimes the useful outcome is simply an answer and a link; there is no reason to make every visitor complete an interview or generate a report.
A version intended to answer detailed sales questions would need access to current, approved product or service information. Start with a small maintained set of FAQs, capabilities, limitations, pricing information, and integration documentation. A larger knowledge base could supply relevant passages as questions arise. Show supporting links, and make uncertainty explicit when the information is missing or conflicting.
That knowledge access would be an extension to the pattern described here. Otto’s current service catalog guides discovery; it isn’t a general product knowledge base. A sales version should not guess about an integration, invent a price, or turn a roadmap idea into a promise.
Replace a discovery intake form with a conversation
This is how we’re using the pattern with Otto. Someone arrives with an incomplete idea, the conversation helps clarify it, and they leave with a brief. Follow-up questions can respond to their situation instead of making them work through a long form with fields that may not apply.
Support similar conversations on the web
Other adaptations could help someone choose an onboarding path, explain a request in a customer portal, or prepare a research intake. The outcome might be an answer, a relevant page, a recommended next step, or a structured summary. All can stay within the website experience, with voice and text available.
The pattern is particularly interesting when an adaptive question can change the recommendation. If everyone gets the same questions regardless of their answers, a well-designed form may be easier to complete and maintain.
It also needs an owner. Someone has to keep product information current, decide whether the questions help, check that answers and briefs are supported, and handle the cases the system gets wrong. A working microphone is a small part of that responsibility. For the sales adaptation, test whether visitors resolve their questions and understand fit; improved conversion is a hypothesis to measure.
When to use something else
| What you need | A sensible place to start |
|---|---|
| A small set of predictable facts | A form, possibly with optional dictation |
| An unresolved, consequential business decision | A human conversation, potentially supported by an AI-prepared brief |
| Managed inbound/outbound calling and voice-agent workflows | Vapi or Retell |
| Custom realtime agents with phone integration and media infrastructure | LiveKit and its telephony stack |
| A code-first framework for voice and multimodal pipelines | Pipecat |
Vapi and Retell are worth evaluating when calling operations are central. LiveKit documents inbound/outbound telephony and SIP integration; Pipecat provides an open-source framework for assembling voice pipelines. They involve different amounts of application and operational ownership, so compare them against your actual requirements. These are starting points, not results of a controlled comparison.
Otto’s current browser implementation is not a phone system. Adding phone numbers, transfers, carrier behavior, or call-center operations changes the scope substantially. Even for a browser-only product, a managed platform may save enough integration and operational work to justify itself.
Operating a public voice agent
An agent on a public page can consume paid APIs. It needs bounded sessions and usage, cancellation, failure recovery, and an honest account of where conversation data goes.
The current implementation includes signed sessions, a human-check integration, and shared usage counters. Hosted brief generation temporarily stores conversation data for background processing. Raw microphone audio is processed by the transcription provider; generated speech text and discovery text go to their respective providers. This isn’t a browser-only privacy architecture.
Those controls are implementation details, not evidence that every production condition has been tested. Real-browser and real-audio acceptance testing still matters. So do ongoing provider costs and the quality of the finished brief.
There are product limits too. The current contact flow asks for a name, email, and phone number before discovery. Calendar scheduling is still a demonstration; it does not create a booking. Neither feature should be confused with a completed sales integration.
Costs and the build guide
For budgeting, I modeled one aggregate hour across six ten-minute discovery sessions, including six generated briefs. With twelve minutes of Otto speech, allowance for unused prepared audio, repeated transcript input, and additional model work, the estimate is about $0.90 in LLM + transcription + speech-generation usage. Lighter and heavier scenarios come to roughly $0.40–$2.85.
Those are assumption-based variable API costs, not measured bills or the complete cost of operating the service. Hosting, maintenance, subscription minimums, and payment/platform fees are separate. The current application’s session limits also mean this is not a promise of an uninterrupted hour-long call. The cost worksheet shows dated provider rates, request counts, token assumptions, and formulas so you can replace them with real usage.
For context, public rates checked September 5, 2026 put ElevenLabs Agents at $4.80 per conversation hour plus LLM usage, and Vapi at $3.00 plus speech, model, and transport charges. Retell with its platform voice and GPT-4.1 mini works out to $5.16/hour. Speechify’s bundled agent overage rates are $4.08–$4.50/hour depending on plan. These configurations include different features and don’t automatically reproduce Otto’s discovery workflow. ElevenLabs, Vapi, Retell, Speechify
Direct OpenAI Realtime is a closer cost competitor. For the same speaking proportions, GPT-Realtime-2.1 Mini’s new audio alone is about $0.50/hour, before text, history, reasoning, and any separate discovery analysis. That is an incomplete cost, but enough to rule out claiming every alternative is dramatically more expensive. The comparison worksheet includes both managed platforms and direct Realtime. Mini pricing, Realtime billing
At modest website traffic, a few dollars per conversation hour can easily be outweighed by maintaining a custom system. The stronger reason to build Otto was control over the discovery outcome: what it asks, how it handles corrections, when it can stop, and what the visitor leaves with.
I’ve drafted a companion AI build guide that describes the architecture, behavior, build order, and acceptance checks. You can give the Markdown to a coding agent or use it as a starting specification with your team.
It is a recipe for adapting the pattern, not a promise that one prompt will reproduce Otto or deliver a production-ready system. Begin with a text conversation that answers a visitor’s question or creates a useful brief. Add voice when you have a reason to believe speaking makes the task easier.
The question I would start with is simple: What should someone be able to leave this conversation with?
If your team has a promising AI interaction and needs help turning it into a dependable product capability, LaunchTap can help with that work.