Quick answer
No, not automatically. A stored transcript is a reconstruction assembled by your pipeline, not a recording of the call, and eleven documented mechanisms make the two differ, ten of them with no recognition error involved at all. Every one was re-read at source on 20 September 2026. Run the Read Back Test below over your last 20 calls.
This page is about the plumbing, not the model. Accuracy benchmarks measure the recogniser, and ten of the eleven mechanisms below are not recognition errors at all: they sit in Pipecat, LiveKit Agents and @livekit/agents (the JavaScript port), in a recorder that resamples audio, in a telemetry upload path, and in an iOS SDK changelog at ElevenLabs. The eleventh is row 9, from the AssemblyAI changelog, and it is a defect in the output of a speech to text service rather than a mishearing: the audio held one filler word and the transcript carried two. Word error rate on Australian speech is a real and separate question, worked through in AI voice agent Australian accent accuracy.
What my transcript is, and what it is not
It is a record of what your pipeline decided had been said. That is not a pedantic distinction. On a framework stack the transcript is built from turn events, and turn events are emitted by an aggregator that reasons about text frames, not about air pressure. Nothing in that path listens to the speaker.
So the transcript can contain three kinds of line: a line the caller or agent actually said; a line that was generated, sent for synthesis, and never played; and a line that was played and then committed twice. It can also be missing a line that was definitely spoken. The single most useful sentence to hold on to is this: the artefact is not the event, and the ways it diverges from the event are enumerable.
Two of our own pages already own a corner of this, and both are ceded here. AI voice agent memory between calls has the consequence for memory design: persist decisions, not dialogue. Why voice agent evals pass but real calls fail has the consequence for evaluation: an evaluator reading an artefact your own aggregator assembled cannot find a fault in that aggregator. This page does what neither does, which is enumerate the divergences and hand you a procedure to count yours.
AI agent observability: traces, logs, outcomes calls transcripts your evidence of what was said. Read alongside the register below, that needs a condition: a transcript is evidence of what was said once you have tested it against the audio, and not before.
The divergence register: eleven documented ways the text and the call differ
Every row is a public, dated report on the vendor or maintainer property that owns it. State, close date and the release carrying any fix were read on 20 September 2026 from the issue page and the repository release notes. Closed is not fixed and closed is not retroactive: a change merged in September repairs nothing written in August. How to run a tracker audit like this yourself is set out in audit a voice platform for leaked keys and PII; the issues here are cited as evidence only.
| # | What diverges, and why | Record affected | Direction | State at source, read 20 September 2026 |
|---|---|---|---|---|
| 1 | When the synthesis provider returns no word timestamps, text is committed to the assistant context and transcript as it is sent for synthesis rather than when it is played, so an interrupted or truncated reply lands in full. The reporter states that on a provider which does return word timestamps the mechanism does not fire | Stored transcript, LLM context | Adds words never spoken | pipecat #5426, closed as completed 26 August 2026 with no closing pull request. The maintainer gave the root cause, “The default behavior when timestamps aren’t available is to push phrases to the context when generation is requested”, and closed it: “Closing this out since this works as designed for now. We’ll add word timestamp support as soon as it’s available.” |
| 2 | When a synthesis context completes with no audio, the unrendered remainder is force completed into an ordinary text frame with append_to_context still true, and the aggregator commits it |
Stored transcript, LLM context | Adds words never spoken | pipecat #5305, still open. On pipecat 1.8.1 the reporter found 7 of 56 sentences in a scripted 10 call batch produced no audio within the 3 second timeout, and all 7 sat in the context and the turn event transcript indistinguishable from spoken ones; 1.8.1 now raises a non-fatal error frame but leaves the text path unchanged |
| 3 | A line spoken with append_to_context=False (the documented way to speak a holding line) never reaches the assistant turn events the documented transcript pattern is built from |
Stored transcript | Drops words that were spoken | pipecat #5639, raised 5 September 2026, still open with pipecat at v1.11.0 (18 September 2026) |
| 4 | On session close the flush that waits for the trailing recognition result is started and then cancelled microseconds later, before its own timeout budget | Stored transcript | Drops the caller’s final utterance | livekit/agents #6889, closed 19 August 2026 by merged PR #6897, listed in the livekit-agents 1.7.0 notes (released 20 August 2026) |
| 5 | Cancelling one text output task can cancel the shared segment rotation, leaving the synchroniser attached to a closed segment; audio still flows, text does not | Stored transcript, all later turns | Drops assistant text persistently | livekit/agents #7299, closed 18 September 2026 by merged PR #7300. Not named in any published release note: the newest livekit-agents release is 1.8.2, 15 September 2026 |
| 6 | An interrupted reply is committed a second time at its full generated length, because the fallback returns the whole generated text when no synchronised transcript exists | Stored transcript, LLM context | Duplicates, and records unspoken words | livekit/agents-js #2457, closed as completed 10 September 2026. The issue names no closing pull request, so it does not identify the release that carries the change |
| 7 | The recorder holds back the resampler tail of each agent segment and flushes it only when the next segment re-anchors, by which time that place in the timeline is already written | Audio recording | Drops audio that was played | livekit/agents #7046, closed 1 September 2026 by merged PR #7047, listed in the livekit-agents 1.8.0 notes (5 September 2026) |
| 8 | A failed read of the local recording file during session report upload is caught and discarded, and the upload proceeds and returns 200 without the audio part | Audio attached to the session report | Drops audio from the uploaded report | livekit/agents #6832, closed 17 August 2026 by merged PR #6833, listed in the livekit-agents 1.7.0 notes. That fix supplies the missing warning only: the pull request states it “keeps the existing behavior (the report still uploads without audio rather than failing outright)”, so from 1.7.0 the loss is logged rather than prevented |
| 9 | Duplicated filler words on Universal-3.5 Pro transcripts generated with disfluencies: true, for example “Uh uh” where the audio contains a single “uh” |
Stored transcript | Adds words the audio does not contain | AssemblyAI changelog, 1 September 2026, which states the update “significantly reduces duplicated disfluencies on internal benchmarks”, “applies to new transcription requests going forward”, and that “Transcripts created before this fix keep their original text and are not retroactively corrected” |
| 10 | The language field is wrong: an unresolved code falls back to Hindi on one service, and another emits ISO 639-3 where its peers emit ISO 639-1 | Transcript metadata and telemetry spans | Mislabels the transcript | pipecat #5691, closed 10 September 2026 by merged PR #5692; pipecat #5396, still open |
| 11 | Streamed parts and corrections attach to the wrong message when responses are reconciled by event identifier rather than response identifier | Client side conversation record | Misattributes text between turns | ElevenLabs changelog, 14 September 2026, iOS SDK v3.3.1: the entry reads “Reconciles agent messages by response_id instead of event_id, preserving multiple responses around tool calls and preventing streamed parts or corrections from attaching to the wrong message” |
Read the directions, not the row count. Four rows (1, 2, 6 and 9) put text into the record that no one spoke, or duplicate text that someone did. Five rows (3, 4, 5, 7 and 8) drop something that was said or played. Two rows (10 and 11) mislabel or misattribute. A transcript can be wrong in both directions on the same call, and neither direction announces itself.
Two rows carry a production measurement from the person who filed them, which sets the scale. On pipecat #5426 the reporter examined 179 production calls over three days and found 18 that stored a final assistant line which could not physically have aired in full. On livekit/agents #7046 the reporter’s log records 16,858 dropped samples, 351 ms, over roughly two and a half minutes, with every agent turn cut 15 to 35 ms short at its end. Both are the filer’s numbers on the filer’s stack, not a base rate for yours. Getting your own is the next section.
The Read Back Test: what to do with my last 20 calls
Name it so it survives being repeated: the Read Back Test. You are not auditing the recogniser. You are asking whether the text you stored corresponds to air that moved.
- Take the last 20 completed calls in time order. Not a sample you choose, and not the 20 that generated a complaint. The mechanisms above fire on ordinary interruptions, so an ordinary week is the right sample.
- Pull three artefacts per call: the stored transcript, the agent channel audio and the caller channel audio. If your recording is a mono mix you cannot run steps 4 and 5 at all, and fixing the recording to dual channel is the whole first task.
- Check the audio before the text. Compare each recording’s duration against the call duration on the call record. A systematic shortfall is row 7; a missing file behind a successful upload is row 8.
- Classify every transcript line, and every stretch of speech with no line against it, into one of five buckets: matched; A, text present with no corresponding audio on that channel; B, audible speech with no text; C, the same line committed twice; D, text attributed to the wrong speaker or turn.
- Then look only at the last three seconds of each call. Does the transcript contain the caller’s final utterance? Does the final agent segment end mid word? Row 4 and row 7 both live in the tail, and a mid-conversation spot check will never see either.
- Count by bucket and divide by 20. That number is yours, it is publishable, and it is the only figure in this area that describes your deployment rather than someone else’s.
The threshold, so the test ends in a decision: one instance of bucket A across 20 calls fails the transcript. Not a rate, one instance, because rows 1, 2 and 6 are deterministic given the trigger, so one occurrence means the mechanism is live and every interrupted call is exposed. Buckets B and D confined to the tail are narrower: they indict the close path, not the whole record. Bucket C is the easiest to misread, because a caller who genuinely repeats themselves looks identical in the text and different in the audio.
Which artefact answers which question
Most arguments about transcripts are really arguments about which artefact was consulted. This is the substitution table.
| What I am trying to settle | Artefact that can settle it | What cannot settle it, and which row says so |
|---|---|---|
| Did the agent say this sentence out loud? | The agent channel of a dual channel recording | The stored transcript: rows 1, 2 and 6 put unspoken text into it |
| Did the caller say this sentence? | The caller channel audio | The transcript tail: row 4 drops the final utterance |
| Did the agent say anything after this point? | The agent channel audio | The transcript: row 5 drops assistant text for every later turn |
| What did the model believe had been said? | The LLM context or chat history, which is a separate artefact from the transcript | The transcript, and vice versa: rows 1, 2 and 6 corrupt both, differently |
| Which language was spoken? | The audio | The language field on the transcript: row 10 |
| Was audio captured at all? | File length and duration against the call record duration | A successful upload response: row 8 returns 200 with no audio part |
| Whether any of this meets a legal, contractual or record keeping obligation | Your own legal adviser, reading the applicable instrument | Nothing on this page, and no vendor dashboard |
Is my transcript a legal record?
That is not a question this page can answer, and it would be doing you harm to try. Whether an artefact is admissible, whether it discharges a record keeping obligation, and what a regulator would accept are legal questions that turn on the instrument that applies to you, your jurisdiction and facts nobody here can see. We build AI sales agents; we are not lawyers, and this is general information only.
What this page gives you instead is the technical input to that conversation: a dated list of the ways your artefact can differ from the call, and a count from your own last 20 calls that does not exist until you run it. Take the count to the adviser, not the assumption.
Two adjacent questions on this site stay in their own lanes and quote their instruments rather than paraphrasing them: Australian call recording laws for AI agents, state by state from the consolidated Acts, and is a phone number in a log personal information? for fields that leak out of the transcript into identifiers and span attributes. Neither answers admissibility either, because it is not answerable in general.
What a transcript you can defend costs to keep
All of the above is available to you today and none of it requires a vendor. The costs are real and worth stating plainly before you decide how far to go.
Dual channel recording roughly doubles stored audio against a mono mix, and it is the precondition for the test, so it is not optional if you want the answer. The diff is manual the first time: 20 calls at a few minutes each is an afternoon, and what it produces is the bucket classification, not a better transcript. Automating it means an alignment step, which is real engineering because the thing you align is the thing you do not trust. Pinning framework versions is the cheapest control here, since most rows above are version dependent and a routine upgrade moves you across one in either direction. And every artefact you keep longer inherits a retention and access decision.
The honest threshold: below roughly 200 calls a week with no disputed calls in your history, run the Read Back Test once per release and keep the audio. Above that, or the first time a call is disputed, the alignment step stops being optional and somebody owns it.
Where the artefacts are produced matters as much as how they are stored. Zian AI runs live phone, SMS, email and WhatsApp agents in 30+ languages and supports private model deployment on customer infrastructure, which is the configuration in which the recorder you diff and the agent you shipped sit inside the same boundary you control. Our AI sales agent solutions describe that deployment shape. Whichever way you build it, ask the question this page asks: what produced the text, and did anything listen?
Where every figure on this page comes from
| Figure or quotation | Who published it | Link (their own page) | Date read |
|---|---|---|---|
| Text committed at synthesis request rather than playback; closed as working as designed; 179 calls, 18 with an unaired final line | pipecat-ai / Pipecat maintainers and issue reporter | github.com/pipecat-ai/pipecat/issues/5426 | 20 September 2026 |
| Unrendered remainder force completed into the context; 7 of 56 sentences on pipecat 1.8.1 | pipecat-ai / issue reporter | github.com/pipecat-ai/pipecat/issues/5305 | 20 September 2026 |
| Lines with append_to_context=False never reach the assistant turn events; open at v1.11.0 | pipecat-ai | github.com/pipecat-ai/pipecat/issues/5639 | 20 September 2026 |
| Trailing recognition flush cancelled at session close; closed 19 August 2026 | LiveKit | github.com/livekit/agents/issues/6889 | 20 September 2026 |
| Cancelled barrier waiter drops later transcripts; closed 18 September 2026 by merged PR 7300 | LiveKit | github.com/livekit/agents/issues/7299 | 20 September 2026 |
| Interrupted reply committed twice at full generated length; closed 10 September 2026 | LiveKit | github.com/livekit/agents-js/issues/2457 | 20 September 2026 |
| Resampler tail dropped from every agent segment; 16,858 samples and 351 ms in the reporter’s log | LiveKit / issue reporter | github.com/livekit/agents/issues/7046 | 20 September 2026 |
| Failed recording read discarded during session report upload, upload returns 200 | LiveKit | github.com/livekit/agents/issues/6832 | 20 September 2026 |
| Hindi fallback on an unresolved language code; ISO 639-3 emitted where peers emit ISO 639-1 | pipecat-ai | issues/5691 and issues/5396 | 20 September 2026 |
| Release versions and dates: livekit-agents 1.7.0, 1.8.0, 1.8.2 | LiveKit | github.com/livekit/agents/releases | 20 September 2026 |
| Release version and date: pipecat v1.11.0, 18 September 2026 | pipecat-ai | github.com/pipecat-ai/pipecat/releases | 20 September 2026 |
| Duplicated filler words on Universal-3.5 Pro, and “not retroactively corrected” | AssemblyAI | assemblyai.com/changelog | 20 September 2026 |
| Streamed parts or corrections attaching to the wrong message, iOS SDK v3.3.1 | ElevenLabs | elevenlabs.io/docs/changelog/2026/9/14 | 20 September 2026 |
Frequently asked questions
Is my AI call transcript a record of what was said?
It is a record of what your pipeline decided had been said. Eleven publicly documented mechanisms, all read again at source on 20 September 2026, make the stored text differ from the audio, ten of them with no recognition error involved at all. Until you have compared your own transcripts against your own dual channel audio, the transcript is a reconstruction of the session rather than a recording of the call.
Can a transcript contain words nobody spoke?
Yes, and by design in at least one case. On Pipecat, text can be committed to the transcript and the model context when it is sent for synthesis rather than when it is played, so an interrupted or truncated reply lands in the record in full. Issue 5426 was closed as working as designed on 26 August 2026 pending word timestamp support from the synthesis provider.
Can my transcript be missing words that were definitely spoken?
Yes, in at least three ways. A holding line spoken without appending to context may never reach the events transcripts are built from (Pipecat issue 5639, still open). A flush at session close can be cancelled before the final caller utterance commits (LiveKit Agents issue 6889). And a cancelled text output task can drop assistant text for every later turn (LiveKit Agents issue 7299).
Does a closed bug report mean my old transcripts were repaired?
No. A fix repairs new records, not old ones, and vendors say so themselves. AssemblyAI records in its own changelog entry dated 1 September 2026, about duplicated filler words, that transcripts created before the fix keep their original text and are not retroactively corrected, and that the remedy is to resubmit the original audio: see the AssemblyAI changelog, read 20 September 2026.
Which artefact should I keep if a call is disputed?
Keep the dual channel audio and the transcript, and keep them separately, because they answer different questions. The audio is the only artefact that can show whether a sentence was played; the transcript cannot, because several mechanisms write unplayed text into it. Whether either artefact satisfies an obligation you are under is a legal question for your own adviser and the instrument that applies to you.
Will a better speech recognition model fix this?
Not for ten of the eleven. Those sit outside the recogniser entirely: in the aggregator that assembles turns, in the close path, in the recorder that resamples audio, in a telemetry upload, in a client SDK, or in a metadata field. A perfect recogniser changes none of them. The eleventh, row 9, is a defect in the output of a speech to text service, and the vendor fixed it for new requests only. Recogniser accuracy is a genuine and separate problem, and it is measured differently.