Skip to main content
A desktop voice assistant needs to determine more than which app to open. “Open Finder and show Downloads” contains an app, an operation and an exact target. Putting every possible combination into one question would create a large, repetitive menu. This cookbook builds a small hierarchical router with the Tazo Python SDK. Tazo Large hears the same original audio at every stage, with earlier selections as context. Each answer chooses from a small local menu. The application assembles an action plan and releases it only when the required decisions pass. The runnable backend and recordings print plans and traces. Device execution is an adapter you can add after reviewing a plan. Every model stage also has NO_TOOL and confidence checks. An unsupported or uncertain choice stops routing before a plan is released.

Setup

Use Python 3.11 or newer:
Commands must be nonempty mono 16 kHz PCM16 WAVs of at most 30 seconds. This backend runs without macOS. The source app’s hotkey recorder, SwiftUI interface and native device adapters are outside this recipe; its hierarchical audio-routing pattern is preserved.

Define the command tree

This example supports a small subset of the source assistant: General app commands select exact targets from the local maps below. The model returns an ID such as downloads; local code supplies the actual target. It cannot invent a URL, app name, shell command or executable argument. Coding mode’s extra apps are available only through that named preset.

Ask one question at a time

Router.ask sends the original WAV and a fresh question for the current stage. Earlier selections tell Tazo what has already been chosen. A stage needs at least 65% confidence and a 12-point lead over the runner-up. NO_TOOL or an unrecognized choice never passes. The helper records a trace and enforces a ten-decision ceiling and a 1,000-character text budget per stage. If a menu grows too large, shorten descriptions or split the stage into smaller choices rather than silently dropping options.

Assemble the plan

Add this method to Router. First choose a structure for the whole command. Open-only commands select one or two distinct apps. An app-action command then selects an operation from that app’s menu and a target from that operation’s menu. A final app-command question compares the entire recording with the plan: opening Finder does not also fulfill “show Downloads.” A confident missing answer discards the plan, just as an uncertain stage does. This recipe asks the speaker to clarify rather than trying to repair a partial plan automatically. Timers select one exact duration, and Coding mode expands a fixed local preset; these two branches return directly after their bounded decisions.

Route recordings and inspect the result

route_command validates the recording before sending it. It returns an empty plan when routing is unresolved. API and SDK errors propagate, so a failed request cannot return a partly built plan as though it were complete.
From the cookbook repository root:
A successful result has this shape; confidence values are illustrative:
The sample recordings are original commands synthesized with macOS say, voice Samantha. A live SDK 0.1.2 check routed the six supported fixtures to their intended plans and rejected both unsupported fixtures. Outputs remain probabilistic between runs. Multiple input files are routed independently. A result with status="needs_clarification" includes a reason and trace, with plan=[]. No desktop side effect occurs in this example.

Build on it

  • Add an app or action. Extend the app menu, its operation map, and its exact target maps together. Keep concrete URLs and device identifiers in application code.
  • Filter by availability. Before asking, remove choices whose apps, saved targets or permissions are unavailable on the current device.
  • Execute a reviewed plan. Preflight every step, show the entire plan for review, then call typed adapters in order. Keep a receipt if a later step fails after earlier effects.
  • Support longer combinations. Add another bounded structure and corresponding stages. Keep the completion check and decision ceiling, and account for extra serial latency.

Limitations

  • This is a planner. Timers, app launches and window placement are output steps; real desktop adapters, a countdown and a review interface belong in your application.
  • Only the structures and targets above are supported. A request for an arbitrary URL, dictation or a third general-command app must stop without a plan.
  • Confidence and completeness checks are probabilistic, not guarantees of correct routing. Test your actual spoken commands before connecting side effects.
  • Every stage resends the same recording and consumes another decision. More stages add inference usage and serial network time. Failed routes are not automatically replayed.
The full Personal Assistant for Mac source adds a native macOS interface, more app operations and bounded command compositions. For a smaller state-machine routing example, see Graph agents.