> For the complete documentation index, see [llms.txt](https://docs.amigo.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.amigo.ai/intelligence-and-analytics/intelligence/call-intelligence.md).

# Call Intelligence

Call intelligence combines several kinds of evidence produced during and after an eligible voice call. These outputs are related, but they are not one universal score: the terminal operational summary measures runtime behavior, post-call analysis evaluates the recorded interaction, and the Voice Judge evaluates audio quality. Availability depends on the voice runtime, configuration, recording, and downstream processing.

<figure><img src="/files/BNp6hKpCVOaC8CtKzz2c" alt="Call intelligence pipeline: terminal operational evidence, optional recording-based analysis, decision traces, and playback timelines"><figcaption></figcaption></figure>

## Evidence Paths

```mermaid
flowchart LR
    C[Voice Call] --> T[Terminal Operational Summary]
    T --> Q[Operational Quality Score 0-100]
    C --> R[Call Recording]
    R --> P[Optional Post-Call Analysis]
    R --> V[Voice Judge for Eligible Calls]
    C --> D[Decision Trace + Playback Timeline]
    Q --> A[Call Review + Analytics]
    P --> A
    V --> A
    D --> A
```

### Terminal Operational Summary

At call completion, the primary voice runtime derives a terminal artifact from the session state it has observed. Depending on the available signals, that artifact can include:

| Evidence                 | What It Captures                                                                                                            |
| ------------------------ | --------------------------------------------------------------------------------------------------------------------------- |
| **Emotion**              | Aggregated emotional state and compound-emotion observations when emotion processing was available                          |
| **Latency**              | Engine and audio time-to-first-byte averages and percentiles, navigation and rendering latency, and estimated silence ratio |
| **Conversation shape**   | Turn count, duration, completion reason, final state, state revisits, and barge-ins                                         |
| **Tool performance**     | Tool-call totals, failures, failure rate, and per-tool timing                                                               |
| **Operator involvement** | Whether the call escalated and whether an operator was active                                                               |

The persisted wire shape still contains `risk_summary` and `safety_summary` for compatibility, but the current runtime leaves both empty. Authored agent policy and operator workflows govern safety and escalation; consumers must not infer a live risk scorer or safety-rule engine from those fields.

Some external voice runtimes do not provide the per-turn inputs needed for this summary. They emit a minimal completion envelope with list and lifecycle fields, while leaving analytical summaries empty and the quality score unset.

### Optional Post-Call Analysis

When post-call analysis is enabled and a recording is available, a background analysis evaluates five dimensions on a 1-5 scale:

| Dimension                | What It Measures                                        |
| ------------------------ | ------------------------------------------------------- |
| **Task completion**      | Whether the caller achieved the purpose of the call     |
| **Information accuracy** | Whether details were captured and understood correctly  |
| **Conversation flow**    | Pacing, repetition, overlap, and confusion              |
| **Error recovery**       | How the agent recovered from misunderstandings          |
| **Caller experience**    | The caller's apparent experience by the end of the call |

The result can also include an overall score, an outcome of `succeeded`, `partially`, `failed`, or `abandoned`, observed issues, and suggested speech-recognition keyterms. These suggestions are review evidence; they do not automatically rewrite voice configuration. Analysis is asynchronous and best-effort, so a completed call can exist without a result.

### Voice Judge Overview

The Voice Judge is a separate scheduled pipeline for eligible recorded production calls. It evaluates audio-native characteristics that structured runtime data cannot establish. See [Voice Judge](#voice-judge) for its rubric and eligibility boundaries.

## Operational Quality Score

Full terminal operational summaries receive a 0-100 quality score. The deterministic calculation starts at 100 and applies penalties for:

* High p95 audio time to first byte
* Excessive estimated silence
* Repeated caller barge-ins
* Revisited conversation states
* Operator escalation
* Tool-call failures

This score measures observable runtime friction. It is not a task-success score, clinical-risk score, or safety judgment. Post-call rubric scores and Voice Judge scores remain separate.

Analytics group operational scores into four ranges:

| Range      | Label     |
| ---------- | --------- |
| **90-100** | Excellent |
| **70-89**  | Good      |
| **50-69**  | Fair      |
| **0-49**   | Poor      |

Use individual scores to inspect a call and distributions to compare services or time periods. A missing score means the runtime did not produce sufficient operational evidence; it should not be treated as zero. See [Call and Eval Analytics](/intelligence-and-analytics/intelligence/analytics-dashboards.md#call-and-eval-analytics) for aggregate views.

## Summary Flags and Transcript Verification

Call detail can derive review flags from aggregate evidence such as latency, silence, barge-ins, loops, tool failures, and operator escalation. These flags explain why the operational score changed, but they are not guaranteed to identify the exact timestamp of an incident. Use the playback timeline or call trace analysis for time-oriented review.

When post-call transcript verification is enabled, the platform runs a higher-accuracy transcription pass and stores the verified transcript, word timings, and accuracy measurements when processing succeeds. Post-call quality analysis can separately suggest recognition keyterms. Neither path silently changes a service's configured keyterms.

## Production and Simulation Evidence

Production voice calls and simulation sessions preserve different evidence boundaries:

* **Production voice calls** can produce terminal operational summaries, recordings, post-call analysis, playback timelines, trace analysis, and Voice Judge results when their prerequisites are met.
* **Simulation sessions** emit source-tagged, run-linked terminal artifacts built from simulated turns, tools, terminal state, and simulation score. The metric pipeline keeps simulation and production scopes separate.
* **Audio-native analysis** does not apply to simulations without recordings. A simulation score is simulation-specific evidence, not a production operational quality score.

This separation lets teams compare like with like without allowing synthetic sessions to blend into production call analytics.

## Decision Trace

For supported voice calls, the runtime emits terminal per-turn decision events after the call. Each event can include:

* The signal classification that triggered the turn
* The effect classification describing what the agent did
* Current and transitioned states
* Tool names and success state
* Emotion observations and latency measurements when available
* Counts of configured inner-thought annotations, rather than hidden model reasoning

Decision-trace events support structural analysis such as turns per call, tool invocation rate, and state transition rate. They describe recorded actions and evidence; they do not reconstruct an unobserved chain of thought.

## Debug Traces

Administrators and owners can use two sensitive debugging views for a completed voice call:

* **Execution trace** - Persisted per-turn inputs and outputs, including transcripts, actions, tools, state transitions, emotion observations, configured inner-thought annotations, and latency fields.
* **Prompt trace** - Best-effort prompt-log records for turns whose prompt evidence was durably emitted.

Prompt evidence may be unavailable even when the execution trace exists. Access is restricted because these views can contain model internals and protected data.

## Call Trace Analysis

For an eligible completed call with accessible audio, asynchronous trace analysis can produce:

* A narrative summary and outcome
* Key decision moments with audio-grounded factors
* An emotional arc and critical emotional shifts
* Interaction dynamics and signal-response alignment
* Coaching recommendations and missed opportunities
* Counterfactual alternatives and predicted impact
* A synthesized explanation of why the call unfolded as it did

The API distinguishes `ready`, `pending`, and `unavailable`. A read can trigger best-effort on-demand processing for a qualifying production call, but a result is not guaranteed. Simulation sessions are not eligible for the recording-based trigger.

## Call Playback Timeline

The call detail response can include a canonical timeline that places speech and runtime events on one shared coordinate system.

<figure><img src="/files/aNYdJUo5DlaXO5ZusB0k" alt="Call playback timeline with caller, agent, operator, tool, and system tracks on a shared timebase"><figcaption></figcaption></figure>

### Lanes and Actors

Lanes are derived from the segments present in a call. Each lane has a stable ID, display order, semantic track, and actor when applicable. Supported tracks are caller, agent, operator, tool, and system. Tool and system events can receive distinct lanes based on their actor identity.

Operator speech uses the `caller_speech` segment type with operator actor metadata and the operator track. Consumers should use the actor and track fields rather than infer the speaker from the segment type alone.

### Segment Types

The current timeline vocabulary is:

| Category               | Segment Types                                                     |
| ---------------------- | ----------------------------------------------------------------- |
| **Speech**             | `caller_speech`, `agent_speech`, `greeting`, `interrupted_speech` |
| **Fillers and checks** | `filler_nav`, `filler_hesitation`, `silence_check`                |
| **Interaction**        | `barge_in`                                                        |
| **Execution**          | `processing_gap`, `tool_call`, `state_transition`                 |
| **Inactivity**         | `silence`                                                         |

### Shared Timebase

Segment start and end values are seconds on the response's shared timebase. Where exact audio offsets exist, the timeline aligns segments to the media. Where a legacy producer lacks exact offsets, the platform supplies synthetic positions so the call-detail UI still receives one consistent lane and seek model. Consumers can therefore render the response as provided instead of rebuilding timing independently.

See [Audio Pipeline](/channels/voice/audio-pipeline.md) for the voice timing settings that influence the underlying events.

## Voice Judge

The Voice Judge scores eligible recorded production calls across ten audio-native dimensions. It reads the caller channel and, when available, the agent channel; an inbound-only recording can be evaluated as mono.

### Ten Evaluation Dimensions

| Dimension                 | What It Measures                                        |
| ------------------------- | ------------------------------------------------------- |
| **Latency and Dead Air**  | Response timing and silence management                  |
| **Pronunciation**         | Speech clarity and correctness, including medical terms |
| **Clarity**               | Intelligibility of speech                               |
| **Filler and Silence**    | Tool-call acknowledgments and dead-air handling         |
| **Interruption Handling** | Barge-in detection and recovery                         |
| **Audio Consistency**     | Volume and pitch stability without cutoffs              |
| **Pacing**                | Conversational tempo and pauses                         |
| **Warmth and Tone**       | Tonal appropriateness to the caller's state             |
| **Accent Quality**        | Language match and accent naturalness                   |
| **Voice Identity**        | Consistency of the agent voice                          |

Each dimension can produce a score from 0.0 to 1.0, a severity of `none`, `warning`, `flag`, or `critical`, and audio-grounded evidence for non-`none` findings.

### Eligibility and Delivery

The scheduled job considers completed production calls within its lookback window, skips calls with a known duration of five seconds or less, excludes calls that already have a result, and requires an accessible inbound recording. Missing recordings, processing errors, and warehouse latency can leave an otherwise completed call without a Voice Judge row.

Results are available through two paths:

* **Recent per-service results** - Per-call scores and the bounded evidence payload for investigation
* **Aggregate metrics** - Ten built-in [Metric Store](/intelligence-and-analytics/metric-store.md) metrics for workspace-level trends

{% hint style="info" %}
**Developer Guide** - See [Call Trace Analysis](https://docs.amigo.ai/developer-guide/platform-api/safety/call-trace-analysis) and [Voice Judge](https://docs.amigo.ai/developer-guide/platform-api/safety/voice-judge) for endpoint contracts.
{% endhint %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.amigo.ai/intelligence-and-analytics/intelligence/call-intelligence.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
