Start with transcription plus text AI if your telephone intake mainly gathers information for staff to review. Consider a live speech model if callers need a responsive conversation that accommodates interruptions and clarification. The deciding questions are how the workflow recovers, how long callers wait and what evidence staff can review afterwards.
For an ordinary enquiry line, define success as a confirmed request reaching the right person. A pleasant conversation that loses the callback details has not completed intake.
Compare the complete intake paths
In a transcription plus text AI design, speech becomes text before a separate model interprets the request. Your workflow then prepares fields, asks questions or produces a staff summary. If callers need spoken replies, speech generation is another part of that proposed design.
This does not necessarily mean waiting until the call ends. OpenAI’s documentation distinguishes completed-file transcription from Realtime transcription for audio still arriving from a call. Streaming text from an uploaded recording is a different path from processing an ongoing call. Source: OpenAI speech-to-text guide
In a live speech design, the model handles the spoken interaction directly. You still need telephone connectivity, record creation and handover logic around it. Neither model choice establishes those integrations.
The AI agents versus automation comparison helps separate conversational judgement from fixed rules, such as requiring a confirmed callback number before marking intake complete.
What the September Gemini announcement changes
Google’s announcement dated 15 September 2026, updated 17 September, described Gemini 3.8 Live and Extended Thinking. It presented fluid dialogue, language switching and background tool execution; Extended Thinking was positioned for more complex reasoning while conversation continued. These are dated vendor claims, rather than evidence that your telephone workflow will perform successfully. Source: Google’s Gemini 3.8 Live announcement
The useful question is whether continuing conversation during a lookup solves a problem your callers actually face. If intake only captures a message, deeper reasoning may add little value. If callers regularly interrupt to correct details, conversational handling deserves a comparison.
Visual context, also described in the announcement, has no role in a voice-only telephone call unless you separately design an appropriate visual channel. Before deployment, check current product, account, plan and region eligibility for the intended integration.
Recoverability: design the restart before choosing the voice
A separated transcription workflow gives you distinct checkpoints to design: captured speech, transcript, extracted details and saved request. If extraction fails, retained permitted evidence can support another attempt without asking the caller to repeat everything. This is a proposed recovery design, not an automatic property of transcription.
A live speech workflow also needs explicit saved state. After a dropped connection, staff should see which details the caller confirmed, which remain uncertain and whether any record was created. Conversational memory alone should not be the handover record.
For either path, give the call and intake request identifiers. Before retrying a record creation step, check whether it already succeeded. A timeout can mean the response was lost after the record was saved.
Tell callers what remains unresolved. “Your request has been captured; the team still needs to confirm availability” is appropriate only after capture succeeds. Otherwise, explain the failure and offer the agreed fallback.
Latency: measure the pauses callers experience
Compare the time from the caller finishing a turn to a useful response. Also observe interruption handling, confirmation questions and the silence before an external lookup finishes. A quick acknowledgement and a completed answer are separate events.
For transcription plus text AI, examine delays across transcription, interpretation, lookup and spoken reply. For live speech, examine the same caller journey, including any work happening in the background. Do not assume either architecture is faster on your telephone connection.
Use equivalent intake tasks and the same destination system. Record ordinary pauses and the longest waits, alongside repeat questions and abandoned calls. Set acceptable limits as proposed operating rules before comparison.
During a slow lookup, acknowledgement should describe progress without promising success. If waiting becomes unreasonable under your chosen rule, offer a callback or human transfer. The fallback needs testing too.
Reviewable records: preserve confirmation and uncertainty
Staff need more than a polished summary. Propose a record containing the request, callback details, caller-confirmed fields, unresolved questions, outcome and a reference to retained evidence where appropriate. Keep the caller’s request separate from anything the agent promised.
Structured output can help enforce an agreed record format. OpenAI documents schema adherence for Structured Outputs. Correct formatting should still be checked against the conversation: a required field being present does not establish that the caller supplied or confirmed its value. Source: OpenAI Structured Outputs guide
Similarly, requesting an action is separate from executing it. OpenAI’s function-calling guide places execution in the application-side workflow. Design intake so that record creation results are checked before the voice reports success. Source: OpenAI function-calling guide
Have the appropriate people decide recording notices, access and retention for this intake purpose. Where audio is not retained, document what evidence reviewers will have and how disputes will be resolved.
Telephone intake architecture decision table
Use this proposed table with your operations lead and implementation partner. Record the selected path and unresolved conditions before building.
| Intake condition | Starting choice | Required evidence or control |
|---|---|---|
| Recorded messages are reviewed after the call | Transcription plus text AI | Staff can inspect extracted details against retained, permitted evidence. |
| Callers need a conversation with corrections and interruptions | Compare live speech with a streaming transcription workflow | Test useful response delays, interruptions and successful confirmation on equivalent calls. |
| Failed extraction must be retried without another call | Transcription plus text AI, with designed checkpoints | Retain permitted source evidence and separate extraction from record creation. |
| Callers wait while a system checks information | Consider live speech | Acknowledgements distinguish pending work from completed results; provide a waiting fallback. |
| Staff need a dependable handover | Either, with an explicit record workflow | Save confirmed fields, uncertainty, outcome and evidence references. |
| A retry could create another request | Either, with duplicate protection | Check the original request identifier and save result before repeating creation. |
| Important details remain missing or ambiguous | Human clarification through either path | Keep fields unresolved; do not infer details needed for follow-up. |
Decision record: Chosen path: ____ Reason: ____ Unresolved condition: ____ Fallback owner: ____ Evidence required before launch: ____
Worked examples: ordinary, incomplete and duplicate intake
These scenarios are hypothetical, and their handling rules are proposed.
Ordinary enquiry. A caller asks a maintenance business to contact them about a leaking tap. They provide a name, callback number and suburb. With transcription plus text AI, the workflow extracts those details and asks for confirmation through the designed voice path. With live speech, the model conducts that exchange directly. Expected handling: save the confirmed request for staff review, without promising a visit or price.
Missing detail. The call drops before the callback number is confirmed. Expected handling: mark intake incomplete and preserve the available request. A staff member reviews whether an existing verified contact provides a suitable follow-up route. If none exists, leave that limitation visible; neither architecture should invent a number or report a scheduled callback.
Ambiguous request. A caller says, “Please come next Friday,” but the intended date remains unclear. Expected handling: ask for the calendar date and read it back. If clarification fails, save the wording with the date unresolved. Staff contact the caller before making arrangements. A tidy summary must not silently turn ambiguous speech into a commitment.
Possible duplicate. Record creation succeeds, but its response times out. The workflow attempts recovery. Expected handling: check the original request identifier, retrieve the existing record if found and avoid creating another. If a caller phones again separately, staff review whether this is a new request or an update before merging anything.
FAQ: choosing a telephone intake architecture
Can transcription plus text AI ask questions during a call?
Yes, as a proposed connected workflow using ongoing transcription, text interpretation and a spoken reply path. File transcription alone does not establish that conversation. Confirm how the implementation handles incomplete turns and caller interruptions.
Does a live speech model remove the need for a transcript?
Decide what staff need to review. You may design a transcript, confirmed field record or both, subject to appropriate recording and retention decisions. Evaluate the actual record produced; natural conversation does not establish its completeness.
Should we combine live speech with later text review?
Consider it when responsive conversation and detailed staff review both matter. Keep the live confirmation record and later interpretation distinguishable. If later review changes an important detail, flag the discrepancy for a person rather than silently replacing what the caller confirmed.
If your business needs help selecting this workflow, explore AI chatbots within AI automation. Bring the completed decision table when you get in touch. The custom AI agents workflow guide and custom AI agent definition explain how a proposed agent connects to a defined business process.