The agent runtime is the piece that actually holds a conversation. Once a call is connected — a phone caller on a SIP trunk, or a browser mic over QUIC — something has to decide when the caller is done talking, run their words through a model, speak the reply, stop instantly when they interrupt, call your tools mid-sentence, and tear everything down cleanly when the call ends. That is the runtime’s job. You describe the agent; the runtime drives the turns. You do not have to use it. TeleQuick Voice is two separable halves — a transport that moves audio, and a runtime that reasons over it. Bring the runtime and you get turn-taking and tool-calling for free. Bring your own runtime and you use TeleQuick purely as the transport. Both are first-class; pick a path below.

​
What the runtime owns

Give the runtime an agent definition and a live audio stream, and it takes ownership of the whole conversational loop:

Turn detection

Decides when the caller has finished a turn and when they’ve barged in over the agent — with hold-and-confirm so a backchannel (“mhm”, “yeah”) never cuts the agent off.

Model orchestration

Runs the pipeline: either a cascade (speech-to-text → language model → text-to-speech) or a duplex speech-to-speech model that does all three in one streaming session.

Tool calling

Lets the model call your HTTP endpoints and MCP tools mid-conversation, feeds the results back, and keeps the caller engaged while a tool runs.

Session lifecycle

Owns the session from connect to teardown — idle watchdog, re-engage prompts, token and duration budgets, and a hard max-session ceiling.
All of this runs inside the voice gateway, in the same process that terminates the call’s media, pinned to the core that owns the call. Audio never leaves the box to reach the runtime — turn detection and barge-in signalling are wired straight into the media path, which is why interrupts feel instant.

​
Two pipeline shapes

The runtime drives a conversation one of two ways. You choose per agent, and you can mix providers within a cascade.
Three specialised models in a chain. The caller’s audio is transcribed, the text goes to a language model, and the model’s reply is spoken back. You get the widest provider choice and full control of each stage.
caller audio ─▶ ASR ─▶ LLM ─▶ TTS ─▶ agent audio
               │             ▲
               └─ on-device VAD decides "caller finished" ┘
Mix and match — for example transcription from Deepgram, reasoning from your LLM of choice, speech from ElevenLabs or Cartesia. A local on-device VAD marks turn boundaries, so backchannels never wake the model.

Wire your own ASR / LLM / TTS

Set the provider and model for each stage.
Cloud duplex providers (OpenAI Realtime, Gemini Live) are supported today. Serving your own duplex model on-prem is newer — see self-hosted inference for what is production-ready versus still being hardened.

​
Two paths: ours, or your own

The runtime and the transport are decoupled. Decide how much of the stack you want TeleQuick to own:

Use the TeleQuick runtime

The built-in runtime drives the conversation end-to-end. You supply an agent definition and provider credentials; turn detection, tool calling, and session lifecycle are handled for you. Start here for most agents.

Keep your own runtime

Already have a conversation engine — a LiveKit or Pipecat pipeline, your own orchestration? Use TeleQuick as transport only: it delivers audio in and carries your audio out, and your runtime owns the turns.
The rest of this section assumes the TeleQuick runtime. If you are bringing your own, Keep Your Existing Agent Runtime is the whole story — you interact only with the web and telephony transport surfaces.

​
Where the runtime gets its audio

The runtime is transport-agnostic. The same conversational loop drives a call no matter how the caller reached you:
CallerArrives asInside the runtime
Phone (PSTN / SIP trunk)G.711 (PCMU/PCMA) at 8 kHzdecoded to PCM16
Browser / mobile appOpus over QUICdecoded and resampled to PCM16
Internally the runtime works in a single 8 kHz PCM16 audio contract, so an agent behaves identically whether it’s answering a phone call or a web caller. How audio gets to the runtime is covered under transport (web) and transport (telephony).

​
Configure it

Every agent is a config document — pipeline shape, per-stage providers and models, turn-detection tuning, tools, and budgets. You edit it in the console at agent.telequick.dev or through the control-plane API, and the gateway hot-reloads runtime tunables without dropping in-flight calls.

Runtime configuration reference

Every knob: models, turn detection, codecs, budgets, and guardrails.

​
Next steps

The TeleQuick Agent Runtime

Pipelines, providers, and turn-taking out of the box.

Turn detection & barge-in

Tune when the agent listens, talks, and yields the floor.

Tool calling

Give the agent HTTP and MCP tools mid-conversation.

Session lifecycle

From connect to teardown, and the guardrails that bound it.