TeleQuick Agent Runtime

You don’t assemble a voice agent from parts. TeleQuick ships a complete runtime that runs the whole conversation loop for you: it listens, decides, speaks, takes turns, and calls tools — all inside the same engine that terminates the call, with no orchestrator to stand up and no glue to write. You describe the agent (which models, what it says, which tools it can use) as a small config, and the runtime does the rest. Point it at a phone number or a browser session and it just talks.

What “batteries included” means here

Everything below is already built and running in-process. You opt into the pieces you want and override defaults where you need to.

A ready pipeline

Speech-to-text, language model, and text-to-speech nodes pre-wired as a conversation graph. Or a single speech-to-speech node. No DAG to hand-build.

A provider registry

First-class ASR, LLM, TTS, and realtime providers behind one interface. Swap any stage by changing a string; drop in your own keys.

Turn-taking wired in

Barge-in, end-of-utterance, and idle handling run end to end — from the caller’s audio to the model and back — with no client code.

A built-in tool belt

The agent can transfer, hold, route to a skill, or send DTMF out of the box, and call your own HTTP and MCP tools mid-conversation.

Two ways to run the conversation

The runtime supports two pipeline shapes. Pick per agent — most teams start cascaded and move latency-critical agents to speech-to-speech.

Shape	How it works	When to use
Cascaded	Separate ASR → LLM → TTS nodes. You mix and match the best provider at each stage.	Maximum control over model choice, cost, and voice; easiest to reason about and swap.
Speech-to-speech	A single realtime node owns the audio path end to end (the provider does its own listening and speaking).	Lowest turn latency and the most natural prosody.

Cascaded (ASR → LLM → TTS)
Speech-to-speech (realtime)

agent.json

{
  "entry_node": "ASR",
  "turn_detection": { "type": "silero", "silence_duration_ms": 500 },
  "pipeline": {
    "ASR":  { "node_type": "ASR",  "provider": "deepgram",  "next_node": "LLM" },
    "LLM":  { "node_type": "LLM",  "provider": "anthropic",
              "model": "claude-sonnet-4-5",
              "system_prompt": "You are a friendly support agent.",
              "next_node": "TTS" },
    "TTS":  { "node_type": "TTS",  "provider": "elevenlabs",
              "voice": "21m00Tcm4TlvDq8ikWAM", "next_node": "PUSH_AUDIO" },
    "PUSH_AUDIO": { "node_type": "PUSH_AUDIO", "next_node": "ASR" }
  }
}

agent.json

{
  "entry_node": "REALTIME",
  "pipeline": {
    "REALTIME": {
      "node_type": "REALTIME",
      "provider": "openai",
      "model": "gpt-realtime",
      "voice": "shimmer",
      "system_prompt": "You are a friendly support agent."
    }
  }
}

When the entry node is REALTIME and you don’t set a turn_detection type, the runtime auto-promotes turn detection to server_vad — the realtime provider owns the audio path, so on-device VAD would never actually run. Override it back to silero if you specifically want gateway-side detection.

You apply this config from the voice console at agent.telequick.dev or through the control-plane API; it’s stored per agent and loaded when a call reaches that agent. See Configuration for the full field reference.

Pipeline nodes

A cascaded agent is a graph of typed nodes. entry_node names where a turn starts; each node’s next_node points to the next. Beyond the three conversation nodes, the runtime ships call-flow nodes so you can build an IVR without leaving the config.

Node	What it does
`ASR`	Streams caller audio to a speech-to-text provider; emits interim and final transcripts.
`LLM`	Runs the transcript (plus history and tools) through a language model and returns the reply.
`TTS`	Turns the reply text into audio.
`REALTIME`	Speech-to-speech: hands the audio straight to a realtime provider that listens and speaks.
`PUSH_AUDIO`	Streams synthesized audio back to the caller; the barge-in path clears its buffer on interrupt.
`GREETING`	Plays an opening line at call connect before the loop begins.
`GATHER`	Collects DTMF digits or a spoken response, with timeout and retry branches.
`MENU`	Branches by DTMF digit (press 1 for sales, 2 for support…).
`TRANSFER`	Hands the leg to a SIP or E.164 destination.
`HANGUP`	Ends the call.

You rarely author nodes by hand. The visual agent builder in the console emits this graph for you; the JSON is the ground truth the runtime loads.

The provider registry

Every ASR, LLM, TTS, and realtime backend sits behind one registry. Selecting a provider is a string on the node — no code, no redeploy. The runtime brings credentials from your tenant vault (sealed at rest) or from the environment, so you can bring your own keys per stage.

Provider	ASR	LLM	TTS	Speech-to-speech
`openai`		✅ default	✅	✅
`anthropic`		✅
`gemini`		✅		✅
`deepgram`	✅ default		✅
`elevenlabs`	✅		✅ default	✅
`cartesia`			✅
`ollama`		✅ (self-hosted)
`xai`	✅		✅	✅

The registry accepts more identifiers than the headline set above — regional and self-hosted ASR/TTS options, plus a self-hosted inference gateway for running your own models. See BYO ASR / LLM / TTS, BYO speech-to-speech, and Self-hosted inference.

Defaults and fallbacks. Leave a cascaded stage’s provider empty and you get the defaults marked above (deepgram ASR, openai LLM, elevenlabs TTS). An LLM node can also declare llm_max_retries and an llm_fallback_provider, so a failed turn retries the primary and then falls back once to a second provider before giving up — resilience without you writing retry logic. If a provider’s credentials aren’t configured, the registry returns nothing for that stage rather than erroring the whole call: an unconfigured ASR simply drops audio, and a streaming TTS falls back to the one-shot synthesis path so the caller still hears the reply.

Turn-taking, out of the box

Barge-in and end-of-utterance are wired from the caller’s audio to the model and back — you pick a mode and tune a few timings; the interrupt travels a single control path for you.

silero (default) — on-device voice-activity detection on the gateway. Right for cascaded pipelines.
server_vad — the realtime provider decides turn boundaries. Auto-selected for REALTIME entry nodes.
energy / none — a lightweight energy gate, or fully manual.

The runtime also runs an idle watchdog (re-engage after silence, then hang up) and hold-and-confirm barge-in so short backchannels like “mhm” don’t cut the agent off. Full schema, defaults, and a barge-in support matrix live in Turn detection & barge-in.

Tool calling

Your agent can act on the world mid-conversation. The runtime advertises a set of tools to the model each turn and executes whatever the model calls. Built-in telephony tools are available to every agent with no setup — the model can transfer_call, route_to_skill, hold_call / unhold_call, send_dtmf, disconnect_call, and request_supervisor, and the runtime issues the corresponding control action on the live leg. Per-trunk realm rules govern where a call may be transferred. Your own tools plug in three ways:

HTTP tools — describe an endpoint and its JSON schema; the model calls it and the runtime makes the request (bearer / basic / header auth supported).
MCP tools — point at a Model Context Protocol server; the runtime runs tools/list and registers every tool it exposes.
Client tools — surface a function your app fulfills, for actions that must run in your environment.

Scope which tools a given node may call with a per-node tool_allowlist (empty means all of the agent’s tools). Full walkthrough in Tool calling.

Where sessions live

Each call gets a runtime session pinned to the core handling the leg, with its own turn-detector state, provider sessions, and deadlines. Timeouts and the maximum session length are configurable and hot-reload without dropping in-flight calls (running sessions keep the deadlines they started with). See Session lifecycle.

Next steps

Runtime overview

How the runtime drives a live conversation, start to finish.

Configure an agent

Every field in the agent config, with examples.

Bring your own models

Swap in your own ASR, LLM, and TTS providers and keys.

Tool calling

Give the agent HTTP, MCP, and client tools.

​What “batteries included” means here

A ready pipeline

A provider registry

Turn-taking wired in

A built-in tool belt

​Two ways to run the conversation

​Pipeline nodes

​The provider registry

​Turn-taking, out of the box

​Tool calling

​Where sessions live

​Next steps

Runtime overview

Configure an agent

Bring your own models

Tool calling

What “batteries included” means here

Two ways to run the conversation

Pipeline nodes

The provider registry

Turn-taking, out of the box

Tool calling

Where sessions live

Next steps