Give Your Chat Agent a Voice

Linear, PostHog and Attio all putting chat on their home screens raises a practical question: once an application has an agent, where else should that agent be able to participate? Luke Harries frames 2025 as the year SaaS products either died or became AI-first by adding chat. The appeal is straightforward: a declarative interface lets users ask for an outcome, while the agent uses tool calling and retrieval-augmented generation, or RAG, to carry it out. Even government services are exploring the pattern with GOV.UK Chat.

Voice extends that interface beyond typing. Harries emphasizes speed, interactivity and accessibility, particularly for people who struggle with keyboards or have dyslexia. It also opens additional channels: the same conversational capability can become available wherever people already speak.

Consider his hypothetical PostHog example: an analytics agent could join a Zoom call and correct an incorrectly quoted statistic. A customer-support agent could gain a phone line. These are different places to use an existing agent’s knowledge and actions, which makes adding voice more consequential than putting a microphone beside a text box.

ElevenLabs began with text-to-speech models, then found itself building a broader agent solution for customers such as Revolut’s customer-support operation. That solution separates naturally into two layers.

The voice layer manages the spoken interaction; the orchestration layer determines what the agent knows and does. Keeping that boundary explicit makes it possible to change the interface without replacing the agent’s underlying behavior.

For a team starting from scratch, adopting both layers together is convenient. But an existing agent may already embody substantial work on evaluations, transcriptions and application behavior. Rebuilding that system just to support speech would discard much of the investment. Voice Engine packages the voice layer as a separate primitive that can wrap an existing agent. Harries presents it as an early preview, with release expected a couple of weeks after the talk; the SDK walkthrough and companion skill below describe that preview, not a verified current API contract.

The proposed bundle combines Scribe speech recognition with V3 text-to-speech. Harries describes Scribe as the most accurate model, but supplies neither a benchmark nor a model version for that claim.

Between recognizing speech and producing it sits turn-taking. A pause does not necessarily mean a person has finished speaking. Harries describes emotion- and context-aware turn-taking, pause detection and semantic voice activity detection, or semantic VAD, as parts of the engine. Their purpose is to help determine when the agent should respond instead of treating every silence as a completed turn. Harries also describes support for thousands of voices, alongside multiple languages.

For the developer, the value of this bundle is that the speech models and conversation mechanics arrive together. A team that has already built a complex chat agent can concentrate on connecting that agent rather than assembling every part of the voice interaction itself.

The server-side integration follows a short sequence:

1. Create the client.
2. Create the Voice Engine.
3. Attach a wrapper around the existing chat agent.
4. For each new session, start a loop that proxies the interaction to that agent.

The session loop is the connection between the two layers: the engine handles the spoken conversation while the existing agent handles the request.

An application-owned TypeScript adapter can express that boundary with a text-turn stream and a reply sink. The names here describe the adapter contract rather than preview SDK methods:

interface VoiceSession {
  userTurns: AsyncIterable<string>;
  sendReply(text: string): Promise<void>;
}

interface ChatAgentSession {
  reply(text: string): Promise<string>;
}

async function proxySession(
  voice: VoiceSession,
  agent: ChatAgentSession,
): Promise<void> {
  for await (const text of voice.userTurns) {
    const reply = await agent.reply(text);
    await voice.sendReply(reply);
  }
}

For a turn such as Hello, how are you?, the adapter passes the text into the existing agent and returns its response to the voice layer. Speech recognition, speech synthesis and turn-taking remain outside this application-level loop.

The client SDK supplies the user-facing entry point. Harries describes the website widget integration as basically three lines. He also presents telephony and contact center as a service, or CCaaS, as largely available out of the box once the agent is wrapped. The intended progression is one server integration followed by the channels through which users reach it.

The UI components follow shadcn/ui and Vercel-style conventions. Harries positions them as components a coding agent can work with, extending the developer-experience goal from connecting the backend to building the interface.

The local demonstration begins with a generic support chat. Harries sends “Hello, how are you?” and receives a reply, establishing that the existing text agent works before adding voice. Harries says the conversion can take about one prompt using a skill planned to accompany the release.

The proposed skill would analyze the codebase, find the chat agent, determine how to deploy it and work out how to wrap it. Harries then shows the resulting integration code: a Voice Engine attaches for each new session and starts proxying to the existing agent. The demonstrated sequence reaches the wrapper code; it does not include a completed spoken exchange or deployment commands.

The broader proposal is to build at a higher level than separate speech-to-text and text-to-speech primitives. Once speech, turn-taking and session handling are bundled, developers have two distinct adoption paths.

The choice depends on whether the team already owns the agent orchestration it wants to keep. The wrapper preserves that investment; the full platform provides an out-of-the-box starting point.

Harries closes the presentation with a prediction that chat agents will either remain chat agents and die or begin adding voice. He also invites early design partners to help develop the product. The architectural proposal is concrete even at this preview stage: let voice become another interface to an agent rather than a reason to rebuild it.

The audience’s final technical question tests that boundary: how does tool calling work? Harries answers that the existing backend chat agent normally already performs most tool calls. Adding the voice wrapper does not require reimplementing those tools. The wrapper can hand the interaction to the agent that already knows how to perform the work.

There is another boundary within the tool system:

• Client-side tools can act in the frontend—for example, manipulating the DOM. ElevenLabs documents this category as client tools.
• Server-side tools run on the backend, where the existing chat agent will commonly already handle tool calling.

Harries describes forwarding some of these tool calls to the wrapped agent as a planned addition. That future proxying capability is separate from the central integration demonstrated here: preserving the backend agent’s existing tool behavior while adding a spoken interface.