Skip to main content
The QA node scores your calls automatically once they finish. Use it to check whether the conversation went well, flag calls that need a human to review them, or pull structured insight out of transcripts at scale. Analysis runs after the call ends, as a background job. It never affects the live conversation.

​
Adding a QA node

Add a QA node to your workflow from the builder, then write the analysis criteria you want applied. The criteria are a prompt: describe what to look for and what to return. Ask for JSON. These four fields are recognised and shown as structured results: Anything else you return is kept in the raw response but not broken out separately.

​
What gets analysed

Analysis is per node, not per call. Each node the conversation passed through is scored on its own, so you can see which part of the workflow went wrong rather than just that something did. A result for one node looks like this:
Tags raised by any node are also collected into a single list for the whole run, so you can filter for a tag without inspecting each node.

​
Choosing the model

By default QA uses the same LLM as the workflow. Turn that off to pick a different provider, model, and key for analysis alone — useful when you want a cheaper model for scoring than for talking, or a stronger one. QA analysis is a separate LLM call. Its token usage is added to the run’s usage breakdown under QAAnalysis, so you can see exactly what each analysis cost.

​
Controlling which calls are analysed

Analysing every call gets expensive at volume. Three settings limit it: You can also disable a QA node entirely without deleting it.

​
Viewing results

Open the Run Detail page for any run to see its QA results. If you are reading runs through the API, results live in the run’s annotations field, keyed by QA node. Each node result keeps the model’s raw_response alongside the parsed fields, so you can still see what the model said if the output was not valid JSON. A result will tell you one of three things:
  • Analysis ran — you get node_results with a result per node
  • Skipped — the reason is included, for example a call below the minimum duration or one excluded by sampling
  • Error — analysis was attempted and failed

​
Testing your criteria

Sampling and the duration minimum both cause QA to produce nothing, which is easy to mistake for a broken node. While you are iterating on criteria, set the sample rate to 100% and the minimum duration to 0 so every test call is analysed. Then run your criteria against several deliberately different calls — one that went well, one where the agent missed something, one that ended early. A single good call will not tell you whether your scoring actually discriminates.