# Call transcripts

> How the agent runtime produces call transcripts, where the console exposes them, and how they differ from recordings, CDRs, and traces.

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:

| Surface              | Field that carries the call    | Where it lives                 |
| -------------------- | ------------------------------ | ------------------------------ |
| Transcript           | call SID                       | Stored per call by the runtime |
| Call Detail Record   | `call_sid`                     | ClickHouse `telephony_cdrs`    |
| Distributed trace    | `call.sid`                     | OTLP consumer (Tempo, SigNoz, Honeycomb, Datadog) |
| Recording            | `recording_url` on the CDR row | Empty if the call was not recorded |

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:

| Artefact           | Answers                                            | Read it from                      |
| ------------------ | -------------------------------------------------- | --------------------------------- |
| **Transcript**     | What was said, and by which side.                  | The console transcripts screen.   |
| **Recording**      | How it sounded — tone, overlap, audio defects.     | `recording_url` on the CDR.       |
| **CDR**            | Did the call connect, for how long, how clean was the media, why did it end. | ClickHouse `telephony_cdrs`. |
| **Trace**          | Where time went inside the gateway — RPC parse, JWT validation, trunk lookup, dialplan node execution, SIP/RTP setup. | Your OTLP backend. |
| **SIP capture**    | The raw SIP exchange, for calls that fail before any `CallEvent` is emitted. | Homer / heplify-server (HEPv3). |

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.

## Related

- [Telemetry](/platform/telemetry) — metrics, traces, CDR schema, SIP capture
- [Telephony Metrics](/glossary/metrics) — what the CDR's quality fields mean
- [Authentication](/concepts/authentication) — scoping access to control-plane reads