Why three persistent sessions
A streaming session takes one question. Open three sessions for one rep reply, send the same audio to each, and keep them open throughout that reply. This avoids starting three new connections for every second of audio. Useaudio_scope="turn" so each evaluation hears the reply so far. A 1,000 ms evaluation
interval requests frequent feedback; it does not guarantee that answers arrive every
second. The interval applies to each of the three sessions, and every evaluation uses
your account’s inference allowance.
Setup
Use Python 3.11 or newer:Define the coaching questions
The option descriptions tell Tazo what each choice means. Keep them distinct and short: they share the request’s text budget with the instructions and history. Each question includesNO_TOOL for insufficient evidence. These sales questions are condensed from
the source project’s coaching definitions.
Supply history and decide when to trust feedback
History contains only turns before the attached reply, with explicitrep and
customer roles. It is supplied by your application; Tazo does not transcribe it. With a
live call, refresh that history when a new reply starts. Do not append the current reply’s
transcript as if it were something the customer said.
The helper rejects an oversized request instead of silently dropping turns. Keep the
relevant context short enough for each question’s 1,000-character budget. A choice needs
at least 65% confidence and a 12-point lead over the runner-up to clear the review gate.
NO_TOOL always needs review and is represented as null in the output.
Stream a reply and consume feedback
Each question gets one sender and one receiver.wav_chunks removes the WAV header and
validates the audio format; pacing imitates a microphone. Frames respect the negotiated
message limit, and a numeric turn limit is checked when present. A None turn limit
means the service has not advertised a cumulative cap.
At the end of the recording, commit the turn, consume its final decision, call finish(),
and keep receiving through normal closure. The final answer must cover the full reply.
A provisional update can change as more speech arrives.
Run all three questions together
The three tasks share a client and receive identical WAV samples. A failed question cancels its siblings, and context managers close the sessions. There is a 180-second deadline for this recorded-reply example; it is separate from the audio duration limit.question, event, choice, confidence, needs_review and
all option probabilities. Output from the three sessions can interleave. The speech
fixtures are synthetic macOS voices. These were observed in a live SDK 0.1.2 check;
choices, confidence and the number of intermediate updates vary between runs:
The discovery clip illustrates why the application checks evidence as well as confidence:
the model selected a customer need without any customer history. The solution clip shows
why a close runner-up should keep feedback in review.
Build on it
- Connect a live microphone. Replace the WAV sender with paced PCM16 frames. Gate capture during partner playback and silence; this example assumes its input is already a rep reply.
- Start the next reply. Open fresh sessions with updated earlier dialogue when the rep speaks again. Longer live replies need turn-limit handling if a numeric limit is advertised.
- Change the scenario. Replace the question specifications with interview improvement, answer direction or support-call coaching. Keep role attribution explicit.
- Show useful feedback. Display the chosen suggestion and its review flag; retain the probabilities for inspection rather than converting them to a performance score.
Limitations
- The thresholds are starting points, not calibrated guarantees. Clear speech can still produce low-confidence or incorrect coaching; the example results show both uncertainty and unsupported guesses.
- Feedback is advisory. The backend does not speak for the rep or execute the suggested move.
- History is fixed for a reply. An incorrect or missing transcript can mislead contextual questions, and long history is rejected by the local budget check.
- Failed streams are not reconnected or replayed automatically. Earlier printed updates remain provisional if a later error prevents the final answer.