Answer on the device inside a configured capture scope, disclose that it is an AI system at first interaction, and hold anything outside that scope for the named product owner, who decides.
When a wake word or screen tap opens a turn, take the request from the on-device recogniser, inside scope.
02
Where a capture falls outside that scope, discard it on the device rather than normalise it and pass it on.
Reason
03
Where the product has a screen and a speaker, draft the spoken answer, the on-screen text and the disclosure together.
04
Apply the capture, consent and disclosure settings configured for where the product ships.
05
When an answer rests on a document, carry the product source and revision it was drawn from with it.
Decide
06
When a request touches a safety function, a health reading or a support commitment, stop and hand over.
07
Route every held response to the named product owner for a decision.
Out
08
Retain what was captured and why, with the answer given — held in your deployment, not in a shared pool.
09
Execute device actions only inside the scope agreed during implementation.
→Product statement
The agent speaks; the named product owner decides what it is allowed to say, and the manufacturer stays responsible for the device.
Example workflow
One turn, spoken to signed off
AgentHuman
1Spoken request receivedWake word on the device, a screen tap on an HMI or a head-unit press
2Scope checkedCapture scope, the configured consent setting, device state and product model
3Response draftedSpoken answer, on-screen text, the AI disclosure and confidence
4Controls appliedScope checks, safety-function exclusions, consent and disclosure settings and confidence threshold
No human action required
Stages 1 to 4 run unaided on the device, and no safety or actuation function is reachable at any of them — the product owner's lane opens at the confidence gate.
5DecisionBranches at the confidence threshold
High confidence
Goes to the named product owner.
Low confidence
Adds a safety-engineering read first.
Product-owner review
The response is held with what was captured, the scope it was answered in and the confidence.
Release · Revise · Send to safety review
Released — spoken on the device▼
6Device settings updatedOnly where the configured scope allows it
7Outcome evaluatedRevision rate, held-response outcomes, false-accept captures and owner corrections
Revisions
Every owner revision is counted, corrections included.
What should not run autonomously
Human approval stays in control
Outside the boundary — human approval required8 items
Controlling or silencing a safety function.
Using captured audio to train a shared model.
Interpreting a health reading for the speaker.
Enabling voiceprint or speaker recognition.
Automation boundaryAgent acts unaided
✓Answer product questions on the device, inside the configured scope.
✓Disclose that it is an AI system at the first interaction.
✓Apply the capture and consent settings configured.
✓Hold anything outside the scope for the named product owner.
Device actions stay inside the agreed scope, and captured audio has no route to a shared model.
Retaining a child's voice recording or transcript.
Scheduling or triggering a firmware update.
Stating a support end date or update commitment.
Changes to capture, consent or disclosure settings.
Example output
One interaction, annotated
Everything the agent says is attached to the capture it was answered from.
Assistant output · single interactionIllustrative example
Device
Spoken answer
Capture scope
Answered from
Confidence
Disclosure
Kitchen speaker
This model's filter is released from the front panel
Single turn
Product manual, rev C
91%
Announced as an AI system at the first turn
As receivedTaken from the device and the published manual — nothing on this side is written by the agent.
What it drew onProduct manual revisionDevice state on handConfigured capture scope
Why this answerAnswered inside the configured scope — the owner still decides what it may reach.
ActionReleaseReviseSend to safety review
What the score decidesHeld for the named product owner before anything leaves the device.
Value
Where AI adds value
The same four claims, placed at the point in the workflow where each one applies.
Where the value landsValue 01 – 04
Every interactionFrom the device
03Answering
Answer from the product
Draw on the published product documentation and the device state on hand.
01Approved path
On the device, inside its scope
Routine product questions are answered where they are asked.
02Human review
Send review to what it must not answer
Safety, health and support-commitment requests are held, so the owner's read starts where risk concentrates.
04Build an evidence trail
What was captured, what it was used for and the owner's setting stay together on the device record.
Integrations
Typical integrations
Five system groups connect to the same agent. Which of them are in scope is decided in discovery.
Device platformsAndroid Automotive · AAOS Embedded Linux · RTOS builds
Voice and audioOn-device wake word · ASR Text-to-speech · microphone front end
Product knowledgeManuals · release notes Spec sheets · service bulletins
Agent
Device-embedded assistant
Hears the request Answers on device Holds what is out of scope
Support and telemetryZendesk · Salesforce Service Fleet telemetry · device management
The people systematically under-counted are the ones who never spoke to the device — bystanders, passengers and children in the room. Nestack reports the owner-revision rate by slice, not only in total.
Slice performance — reported separately, not only in aggregateIllustrative example
Slice
Failure rate
Lift
Lift vs. threshold
Status
Unintended wake-word activations
9.0%
3.9×
Review
Multi-speaker rooms and cabins
5.5%
2.4×
Review
Accented and non-native speech
3.9%
1.7×
Watch
Single-speaker quiet rooms
1.4%
0.6×
Normal
Bar: owner-revision-rate lift vs. quiet-single-speaker baseline · scale 0–4.0× · tick marks the 2.0× review threshold2 of 4 slices over threshold
Evidence-linked improvement
A cycle ends in a regression case
Nothing closes because it was understood. It closes when the next release has to pass a case, and that suite is what the next interaction is measured against.
Improvement cycle · five stagesSwitchback — the path turns at Improve and returns at Learn
01Detect
Owner-revision rate rises in a device cohort.
02Diagnose
Which capture, which scope, which release? The team reads the held interactions until one answer holds.
03Improve
Changes ship against a version with the interactions that caused them.
04Verify
A failing case blocks release until it clears.
05Learn
The case is permanent, and the capture rules move with it.
Learn → DetectThe return edge. The next detection runs against a suite that is one case longer.
Typical build scope
Twelve workstreams across six weeks
The build scope read against the delivery timeline. Week structure follows the six-week plan — discovery, platform, answering workflow, evaluation, integration, then production validation and handover.
WorkstreamWeek 1Week 2Week 3Week 4Week 5Week 6
01Interaction discovery and capture-scope definition.
02Device platform and audio-stack assessment.
03Consent, disclosure and jurisdiction-setting mapping.
04On-device capture and turn normalisation.
05Answering logic and product-source binding.
06Confidence scoring and handover routing.
07Product-owner review workflow.
08Device-platform and support integration.
09Capture-scope regression cases.
10Guardrails and consent controls.
11Interaction-trail instrumentation.
12Deployment, documentation and Agent Care handover.
12 workstreams · 6 weeks · bar shows the weeks a workstream is active — several run in parallelFinal scope and sequence confirmed in discovery
Engagement tiers
What each tier includes
Rows are the capabilities named in each tier's scope. Higher tiers include everything below them.
Capability✓ in scope · — not at this tierPilotOne device modelProductionProduction device fleetAdvancedMultiple products / markets
Introduced at Pilot
Answering inside your scope✓✓✓
Product-owner approval✓✓✓
Interaction-quality baseline✓✓✓
Introduced at Production
Reporting by device model—✓✓
Review workflow in your systems—✓✓
Approved device actions—✓✓
Device-platform integration—✓✓
Introduced at Advanced
Complex product-line rules——✓
Multi-stage product approvals——✓
High device volume——✓
Multi-market device controls——✓
Build priceFrom $5,000From $8,000Custom quote
Final build priceConfirmed after discovery based on integrations, workflow complexity, device volume, approval controls and deployment requirements.
Separate from buildBuild pricing is separate from recurring Agent Care, which covers managed monitoring, evaluations, incidents and verified improvements after launch.
What we need from you
What you bring, and what we build with it
Each input maps to a piece of build scope and a week in the delivery timeline.
You bringWe build with it
01Your device platform and audio stack→On-device capture and turn handlingWeek 1
02Representative interactions from the product→Answering baseline, product-source binding and scope mappingWeek 2
03Your capture scope and disclosure wording→Consent, disclosure and capture-scope boundary definitionWeek 1
04Access to device builds, telemetry or exports→Device-platform and audio-stack assessment, then integration setupWeek 2
05Interactions you would not want retained→Consent cases and failure-mode testingWeek 4
06What the assistant is never allowed to reach→Confidence scoring, handover routing, guardrails and approval controlsWeek 3
07Named product owners to review held responses→Product-owner review workflow, then pilot and production validationWeeks 5–6
Nothing else is requiredDeployment, documentation and Agent Care handover are ours.
Delivery timeline
Four phases across six weeks
Each band covers the weeks it genuinely occupies, so the fifth week holds two kinds of work.
PhaseW1W2W3W4W5W6
DiscoveryW1
BuildW2 – W3
EvaluateW4 – W5
Pilot & LaunchW5 – W6
Week focusW1Interaction discovery, capture-scope mapping and the automation boundaryW2Device-platform integration and the answering baselineW3Answering workflow, confidence logic and approval controlsW4Evaluation suite, consent cases and failure-mode testingW5Support integration, pilot devices and targeted correctionsW6One device cohort run under the product team, then Agent Care handover
Reading the bandEach bar covers only the weeks its work is named in. The fifth week genuinely holds two kinds of work.
At the end of W6Live devices close the validation and monitoring moves to Agent Care.
DurationSix-week plan shown · typical delivery 4–6 weeks depending on scope confirmed in discovery.
Next step · Electronics AI agent
Build an embedded assistant around your product's capture scope.
Show us the device, what it is allowed to hear and what it must never reach. A named product owner signs what the assistant may say, and we set that name in the build from week one.
