How it works

Tried has three moving parts: the API, the agent runtime and the media layer. This page explains how they fit together and walks through a call from the first ring to the last webhook. Knowing the lifecycle helps you decide where to put logic: in the prompt, in a function, in a pre-call workflow or in a webhook handler.

Components#

PSTN ─ Telnyx / Twilio / your trunk ─▶ LiveKit SIP ─▶ room "call_<call_id>" ◀── browser (web call)
                                                      │ agent dispatch
                                                      ▼
                         agent worker: STT ─▶ turn detector ─▶ LLM (stream) ─▶ TTS (stream)
                                                      │ events (transcript, tools, latency)
                                                      ▼
                         API: store call, webhooks, post-call analysis, billing

The configuration snapshot#

When a call starts, the worker fetches one frozen snapshot of everything it needs: the agent, its engine (Retell LLM, conversation flow or Custom LLM WebSocket URL), the resolved voice and fallback voices, knowledge base IDs and the merged dynamic variables. The worker never reads the database during the call.

This has two effects you should know about:

• Edits to an agent do not change calls that are already running. They apply to the next call.
• If the API is briefly unavailable mid-call, the call continues. The worker buffers its events and retries.

Which version of the agent goes into the snapshot depends on how the call was started. Phone numbers can pin a version or follow an environment tag such as prod. API calls can pass override_agent_version. See Versions and environments.

Inbound phone call#

Outbound phone call#

Web call#

POST /v3/create-web-call creates a room and returns an access_token and livekit_url. The browser joins the room with the browser SDK or livekit-client. The token is valid for one room for one hour; the response carries the expiry in expires_at. Transfers do not apply to web calls.

During the call#

The worker sends events to the API in batches: each utterance, function calls and results, flow node transitions, keypad digits, collected variables and per-turn latency. The API stores them on the call, which is how Live Monitoring and the transcript_updated webhook see the conversation as it happens.

You can change a running call with PATCH /update-live-call/:call_id: override dynamic variables, change metadata, or add context for the agent and ask it to respond. See Dynamic variables.

The call ends when the caller or agent hangs up, the agent transfers the call, End Call on Silence or Max Call Duration is reached, or a detection feature ends it. The reason is stored in disconnection_reason.

After the call#

When the call ends:

• The call status becomes ended and the call_ended webhook is sent.
• Post-call analysis runs with the agent's post_call_analysis_model and fills call_analysis. The call_analyzed webhook is always delivered after call_ended.
• The post-call workflow runs after analysis, if the agent has one.
• Contact memory is rewritten, if the agent has Update memory after each call on.
• Cost is computed per second and recorded on the call.
• The data storage setting is applied last, once webhooks and analysis have received the full call. With Everything except PII, PII is scrubbed from the stored transcript and the recording is beeped over the redacted words. With Basic attributes only, the transcript, variables and recordings are removed.

Where to put your logic#

Related#