You have the architecture (Chapter 1), the build approaches (Chapter 2), the latency discipline (Chapter 3), and the deployment patterns (Chapter 6, Chapter 9). This chapter compresses them into two artifacts: a five-question decision framework you can answer in one meeting, and a first-week build plan that ends with a conversing agent.
Answer these before writing code. Together they determine your build approach and where each component runs.
Human conversation runs on median turn gaps of roughly 200 ms (Stivers et al., 2009, PNAS); that is the bar users apply without knowing it. Budget your pipeline per stage as in Chapter 3, and count a network round-trip for every stage that runs remotely. If the budget is tight, move stages on-device: local inference deletes round-trips instead of shrinking them, and Orca Streaming Text-to-Speech starts speaking 128 ms after the first token (TTS benchmark).
If audio is regulated (health, finance, children's voices) or contractually confined, decide now whether it may leave the device at all. Audio processed on-device creates no residency, retention, or transit obligation to mitigate (Chapter 8); audio sent to a cloud pipeline creates all three. The medical voice agent tutorial shows the on-device answer applied to HIPAA-sensitive audio.
Vehicles, factories, field hardware, and anything that must keep working during an outage need an agent that runs offline (in-car voice control, factory voice agents). If the answer to "does the product still work with the network down?" must be yes, the core loop belongs on the device.
Model the cost at production volume, not pilot volume. Cloud pipelines carry usage-based pricing, so the bill grows with every conversation without bound. On-device engines are cost-effective at scale because inference runs on hardware you already ship. If your projections make the cloud meter a dominant cost line, choose the component path before launch rather than migrating after.
If users can ask anything, you need an LLM: picoLLM on-device for bounded reasoning, a frontier cloud model behind a hybrid split for unbounded reasoning, following the Apple Intelligence pattern of on-device by default with cloud escalation (Apple Machine Learning Research). If the agent handles a defined command-and-control domain, Rhino Speech-to-Intent maps speech straight to structured intents, with 6x fewer errors than the Big Tech average on the NLU benchmark, and no LLM in the loop at all.
The five answers are one decision viewed from five angles. Latency, privacy, connectivity, and cost at scale all improve when inference moves on-device; domain openness decides how much reasoning must stay in the cloud. Start from the fully on-device stack and promote only the reasoning stage to the cloud if question 5 demands it. That is the hybrid architecture the platform vendors converged on, and it keeps every other property intact.
The plan below builds a component-level agent per Chapter 2, one stage per day, so each stage is verified before the next depends on it. Every engine involved is available on the Picovoice Free Trial.
Sign up at Picovoice Console and copy your AccessKey; it authenticates every engine. Pick your platform SDK from the docs (Python is the fastest path for a first build), and get microphone audio flowing: capture frames, print amplitude, confirm your device and sample pipeline work. Unglamorous, and the foundation of everything after.
Add Cobra Voice Activity Detection to classify frames as speech or silence, then feed speech through Cheetah Streaming Speech-to-Text and print partial transcripts as you talk. By the end of the day you have the "Listen" and "Understand" stages of the loop running locally, and you can watch endpointing behave against your own pauses.
Wire the transcript to your reasoning stage, chosen by question 5. For a command domain, design your Rhino context (intents and slots) in Console and get structured intents out of raw speech. For open dialog, connect picoLLM or your chosen cloud LLM and stream response tokens. Keep the first task narrow: one workflow, a handful of intents or one system prompt.
Close the loop with Orca Streaming Text-to-Speech, synthesizing from tokens as they arrive rather than waiting for the full response. Then implement barge-in: keep Cobra listening during playback, and stop synthesis the moment the user speaks (Chapter 3 covers the state machine). An agent that cannot be interrupted feels broken regardless of how well it answers.
Instrument the loop: timestamp end-of-speech, first LLM token, and first audio out, and compare against the budget from question 1. Test in the conditions you will ship under: background noise (add Koala Noise Suppression if needed), accents, mid-sentence corrections. Log every turn's transcript and timing; this is the seed of the observability layer in Chapter 7.
Instead of assembling from scratch, you can also start from a finished recipe and adapt it:
Add Porcupine Wake Word when the agent should activate hands-free, and Eagle Speaker Recognition when it should know who is talking.
Every stage in this plan runs on-device, so the agent you finish on Day 5 already has the properties the decision framework asks about: no network round-trips inside the loop, audio that never leaves the machine, offline operation, and a cost profile that is cost-effective at scale. Promoting the reasoning stage to a cloud LLM later is a one-stage change, not a re-architecture.
Everything in the first-week plan runs on the Free Trial: sign up, grab your AccessKey, and have the Day 1 loop running today. The docs cover every SDK and platform, the cookbook recipes provide complete working agents to adapt, and the published benchmarks let you verify engine claims on your own data before you commit.
The Common Failure Modes appendix closes the guide with the production failures that recur across voice agents and the pattern that prevents each. For definitions of any term used across these chapters, from barge-in to wake word, see the Picovoice voice AI glossary. Or go back to the guide hub for the full chapter map.