Skip to main content
Session History is a per-call event log. Each session represents a single call from start to end. Within a session, you can see every event that occurred — transcription results, LLM calls, function executions, and TTS outputs — with timestamps, inputs, and outputs at each step. Use Session History to debug a specific call where the agent behaved incorrectly, trace why a function call failed, or verify that a post-call analysis field was correctly extracted. Access it at Monitor > Sessions.

​
What is a session

A session maps to a single phone call. It begins when the call connects and ends when the call terminates. Sessions are identified by a unique session ID in the format sess_.... Each session record includes:
  • Session ID (sess_...)
  • Agent that handled the call
  • Phone number (inbound or outbound)
  • Start time and duration
  • Call outcome (from post-call analysis, if configured)
  • Total cost for the session
  • Event timeline

​
Event types

Records a segment of caller speech converted to text. Contains:
  • Raw transcript text
  • Confidence score (word-level and utterance-level, if available)
  • Timestamp (when the utterance started and ended)
  • Transcription model used
Multiple transcription events occur per call — one for each caller turn.
Records a call to the language model. Contains:
  • Input messages (the full conversation context sent to the LLM)
  • LLM output (the raw text response before TTS processing)
  • Model used and token counts (prompt tokens, completion tokens)
  • Latency (time from request to response)
Use this event to determine whether unexpected agent behavior originated in the LLM response or in downstream processing (function execution, TTS).
Records the execution of a tool/function call by the agent. Contains:
  • Function name
  • Input arguments passed by the LLM
  • Response returned by the function
  • HTTP status and latency (for external API calls)
  • Error details if the function failed
If a function call returned an error or unexpected data, this is where to look.
Records a text-to-speech synthesis request. Contains:
  • Input text sent to the TTS provider
  • Provider (ElevenLabs, Cartesia)
  • Voice ID used
  • Latency (time to first byte of audio)
  • Cache hit indicator (whether audio was served from the Audio Cache)
For conversational flow agents, records which flow node was entered and exited. Contains:
  • Node ID and name
  • Entry timestamp
  • Exit condition (which branch was taken)
  • Variables set by the node
Use flow node events to trace why a caller ended up in the wrong branch.

​
Filtering and searching sessions

Search by phone number: enter the caller’s phone number to find all sessions from that number. Filter by agent: narrow to sessions handled by a specific agent. Filter by date range: set a start and end date. The default view shows the last 7 days. Filter by outcome: if post-call analysis is configured, filter by extracted outcome fields (e.g., show only calls where intent = booking). Filter by duration: find unusually long or short calls using minimum/maximum duration filters.

​
Debugging a specific call

1

Find the session

Search by phone number, session ID, or date range to locate the call. If you know the approximate time, use the date filter.
2

Open the event timeline

Click the session row to expand the full event timeline. Events are displayed chronologically.
3

Identify the failure point

Scan the timeline for the first event where behavior deviated from expected. Look for:
  • A transcription event with low confidence or wrong text (transcription error)
  • An LLM event where the output does not match expected behavior (prompt/LLM issue)
  • A function event with an error status or unexpected response (integration issue)
  • A flow node event that branched incorrectly (flow logic issue)
4

Inspect the inputs at the failure point

For LLM events, examine the full input context. Did the LLM receive the correct conversation history? Were variables correctly substituted? Was the system prompt intact?
5

Cross-reference with post-call analysis

If the session has a post-call analysis result, check whether the extracted fields match what actually happened. Mismatches here can indicate extraction prompt issues.

​
Transcription errors vs. LLM errors

Session History makes it possible to distinguish between these two error categories — important because the fix differs.
  • Transcription error: the LLM input event shows wrong or garbled text in the caller turn. The agent did not mishear — the transcriber produced incorrect text. Fix: adjust denoising, transcription model, or vocabulary hints.
  • LLM error: the transcription event shows the correct caller utterance, but the LLM output is wrong or off-topic. Fix: adjust the system prompt, add constraints, or review the conversation context being passed.