AI Agents

Wearable Device as an AI Agent Endpoint: Cloud or On-Device

Production line for AI hardware
Wake word and on-device inference decisions are locked before this line runs. Reference photography from our production line or product set.
TITLE: Assistant Hand-Off Phone vs Standalone Voice Hardware DESC: Two architectures for voice on AI devices, and why the choice decides your app-store path, your BOM and your certification scope. Read before you brief a supplier. KEYWORDS: assistant hand-off phone, standalone voice assistant hardware, AI device app store, voice assistant OEM, embedded assistant architecture TAGS: AI agents, voice, OEM, compliance, app store Q: Can a standalone assistant device ship with Google Play or GMS? A: Not by default. Google Play and GMS are not licensed with the hardware, so a standalone device usually runs your own app layer, an AOSP build or a curated store. Budget the licensing and update path as a separate workstream from the hardware. Q: Does hand-off to a phone assistant change my certification scope? A: It can narrow it. If the device only captures audio and passes it to a paired phone, the radio and compute load sit largely on the phone, but you still certify your own radio, charger and battery. The test scope is booked per hardware revision with an accredited laboratory, so a change of module means a new booking.

Most buyers approach voice as a feature list: wake word, languages, latency. The more consequential decision is architectural. Either the device hands audio or intent to an assistant that already lives on the user's phone, or it runs the assistant itself as standalone voice assistant hardware. The two paths produce different bills of materials, different app-store obligations and different certification scopes. Choosing late is expensive, because the choice is baked into the radio, the memory and the enclosure.

How assistant hand-off actually works

In a hand-off design, the device is a peripheral with a good microphone array and a Bluetooth or Wi-Fi link. It captures speech, applies echo cancellation and noise suppression locally, then passes either raw audio or a parsed intent to an app on the paired phone. The phone's assistant does the language model work. This keeps the device cheap: less RAM, less flash, no thermal budget for sustained inference, and often a smaller battery. It also means the user experience is only as good as the phone, and that the device is useless without one. For a purchasing manager, the practical consequence is that your firmware team is writing a companion app, not an operating system.

The trade is control. You inherit the phone assistant's language coverage, its privacy disclosures and its update cadence. If the phone assistant changes its wake-word policy or restricts background audio, your product changes with it. That risk belongs in the contract, not in a support ticket six months after launch.

What standalone changes in the BOM and the app layer

A standalone device carries the inference stack itself. That usually means a more capable system-on-chip, more memory, a larger battery and a thermal design that survives continuous listening. It also means you own the software surface: the wake word, the skill set, the account system and the update mechanism. Google Play and GMS are not licensed by default, so a standalone product typically runs an AOSP build, a curated store or a single-purpose interface. Each of those is a decision with a cost, and none of them is free.

Standalone is the right answer when the product must work without a phone: a kitchen device, a bedside unit, a workshop tool. It is the wrong answer when the phone is always present and the budget is tight. Our firmware and app white-label workstream exists precisely because this boundary has to be drawn before tooling, and the MOQ for white-label firmware or app work is 2,000 units.

App-store consequences you should price in

Hand-off devices usually ship with a companion app distributed through the public stores. That brings review cycles, store policy compliance and a dependency on the store's rules about background microphone access. Standalone devices often avoid the public store entirely, which removes review friction but shifts the update burden onto you: your own signing keys, your own update server, your own rollback plan.

Decision pointHand-off to phoneStandalone assistant
Compute locationPhone performs inferenceDevice performs inference
App distributionCompanion app via public storeOwn layer, AOSP or curated store
GMS / Google PlayGoverned by the phoneNot licensed by default
Works without a phoneNoYes
Typical certification scopeOwn radio, charger, batteryOwn radio, charger, battery, thermal
Update ownerShared with phone platformEntirely the brand owner
Customisation MOQLogo 500 units, custom packaging 1,000, firmware or app white-label 2,000

Certification and compliance follow the architecture

Documents are supplied per model and hardware revision: CE RED covering EN 300 328, EN 301 489 and EN 62368-1, FCC Part 15 B/C, UKCA on request, RoHS 3, REACH SVHC screening, battery UN38.3 with SDS. EN 1811 nickel release applies to skin-contact items. Toy scope under EN 71-1/-2/-3, EN 62115 and the Toy Safety Directive is decided by the age grading printed on the packaging and booked with an accredited laboratory per build. If the product is a companion robot, remember it is not a monitoring or emergency-response device, and any health metrics are wellness guidance rather than diagnosis. Translation output is a reference translation.

Where an importer should say no: to a supplier who offers to "reuse" a test report across a different radio module, or who cannot state the hardware revision the report covers. EU and UK importer duties, including WEEE, BattG, DEEE/Triman and EORI/VAT registration, sit with you, not the factory.

Choosing, then briefing

Decide the architecture first, then let it drive the specification. A hand-off product is a microphone, a link and an app; a standalone product is a small computer with a voice interface. Both are legitimate, and both are represented in our product catalogue, from the pocket translator to the companion robot and the AI glasses.

  1. Write down whether the product must function with no phone present.
  2. Map that answer to compute, battery and thermal budget before requesting quotations.
  3. Confirm who owns the update path and the signing keys.
  4. Ask which hardware revision each compliance document covers.
  5. Check the age grading on the packaging before ordering toy-scope testing.
  6. Confirm the importer-side registrations you will need in each destination market.

Samples run 3-5 days from stock and 7-15 days configured, with the sample cost credited against mass production; production is 25-35 days, or 30-40 for education models, and ODM tooling runs 12-20 weeks. Standard MOQ is 500 units, 300 for AI glasses and 50 for service robots quoted per project. Send the specification, including the architecture decision, through our contact page and we will return a quotation with the certification scope stated per revision.

Questions buyers ask

Can a standalone assistant device ship with Google Play or GMS?

Not by default. Google Play and GMS are not licensed with the hardware, so a standalone device usually runs your own app layer, an AOSP build or a curated store. Budget the licensing and update path as a separate workstream from the hardware.

Does hand-off to a phone assistant change my certification scope?

It can narrow it. If the device only captures audio and passes it to a paired phone, the radio and compute load sit largely on the phone, but you still certify your own radio, charger and battery. The test scope is booked per hardware revision with an accredited laboratory, so a change of module means a new booking.

Related: more on ai agents · buyer guides · customisation tiers