Most agents do not need this page. If you can remove the LiveKit server,
install the transport plugin —
livekit-plugins-clutchcall / @clutchcall/livekit-transport —
into your agent process instead. Then you do not need the sidecar, the room, or
the credentials setup below. This is the recommended path:
Run a LiveKit Agent on ClutchCall Transport.Use the front-proxy on this page when the room itself must stay — for
example, other participants join it, or another part of your stack depends on it.1. Configure a vendor-bridge agent
Give the agent a singleVENDOR_BRIDGE entry node instead of an ASR→LLM→TTS
cascade. With this configuration, the runtime runs no turn detection and
no model. It sends the caller’s audio to your LiveKit room. It streams the
room’s audio back.
agent-config.json
string
default:"livekit"
The external vendor to route to. The sidecar implements
livekit and
vapi today (Twilio Media Streams is the same PCM-over-WebSocket proxy shape
and is a natural follow-on). Setting it to clutchcall instead means
the opposite arrangement — your own agent process on our transport, no
sidecar and no room. See
LiveKit Agent over ClutchCall Transport.string
The LiveKit room that the bridge sidecar joins. For the other vendors, this is
the Vapi assistant id or the Twilio app.
string
The key into your tenant’s sealed vendor credentials: your
LIVEKIT_URL,
LIVEKIT_API_KEY, and LIVEKIT_API_SECRET. The system stores these values at
rest and never inlines them.2. Place a call at that agent
Attach the agent onoriginate. The gateway connects the audio automatically on
answer. You do not need your own AudioBridge.
- TypeScript
- Python
3. Promote a live call to the LiveKit agent
If a call is already in progress, attach the vendor-bridge agent to the runningsid. This moves the conversation to your LiveKit room in the middle of the call.
- TypeScript
- Python
4. Run the bridge sidecar
The gateway side of the bridge — the vendor-bridge node plus the media handler — is part of the runtime. The process that joins your LiveKit room is a small Go sidecar (clutchcall-livekit-bridge) that you run next to your
LiveKit deployment, because it holds your LiveKit credentials.
It is a WebSocket server, not a client of yours. The engine connects to it:
/bridge and sends a JSON
handshake as the first text message; every message after that is one audio
frame, in either direction. The sidecar is codec-agnostic — the engine sends the
vendor-appropriate codec (Opus for LiveKit, PCM16 for Vapi) and converts on the
return, so the sidecar only forwards bytes.
handshake
vendor_creds_ref — they are stored at rest and
never inlined into an agent config.
For "vendor": "vapi" the same handshake carries assistant_id, and api_key
is reused as the Vapi private key; the sidecar POSTs /call, gets the call
WebSocket, and proxies PCM both ways.
What is shipped and what you deploy. The vendor-bridge routing is part of
the runtime. The sidecar is a separate binary you operate, because it is the
only component that needs your LiveKit URL, key, and secret.
Browser leg? The compat shim (preview)
If your LiveKit surface is a browser app (livekit-client) and not a
server-side agent, you can skip the edge bridge. Change one import line to run
the client’s audio directly over the transport.
Related
LiveKit Agent Integration
All three paths: transport plugin, front-proxy, and browser shim.
Run a LiveKit Agent on the Transport
The recommended path: a plugin in your agent process, with no sidecar and no room.
From Self-Hosted LiveKit
The wave-by-wave migration off a LiveKit SFU.
Custom Agent Runtime
The same front-proxy pattern for any non-LiveKit runtime.
WebRTC Diversion
How the compat shim sends encoded Opus over QUIC in the browser.

