> ## Documentation Index
> Fetch the complete documentation index at: https://docs.usetuner.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Tuner Features
> Every feature in Tuner, what it does, when it is useful, and how the pieces fit together.
Tuner covers the full life of a voice agent: connect it, test it before launch, watch it in production, find out why a call went wrong, and fix it. This page lists every feature so you can find the one you need, and see how it relates to the rest.
The short version of how it fits together: **you connect an agent once**, define what a good call looks like, and that single definition is used in two places. It scores your live traffic, and it scores the test calls Tuner places against your agent. There is no second configuration for testing.
The Quickstart connects an agent and gets a scored call in about five minutes.
The glossary defines every term used across the product.
***
## 1. Connecting your agent
The only job of an integration is to **get the finished call to Tuner**. Once Tuner has it, everything on this page happens on Tuner's side: transcript, per-turn timing, classification, evals, red flags, and alerts. Which route you take depends only on what you build on, and every route produces the same result once the call lands.
| Feature | What it does | When you want it |
| ----------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------- |
| [**Retell integration**](/docs/integrations/retell) | Paste your Retell API key, pick an agent, done. Tuner configures the webhook side for you. | You run on Retell and want no code at all. |
| [**Vapi integration**](/docs/integrations/vapi) | Same one-key setup using your Vapi private key. | You run on Vapi. |
| [**Vapi transient assistants**](/docs/integrations/vapi-transient-assistants) | Handles Vapi assistants defined per call rather than stored in the dashboard, including exact interruption data from the call log. | Your assistant config is generated at call time. |
| [**Dograh node**](/docs/integrations/dograh) | A Tuner node you drop into your Dograh workflow. | You build in Dograh. |
| [**LiveKit SDK**](/docs/integrations/livekit) | Python and Node plugins for LiveKit Agents that capture turns, per-stage latency, tool calls, usage, and cost. | You run LiveKit Agents, self-hosted or on LiveKit Cloud. |
| [**Pipecat SDK**](/docs/integrations/pipecat) | An observer you attach to your Pipecat pipeline, capturing the same detail. | You run Pipecat. |
| [**Custom stack**](/docs/integrations/custom-stack/overview) | Two ways to send a call from anything else. The [custom SDK](/docs/integrations/custom-stack/sdk-quickstart) attaches Python observers to your own [speech-to-text](/docs/integrations/custom-stack/speech-to-text), [text-to-speech](/docs/integrations/custom-stack/text-to-speech), LLM, or [LangChain](/docs/integrations/custom-stack/langchain) components and sends everything in one `flush()` at call end. The [Custom API](/docs/integrations/custom-stack/direct-api) takes a call payload you build yourself, from any language. | You are on any other platform, for example Plivo, Bland, or Twilio, or on a stack you built yourself. |
| [**Webhooks**](/docs/integrations/webhooks) | Tuner sends events out: `call.analyzed`, `alert.fired`, and for Vapi and Retell the original provider payload forwarded on. | You want Tuner events in Slack, PagerDuty, n8n, or your own service. |
| [**Templates**](/docs/getting-started/quickstart#step-2-pick-a-template) | Starting configurations (support, appointment booking, medical receptionist, food ordering, real estate, payment reminders, lead qualification, and more) that pre-fill outcomes, intents, evals, red flags, alerts, and extraction fields. | You want eval results on your very first call instead of an unscored transcript. |
**Worth knowing:** for monitoring, traffic goes one way, from your stack to Tuner over HTTPS. Tuner needs no route into your network, so a fully self-hosted agent connects the same way a managed one does.
***
## 2. Seeing what happened on a call
| Feature | What it does | When you want it |
| ------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- |
| [**Overview dashboard**](/docs/observability/overview) | Headline metrics, intent and outcome breakdowns, and the recent red flag queue over the period you pick. | Your daily pulse check. Is this broadly healthy, or degraded across the board? |
| **Call logs and transcript** | Every call with its turn-by-turn transcript, tool calls inline, outcome, intent, tags, sentiment, ended reason, duration, and cost. | You need to read exactly what was said and what the agent did about it. |
| [**Voice metrics and latency**](/docs/observability/voice-metrics) | Per-turn latency split by pipeline stage: end of utterance, STT, LLM, TTS, and time to first byte. Plus conversation shape metrics like longest agent monologue. | The agent feels slow and you need to know which stage is responsible instead of guessing. |
| [**Root cause analysis**](/docs/observability/root-cause-analysis) | A structured way to work a single failing call from symptom to cause using the Call Details view. | One call went wrong and you need to understand why before changing anything. |
| [**OpenTelemetry traces**](/docs/observability/traces) | Send OTel spans from LiveKit Agents or Pipecat and read them as a span tree attached to the matching call. | You already run OTel and want your spans next to the transcript rather than in a separate tool. |
**Worth knowing:** the depth of the latency breakdown depends on how you connected. Platforms that hand over a finished transcript can only tell you a call was slow. The SDKs record each stage as it happens, which is what turns "slow" into "the LLM stage added 900ms on turn four".
***
## 3. Judging every call
This is where you tell Tuner what a good call looks like. Everything defined here runs on production calls and simulated calls alike.
| Feature | What it does | When you want it |
| --------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------ |
| [**Call outcomes and intents**](/docs/evaluation/call-classification) | Classify each call by what the caller wanted and how it ended, with your own definitions of success and failure. | You want to answer "how often do we actually book the appointment", not just "how many calls came in". |
| **Data extraction** | Pull structured fields out of the conversation, for example the appointment date or the quoted price, and file them against the call. | You need call content as data you can filter and report on. |
| [**Predefined evals**](/docs/evaluation/predefined-evals) | 21 ready-to-use evals across Accuracy, Actions & Tools, Conversation Quality, and Safety & Compliance, each backed by a judge tuned on real voice deployments. One click to enable. | You want coverage of the common failure modes without writing anything. |
| [**Custom evals**](/docs/evaluation/custom-evals) | Write your own criteria in plain language, scored Pass/Fail or 1 to 5, and choose what evidence the judge can see under **Inputs Used**: system prompt, tools, allowed capabilities, workflow, or per-call metadata. | You have a rule specific to your business, like a disclaimer that must be read verbatim. |
| [**Evals for dynamic agents**](/docs/evaluation/dynamic-agents) | Score agents whose instructions change per call by passing those instructions as metadata and evaluating against them. | Multi-tenant agents, or personas that vary per session. |
| [**Red flags and labels**](/docs/evaluation/red-flags) | The Rule Builder combines eval results, voice metrics, and classification into composite conditions. Red flags mark a call as a problem, labels categorize without judging. | A single eval failure is noise, but three together is a call someone should look at. |
| [**Real-time alerts**](/docs/observability/alerts) | Notification when a condition you defined is met, delivered by email or to your webhook. | You would rather hear about the problem than go looking for it. |
**Worth knowing:** an eval judge is not limited to the words in the transcript. Because it can read the tool calls and results, and the agent's own instructions, an eval can fact-check the agent instead of only rating its tone. "The agent quoted a delivery time the tool never returned" is a checkable failure, not an opinion. See [What an eval actually judges](/docs/evaluation/overview#what-an-eval-actually-judges).
Evals also run in whatever language the call happened in, so a multilingual agent needs one set of evals rather than one per language.
***
## 4. Testing before your customers do
[Call Simulation](/docs/simulation/overview) places real voice calls against your agent and scores them with the evals you already configured. It is included from the **Builder** plan upward. Simulation is temporarily unavailable for [Dograh](/docs/integrations/dograh) agents, which can still capture and analyze real calls.
| Feature | What it does | When you want it |
| -------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------- |
| [**Inbound simulation**](/docs/simulation/inbound/setup) | Tuner dials into your agent over SIP, like a customer calling in. Guides for [Vapi](/docs/simulation/inbound/vapi), [Retell](/docs/simulation/inbound/retell), and [any SIP-capable provider](/docs/simulation/inbound/other-platforms) including Twilio, Telnyx, and LiveKit Cloud SIP. | Your agent receives calls. |
| [**Outbound simulation**](/docs/simulation/outbound) | Tuner triggers your endpoint with a SIP URI, and your agent dials Tuner's simulated caller. Guides for LiveKit, Pipecat, and Custom API. | Your agent places calls. |
| **Routine Callers** | Cooperative, on-topic callers generated from your configured intents and outcomes. | Checking the happy path still works after a change. |
| **Pressure Tests** | Difficult callers auto-generated from your evals: hallucination bait, scope boundary pushing, escalation demands, offensive language, personal data requests. | Finding the breaking point before a real customer does. |
| **Intent and eval targeting** | Narrow a run to specific intents or specific failure modes instead of testing everything. | You changed one workflow and want to test that one workflow. |
| [**Test profiles**](/docs/simulation/test-profiles) | Give the simulated caller an identity and context before the call: name, account details, urgency, whatever your agent needs. Snapshotted at run time so past results stay valid. | Your agent behaves differently for a new user than a returning one. |
| **Languages and accents** | Run simulations in Arabic, English, French, German, Italian, or Spanish, with AU, UK, or US accents for English. | Testing a multilingual agent, or how yours handles an accent it was not tuned on. |
| **Max call duration** | Caps how long any single simulated call can run. | Keeping a stuck agent from looping, and keeping batch cost predictable. |
| **Batch runs** | 5 to 20 calls per run, each one a fresh variation rather than a repeat of the same scenario. | The same request phrased ten ways produces ten different conversations. Volume is what covers them. |
***
## 5. Configuring, diagnosing, and automating
| Feature | What it does | When you want it |
| ------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------- |
| [**MCP server**](/docs/mcp/setup) | Connects your Tuner workspace to Claude, Cursor, Claude Code, Antigravity, or ChatGPT, with read and write access. Describe the agent you want and it creates the outcomes, intents, evals, red flags, and alerts. Currently in beta. | You would rather describe a configuration than fill in forms. |
| [**Diagnose your agent**](/docs/mcp/diagnose) | Reads your real call data, finds what is failing and why, then writes the fix back: updated prompt, new evals, extra data capture. | The dashboard tells you something is wrong across many calls and you want the pattern, not one example. |
| [**Public API**](/docs/api-reference/create-call) | Create and update agents, push calls, read them back. | Provisioning agents programmatically, or building Tuner into your own tooling. |
***
## 6. Data and compliance controls
| Feature | What it does | When you want it |
| -------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------- |
| [**PII redaction**](/docs/observability/pii-redaction) | Detects names, phone numbers, addresses, national IDs, card numbers, and spoken PINs in each transcript and replaces them with labels before storage. The unredacted version is never kept. Workspace-wide, on the Growth plan. | Regulated data on your calls, or a policy against storing caller details. |
| [**Data retention**](/docs/observability/data-retention) | Sets how long call data is kept and what is erased when it expires, from 7 days to 1 year, plus **Never** on Enterprise. Always on, workspace-wide. | Any compliance policy with a fixed data lifetime. |
Where your agent runs and where Tuner runs are separate questions. Your agent can be entirely self-hosted on any plan. Tuner itself runs as a hosted cloud service, with **on-premise deployment available on Enterprise**, alongside SOC 2 and HIPAA compliance, custom integrations, and a DPA on request. See the [FAQ](/docs/resources/faq) for both.
***
## What makes Tuner different
Useful when you are comparing tools, or deciding whether you need more than one.
A testing tool and a monitoring tool that know nothing about each other means writing the same criteria twice and watching the two definitions drift apart. In Tuner the evals, outcomes, and intents you define are used in both places. A behaviour you catch in simulation is scored the same way when it reaches production, and a failure you discover in production becomes a pressure test on the next run without any extra setup.
A call duration tells you a call was slow. Tuner's SDK integrations record end of utterance, STT, LLM, TTS, and time to first byte per turn, so you can point at the stage that cost you the second. That level of detail is not available from a platform that only hands over a finished transcript, which is why the SDK path captures more than the webhook path.
An eval judge can be given the agent's system prompt, its tools, its workflow, and the actual tool calls and results from the call. That turns evaluation into something checkable: did the required tool really run, were its arguments right, did the agent report back what the tool actually returned, did it follow the prompt it was given. Tone scoring is still there, it is just not the only thing an eval can do.
Simulation places actual voice calls over SIP, inbound or outbound, rather than exchanging text with your agent's logic. Your telephony, your endpointing, your TTS, and your latency are all in the loop, so what you are testing is the thing your customers will hear.
Managed platforms, self-hosted frameworks, and fully custom stacks all connect. If you switch from a managed platform to your own infrastructure, your evals, history, and dashboards come with you rather than being left behind in a vendor's console.
The MCP server both reads and writes. It is not a chat interface over your metrics. You can ask what is failing across every call, get the root cause, and have the fix applied to the agent's configuration in the same conversation.
Credits are spent on the analyses you switch on, not on a seat count. An agent with three evals costs less per call than one with fifteen, and alerts and red flags cost nothing at all. Plans set your monthly credit allowance and feature access, starting free on Pay as You Go with 300 credits and no commitment. Current rates and plan contents are on the [pricing page](https://usetuner.ai/pricing).
***
## Where to go next
Connect an agent and get a scored call.
Test before launch and after every change.
How calls are judged, and what the judge can see.
What to check, and how often, once calls are flowing.