Skip to main content
After a call ends, an LLM judge reads the transcript and evaluates it against the assistant’s analysis configuration. It can rate the caller’s sentiment, decide whether the call met a success criterion, and pull out structured fields (a callback number, an order ID, a yes/no answer). The result is stored on the call and is available in the history filters, the public API, and MCP.

​
What it produces

For each analyzed call the judge writes a result with:
  • Sentiment — positive, neutral, or negative (overall caller sentiment).
  • Success — true / false (or null when success evaluation is off), plus a short reason explaining the verdict.
  • Data — a map of the structured fields you defined, keyed by field name.
  • Model and analyzed_at — which judge model ran, and when.
Sentiment and success are also stored as denormalized columns on the call so you can filter large call lists quickly (in the history view and via GET /calls?sentiment=&success=).
Analysis runs after the call and never affects the live conversation. If the judge fails or returns unusable output, the call is untouched — a analysis_failed call event is recorded and nothing is written to the call’s analysis.

​
Configuring an assistant

Open the assistant’s Analysis card and turn on the parts you need. Everything is optional; an empty configuration means no analysis runs.
1

Sentiment

Enabled by default. Turn it off if you don’t need per-call sentiment.
2

Success criterion

Enable Success and describe, in plain language, what a successful call looks like — e.g. “The caller booked an appointment” or “The caller confirmed their delivery address.” The judge returns a boolean plus a reason.
3

Structured fields

Add fields to extract. Each field has a name (snake_case, unique), a type (string, number, boolean, or enum), a description telling the judge what to pull (max. 500 characters), an optional required flag, and — for enum — a list of choices.

​
Example configuration

A resulting calls.analysis looks like:

​
Using the results

  • History filters — filter the call list by sentiment and success to find, say, all negative calls that did not succeed.
  • Public API — every call in GET /calls and GET /calls/{id} carries analysis, sentiment, and success. Filter the list with ?sentiment=negative and ?success=false.
  • MCP — the same call fields are exposed through the MCP list_calls / get_call tools.

​
Configuring via the API

analysis_config is a writable assistant field, so you can manage it programmatically:
See the API reference (PATCH /assistants/{id} and the AnalysisConfig schema) for the full field contract.