A transcript is the spoken record of a call — what was said, turn by turn. It sits alongside the other per-call artefacts that TeleQuick keeps (the CDR row, the recording, the trace), but it is the only one that carries call content rather than call metadata.

​
Where a transcript comes from

Transcripts are captured by the agent runtime while the call is live. They are not reconstructed after the fact from a recording, which has two consequences:
  • A call has a transcript when the agent runtime was in the call path. On the CDR side these are the calls with agent_id set — the field the gateway populates when a call routes through an AI agent DAG.
  • A transcript can exist for a call that was never recorded. recording_url on the CDR is independent of transcript capture and is empty when the call was not recorded.
Each transcript is stored per call, so the call SID is the unit of storage and the unit you read back.

​
Finding transcripts in the console

The console exposes transcripts at agent/transcripts, in the admin navigation under Transcripts (“What was said on each call — captured from the agent runtime and stored per call”). The screen lists the captured calls and lets you open one call’s record. The table body — its columns, its filters, and the order it sorts in — is rendered by shared console UI and can change between releases without a change to this page. Treat the screen itself as the source of truth for what is filterable today; this page only describes where the data comes from and how it relates to the rest of the per-call record.

​
Correlating a transcript with a call

The call SID is the join key across every observability surface, so a transcript can always be lined up with the operational data for the same call: To go from a transcript to the call’s quality numbers, read the CDR row for the same call_sid: duration_seconds, q850_cause, status, packets_lost, jitter_ms, and estimated_mos are all on that row. To go from a transcript to the agent that produced it, use agent_id.

​
Transcripts, recordings, and traces

These four artefacts answer different questions about the same call. Reach for the right one: A common debugging order for an agent call that went wrong: read the transcript to find the turn where the conversation broke, read the CDR for that call SID to see whether media quality explains it, then open the trace if the fault looks like it was on the gateway side.

​
Storage and retention

Transcripts are stored per call by the agent runtime, and the console screen is the read surface for them. This page does not state a retention window, because the retention applied to transcripts is a property of your deployment rather than of the screen. Confirm what your deployment keeps before you treat transcripts as a system of record. The durable per-call record is the CDR: the telephony_cdrs table is partitioned by month and indexed on (tenant_id, timestamp_ms). Transcripts contain call content. Handle them with the same care as recordings, and scope access to them the same way.