Deepgram is the default speech-to-text provider for a cascaded TeleQuick Voice agent. When you run an ASR -> LLM -> TTS pipeline, the caller’s audio streams into Deepgram over a persistent socket and comes back as interim and final transcripts — the runtime feeds those to the language model as soon as the caller stops talking. It is a shipped integration: a bare cascade with no asr_provider set already uses Deepgram. You wire it in one config field, drop in a key, and place a call. No code, no rebuild.

​
Turn it on

1

Select Deepgram for the ASR stage

In your agent-config.yml, set asr_provider: deepgram and pick a model. If you leave asr_provider unset, the cascade falls back to Deepgram anyway — so this step is really about choosing the model.
agent-config.yml
name: support-agent
pipeline_mode: cascaded

asr_provider: deepgram
asr_model: nova-2          # forwarded onto the ASR socket

llm_provider: openai
llm_model: gpt-4o-mini
tts_provider: elevenlabs
tts_voice: <voice-id>
language: en
2

Add your Deepgram key

Keys are per-tenant. Set DEEPGRAM_API_KEY in the TeleQuick console at agent.telequick.dev; it is sealed at rest and resolved from the control plane at call setup — never baked into the config document. For single-tenant or local development the runtime also reads it from the environment:
export DEEPGRAM_API_KEY=...
An agent whose ASR provider has no usable key is refused at session creation with a clean error rather than starting and failing mid-call. Confirm the key is present before you route live traffic.
3

Place a test call

Config is hydrated into the runtime from the control plane with no rebuild. Place a call and watch the latency breakdown to see ASR-final timing per turn.

​
What the runtime sends Deepgram

The TeleQuick Agent Runtime opens one streaming Deepgram session per call on the caller’s shard and forwards each 8 kHz PCM16 audio frame as it arrives off the media plane. It consumes Deepgram’s streaming results — interim hypotheses while the caller is still speaking, then a final transcript at the endpoint — and hands the final text to the LLM stage. Because the runtime owns endpointing (see below), it drives Deepgram in streaming mode rather than delegating turn-taking to the transcriber. The asr_model value is passed straight through to Deepgram, so any current Deepgram streaming model id works:

​
Barge-in

Barge-in works with a Deepgram cascade. Endpointing and interruption are handled by the runtime’s local, on-device VAD, not by the transcriber — so the caller can talk over the agent and the agent stops, independent of your ASR choice. The runtime uses hold-and-confirm barge-in: a short backchannel (“mhm”, “ok”) does not cancel the agent, but sustained speech past the confirm window does. Tune it in the turn-detection block:
agent-config.yml
turn_detection:
  type: local               # on-device VAD owns endpointing + barge-in
  silence_threshold_ms: 500
  min_speech_ms: 300
  barge_confirm_ms: 300     # sustain speech past this to interrupt the agent
  response_min_speech_ms: 600
Backchannel suppression is acoustic — it keys off utterance duration and the hold-and-confirm window, not the words spoken. Lexical gating (“stop” vs “ok”) is not built. See turn detection for the full knob set and barge-in debugging to inspect what fired on a live call.

​
Deepgram for text-to-speech

Deepgram also ships as a text-to-speech provider (the Aura voices). If you want Deepgram on both ends of the cascade, set the TTS stage too:
agent-config.yml
tts_provider: deepgram
tts_voice: aura-asteria-en
See BYO ASR / LLM / TTS for the full provider matrix across all three stages.

BYO ASR / LLM / TTS

Assemble the full cascade — every ASR, LLM, and TTS provider in one config file.

Turn detection

The endpointing and barge-in model that runs in front of Deepgram.

Runtime configuration

Every agent-config.yml field: providers, turn detection, budgets, codecs.

Latency breakdown

See per-stage ASR / LLM / TTS timing on a live call.