OpenAI's new realtime voice models turn speech into a workflow interface

The useful part of voice AI is not that a chatbot can talk.

The useful part is that a person can keep working while software listens, understands, and moves the next step forward. A dispatcher can update a job while handling a call. A field technician can capture notes without stopping to type. A support team can help a customer in another language without turning the conversation into a slow relay.

That is the business shift behind OpenAI's May 7 release of three realtime audio models in the API: gpt-realtime-2, gpt-realtime-translate, and gpt-realtime-whisper.

The practical question is not "Should we add a voice agent?"

It is: which voice pattern matches the job?

For most teams, the answer falls into three buckets: live voice-to-action, live translation, or live transcription. Each pattern has different risks, costs, controls, and business value.

What OpenAI announced

OpenAI introduced three realtime audio models for API developers:

• gpt-realtime-2, a voice model with GPT-5-class reasoning for natural, agentic voice conversations.
• gpt-realtime-translate, a live translation model that supports 70+ input languages and 13 output languages.
• gpt-realtime-whisper, a streaming speech-to-text model for low-latency live transcription.

OpenAI's Realtime and audio docs frame the decision around the outcome you want to build: use realtime sessions when the experience needs live, low-latency audio; use request-based audio APIs for files, bounded requests, or non-live work.

The API paths also differ by use case. OpenAI's API changelog lists /v1/realtime for realtime voice sessions, /v1/realtime/translations for live translation, and /v1/realtime/transcription_sessions for streaming transcription. The same changelog notes that the Realtime API Beta was removed on May 12, 2026, with users directed to migrate to the released GA Realtime API.

That matters because these are not three names for the same thing. They are three different workflow interfaces.

Pattern 1: voice-to-action with gpt-realtime-2

Use gpt-realtime-2 when the person speaking expects the system to do something, not just capture what they said.

OpenAI describes gpt-realtime-2 as its first voice model with GPT-5-class reasoning. The model is designed for natural voice conversations where the agent can understand intent, maintain context, use tools, and recover when the conversation changes direction.

OpenAI also says Realtime-2 increases context for agentic workflows from 32K to 128K and adds features such as preambles, parallel tool calls with tool transparency, recovery behavior, stronger domain understanding, and better handling of specialized terminology.

In plain business terms: this is the model pattern for a voice agent that can listen and act.

Examples for SMB operations:

• A service dispatcher says, "Move the Johnson job to Thursday morning, assign it to Marco, and text the customer an updated window."
• A sales rep says, "Log this call, mark the lead as interested in the maintenance plan, and remind me to follow up next Tuesday."
• A customer calls and says, "I need to reschedule my delivery, but only if the new date is after my payment clears."
• A field technician says, "Add a note that the pump was replaced, attach the photo I just took, and create a quote for the remaining valve work."

This is where voice becomes a workflow interface. The user does not want a transcript. They want the system to check business rules, call internal tools, explain what it is doing, and ask for confirmation before taking higher-risk actions.

OpenAI's docs recommend gpt-realtime-2 for low-latency voice agents and note that production voice agents generally start with reasoning.effort = low, then adjust based on latency tolerance and task complexity. That detail is important. A demo may prioritize model capability. A production workflow often has to balance capability against response time, cost, and reliability.

A voice-to-action agent is a good fit when the user is already speaking as part of the job, the workflow has clear systems of record, and the possible actions can be limited and approved. It is a poor fit when the business process is vague, the data is messy, or the agent would need broad permission to make judgment calls without review.

If your team is still deciding which workflow should use AI at all, start with the workflow, not the model. That is usually the right place for an AI consulting or AI readiness assessment conversation.

Pattern 2: live translation with gpt-realtime-translate

Use gpt-realtime-translate when the job is to keep a live conversation moving across languages.

OpenAI says gpt-realtime-translate supports speech translation from 70+ input languages into 13 output languages while keeping pace with the speaker. The Realtime docs map live speech translation to a dedicated translation session, not a general voice-agent session.

For business teams, this pattern fits conversations where speed and natural flow matter:

• Customer support for callers who prefer another language.
• Front desk or intake teams serving multilingual customers.
• Field crews coordinating with subcontractors.
• Travel, hospitality, logistics, or service teams where live conversation is part of the work.

This is not the same as creating an official translated record.

MindStudio's explainer makes a useful distinction: realtime translation is for natural conversation flow, not precision legal, medical, or official translated transcripts. That is the right caution. If the output will be used as a compliance record, legal document, medical instruction, or contract term, a realtime translation model should not be the only control.

A translation workflow is a good fit when the priority is helping people understand each other in the moment and a human remains in the conversation. It is a poor fit when the business needs certified translation, exact wording, or legally binding language.

Pattern 3: live transcription with gpt-realtime-whisper

Use gpt-realtime-whisper when the business needs text from live speech.

OpenAI describes gpt-realtime-whisper as a streaming speech-to-text model that transcribes speech live as the speaker talks. The Realtime docs map this to transcription sessions that emit transcript deltas without model-generated spoken responses.

This is the right pattern when the spoken conversation is input to another workflow:

• Live captions for meetings or events.
• Call notes for customer support.
• Job-site observations from field workers.
• Intake summaries for service teams.
• Searchable records of meetings, calls, inspections, or interviews.

The key distinction is output. If you need a spoken response, use a realtime voice-agent pattern. If you need stored or analyzed text, use transcription.

MindStudio summarizes this as the difference between audio-in/audio-out experiences and transcription-first systems where audio becomes text that can be stored, searched, summarized, or routed.

For many businesses, transcription is the safer first pilot. It creates useful data without immediately giving a voice agent permission to change records, send messages, or trigger operational actions.

Why this matters for SMB operations and customer-facing teams

Voice is useful when typing is the bottleneck.

That shows up in customer support calls, field service work, warehouses, clinics, job sites, showrooms, dispatch desks, and multilingual service situations where short spoken updates need to become structured records.

For SMBs, the opportunity is not to replace every conversation with an AI agent. It is to reduce the small delays that pile up across a week:

• Notes that never make it into the CRM.
• Follow-up tasks that depend on memory.
• Calls that require duplicate data entry.
• Customers waiting while an employee clicks through systems.
• Field updates that arrive as voicemails, texts, or incomplete notes.

The right voice workflow can turn a spoken moment into a structured handoff.

That might mean a voice agent updates a job record, a translation session helps a support conversation continue, or a transcription session creates a clean record for later review.

The implementation work is less glamorous than the demo. You need clean handoffs, exception handling, data boundaries, and system permissions. That is why voice AI usually belongs inside a broader process automation plan rather than as a standalone gadget.

What to avoid

Not every voice use case needs a realtime voice agent.

Use a form when the inputs are structured. If the user needs to submit five known fields, a form may be faster, cheaper, and easier to audit. Voice can help when the user is hands-free or when the input is naturally conversational. It adds complexity when the task is already simple.

Use transcription when the business needs a record. If the goal is to capture what was said, do not force the system into a voice conversation. A transcription-first workflow can capture the audio, create text, summarize it, classify it, and route it for review.

Use human review when the action carries risk. A voice agent that says "I'll take care of that" can create trust faster than the system deserves. If the action changes money, schedules, access, legal status, customer commitments, or safety-sensitive records, the agent should ask for confirmation or route the task to a human.

Use screen automation only when voice is not the real interface. Some workflows are still best handled through existing software screens, especially when the system has no API. That is a different pattern from voice. For a contrast, see our recent post on Microsoft Copilot computer use agents and legacy workflows.

Voice is the interface when the work happens through speech. Screen automation is the interface when the work happens through applications that were built for humans to click.

Controls to put in place before production

A voice AI pilot should be designed like an operational system, not like a chatbot experiment.

Before letting a voice agent take action, define the controls.

Start with data boundaries. Decide what the model can hear, store, retrieve, and repeat. That includes customer data, employee data, payment information, health information, confidential business records, and any sensitive notes captured during calls or field work. Your policy should answer what audio is streamed, what transcripts are stored, which systems the agent can query, which fields are excluded, and how mistakes are corrected.

This belongs in a responsible AI plan, not a late-stage security review.

Next, list the approved actions. A narrow first version might create a draft note, update a job status, search a knowledge base, suggest a reply, prepare a customer message for approval, or schedule an appointment inside approved rules. It should not send messages, cancel orders, change pricing, issue refunds, modify access, or make legal, medical, financial, or safety-sensitive commitments without confirmation.

Then decide where a person must approve, edit, or override the AI. Human review is especially important when the model is converting messy speech into structured business actions. Speech includes interruptions, background noise, incomplete thoughts, and corrections. Better model performance does not remove the need for production safeguards.

DataCamp's GPT-Realtime-2 coverage makes a useful caution: higher benchmark-style claims at higher reasoning settings may not match production defaults when teams choose lower reasoning effort for latency, and voice has failure modes that model quality alone does not solve.

Recording and transcript retention also need a policy. Decide whether calls are recorded, whether transcripts are saved, how long records are retained, who can search or export them, how customers and employees are notified, and how deletion requests are handled. Consent and jurisdiction matter.

A voice workflow should also fail clearly. If the system cannot understand the user, cannot reach a tool, or lacks permission to act, it should have a defined fallback: ask a clarifying question, transfer to a human, create a draft instead of taking action, log the issue for review, or tell the user what did not happen.

Finally, test latency and cost with real conditions. A delay that is acceptable in a back-office automation may feel broken in a live conversation. Test noisy audio, interruptions, accents, domain terms, long conversations, tool delays, low-connectivity environments, multiple speakers, and repeated corrections. Also test the cost of always-on or long-running sessions. A voice workflow that works well for one demo call may behave differently across hundreds of support calls or field updates.

A practical first pilot

The best first pilot is narrow, observable, and reversible.

For many SMBs, that means one of these:

• A live transcription workflow for support calls or field notes.
• A translation assistant for a specific customer support scenario.
• A voice-to-action agent that can draft updates but requires approval before sending or changing records.

Start with one workflow where speaking is already natural and the next step is well understood.

For example: after a service call, let technicians dictate the job summary. Convert it into a structured note, suggest follow-up tasks, and require human approval before anything is sent to the customer.

That pilot is useful even if the AI never talks back. It saves typing, improves records, and creates a safer foundation for later automation.

If the workflow proves valuable, the next step may be giving the agent limited actions: update status, create a draft message, or schedule a follow-up inside approved rules.

Voice AI is becoming a practical interface for work. The teams that get value from it will not be the ones that add a talking bot everywhere. They will be the ones that match the voice pattern to the job, put controls around the actions, and measure whether the workflow actually gets better.

If you want help choosing a safe first pilot, BaristaLabs can help map the workflow, risks, and system handoffs through a process automation review.