Explain why an alert fired, why a feature stopped and why a command failed — from the vehicle's own record, with entitlement, consent and everything that reaches the car held by a named person.
Take the question as asked — the alert that fired, the feature that stopped or the command that failed.
02
Read the vehicle's own record — the event, the code, the module state and the connection history behind it.
Reason
03
Set out what the vehicle actually reported, when it reported it, and how old the reading on the screen is.
04
Separate a real condition from a lapsed subscription, a retired network, an update in progress or a queued command.
05
Read the account and its entitlement — who this vehicle's data belongs to, and who is only sitting in the car.
Decide
06
Hold anything that would name a fault, clear a vehicle to drive, or state a cause the record does not carry.
07
Route a vehicle action, a data disclosure or an account change to the person allowed to authorise it.
Out
08
Hand back a plain explanation with the reading, the time it was sent and what the desk should confirm.
09
Retain what was read, what was said, who asked, what was authorised and what the vehicle acknowledged.
→Product statement
The agent reads, explains and requests. A vehicle action, a data disclosure and an account change are authorised by a named person, and the vehicle's own acknowledgement is what closes one.
Example workflow
One connected-services case, end to end
AgentHuman
1Question arrivesOwner app, the connected-services line, an OEM agent's queue or a dealer's connected-services request
2Caller and vehicle matchedResolved to one account, one VIN and the entitlement that account holds, before any vehicle data is read
3Vehicle record readThe event or code as logged, the module and connection state, the subscription in force and any update running
4Explanation assembledWhat the vehicle reported and when, what the record does not say, and what a person would have to authorise
No human action required
Stages 1 to 4 run without a person in the loop — the match, the record read and the explanation all finish before anyone opens the case, and nothing has reached the vehicle at the end of them.
5DecisionSplits on entitlement, on the age of the reading and on whether anything would reach the vehicle
Entitled, and nothing reaches the car
Reaches the desk ready to read out.
Entitlement unclear, or the car is involved
Goes to the agent who can authorise it.
Connected-services agent
Reads the explanation, the reading behind it and what was held back, checks the caller's entitlement, then authorises anything that reaches the vehicle under their own name and waits for the acknowledgement.
Authorise · Correct · Escalate to the OEM
Acknowledged — logged back▼
6Explanation filed against the caseWritten to the case record; no command, setting, subscription or software change is sent from here
7Outcome evaluatedWhat the agent explained, what the desk corrected, what was authorised and what the vehicle acknowledged
Corrections
What the desk rewrites before speaking is counted in the evaluation.
What should not run autonomously
Human approval stays in control
Outside the boundary — human approval required8 items
Any remote command sent to a vehicle.
Telling a driver a vehicle is safe to drive.
Naming a fault as the cause of an alert.
Releasing location or trip data to a caller.
Automation boundaryAgent acts unaided
✓Match the caller, the account and the VIN before reading.
✓Read the logged event, the module and connection state.
✓Explain what the vehicle reported, when, and how old that reading is.
✓Name the pre-conditions and who would have to authorise a vehicle action.
The agent writes to the case, never to the vehicle. Anything reaching the car is requested, authorised and acknowledged.
Adding or removing a user on the account.
Starting, deferring or rolling back a software update.
Changing a subscription, feature or charge setting.
Confirming a recall or campaign applies to a vehicle.
Example output
One connected-services case, annotated
Everything the agent explains is attached to the reading it came from and the moment the vehicle sent it.
Support output · one telematics alertIllustrative example
Customer asked
Channel
Matched to
Returned
Confidence
Safe to drive
Why did the tyre alert come on?
Owner app, then the services line
One account, one VIN
The reading and its time
89%
Not the agent's to say
As receivedThe customer's own words and the channel they came in on, kept beside the reading — nothing on this side is inferred.
Evidence usedAccount and VIN entitlementLogged sensor readingOvernight temperature drop
Why no cause is givenThe vehicle reported a low reading, not a puncture. What caused it is a person's call.
ActionAuthoriseCorrectEscalate to the OEM
What the score decidesConfidence decides how much the desk re-checks, not what reaches the vehicle.
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 connected-services contactOwner app, the services line or an OEM queue
03Read & explain
Answer from the car's record
Use the event as logged, the module and connection state, the subscription in force and the entitlement the account actually holds.
01Approved path
Put the reading in front of the agent
The event, the time the vehicle sent it and the state of the connection arrive together, instead of an agent working from a photograph of a dashboard.
02Human review
Send the vehicle question to a person
Anything that would reach the car — a command, an update, a setting — waits for the agent allowed to authorise it, who then watches for the vehicle's acknowledgement.
04Build an evidence trail
Retain the question, the entitlement checked, the readings used, the explanation given, the authorisation and what the vehicle acknowledged — on both paths.
Integrations
Typical integrations
Five system groups connect to the same agent. Which of them are in scope is decided in discovery.
Telematics & vehicle dataVehicle event feeds · diagnostic codes Connection and module state
Connected-services platformOEM services portal · entitlement records Subscription status
Integration availability depends on the client's existing systems and API access.
Agent controls
Six layers between the model and the vehicle
Each control wraps the one inside it. An explanation clears every layer before the desk reads it, and the command itself sits outside all six.
L6 · Outermost — last line of defenceInward → L1 · closest to the model
L6Rollback / safe modeReturn connected-services handling to your staff if evaluations or production signals degrade.Roll back
L5TraceabilityRecord who asked, what was read, what was said, who authorised and what the vehicle acknowledged.Record
L4Command pre-conditionsA vehicle action is offered only where the pre-conditions, the authoriser and the stop are named.Gate
L3Data-age markingA reading is carried with the time the vehicle sent it, and its age is marked before use.Stamp
L2Cause and safety blockA named fault, a safe-to-drive answer and a recall clearance are kept out of the explanation.Withhold
L1Entitlement gateNo vehicle data is read, or read out, until the caller's right to it is established.Verify
Model coreExplanation drafted — the event as logged, the time the vehicle sent it, the state of the connection and confidence
L1 – L2Decide what may be read and what may be said
L3Marks how old the reading behind an answer is
L4 – L5Leave the command with a person, trail kept
L6Pulls automation back when signals degrade
How Nestack evaluates it
Evaluate the whole answer — not only the sentence the customer hears.
Coverage runs the whole depth of the workflow, and every layer is cut by slice.
Surface — the explanation the desk reads out
Depth of coverage ▼
E1Final-output evaluationWas the explanation true to what the vehicle reported?
E2Step-level evaluationDid it read the right event, module state and subscription record?
E3Tool evaluationWas the caller matched to an account entitled to this VIN?
E4Refusal recallDid a fault call, a drive-away answer or a command get through?
E5Slice evaluationWhich vehicle and account cohorts get the weakest answer?
E6Business outcomeHow many cases came back, and what did the vehicle acknowledge?
Floor — what the vehicle actually did next
Failure modes
Where each failure originates in the agent
Seven failure modes plotted against the five stages of the agent lifecycle. None of them commands a vehicle — the entitlement check, the named authoriser and the vehicle's own acknowledgement are the controls that stop them.
Agent lifecycleDirection of processing →
01 · Entitlement / match2 modes
CC-01
Removed user still entitled
Remote access outlived the order that took it away.
CC-02
Used vehicle still paired
The previous owner's app is still linked to the VIN.
Stage resolvesThe caller, the account, the VIN and what it entitles
02 · Vehicle record2 modes
CC-03
Stale reading read as current
The module last reported before the repair, not after.
CC-04
Retired network read as a fault
The car is off a shut-down network, not broken.
Stage readsThe logged event, the module state and the connection
03 · Explanation1 mode
CC-05
Alert explained as a fault
A cold-snap pressure drop is answered as a puncture.
Stage explainsWhat the vehicle reported, when, and what it leaves out
04 · Request / handoff1 mode
CC-06
Command queued, not delivered
The car was asleep; the customer was told it locked.
Stage requestsThe vehicle action a person authorises and watches
05 · Change / Version1 mode
CC-07
Update moves the feature
A vehicle-software change retires what the answer describes.
Stage tracksModel, prompt, platform and vehicle-software changes
Sev-1 · data reaches the wrong personSev-2 · the customer is told more than was readSev-3 · the answer thins and is re-checked
A vehicle that has changed hands, one that several people drive, and one whose module sits on a network that was switched off are where the record and the car disagree most. Nestack reports performance by slice, not only in total.
Slice performance — reported separately, not only in aggregateIllustrative example
Slice
Failure rate
Lift
Lift vs. threshold
Status
Second owners, account untransferred
6.2%
3.1×
Review
Vehicles on a retired network
4.4%
2.2×
Review
Shared and fleet-driven vehicles
3.8%
1.9×
Watch
Routine subscription questions
1.4%
0.7×
Normal
Bar: corrected-explanation-rate lift vs. routine-question baseline · scale 0–4.0× · tick at 2.0×2 of 4 slices over threshold
Evidence-linked improvement
What the vehicle did next is the score
An explanation the desk took back is not closed when that customer is called again. It moves the entitlement rule, the data-age limit or the wording.
Improvement cycle · five stagesSwitchback — the path turns at Improve and returns at Learn
01Detect
Desk corrections, repeat contacts or unacknowledged commands move in a cohort.
02Diagnose
The gap is in entitlement, the record read, the age of the reading, the wording, or the platform itself.
03Improve
The rule or the wording changes under your connected-services change control, with a named approver.
04Verify
Re-run on stored cases from that cohort, including the ones the desk had to take back.
05Learn
The corrected case joins the regression set and the limit it exposed enters the desk's own script.
Learn → DetectThe return edge. A change to what the desk may say about a vehicle's condition is signed off before it ships, not after the call.
Typical build scope
Twelve workstreams across six weeks
The build scope read against the delivery timeline. Week structure follows the six-week plan — discovery, entitlement and records, explanation and requests, evaluation, integration, then supervised handling and handover.
WorkstreamWeek 1Week 2Week 3Week 4Week 5Week 6
01Connected-services discovery and boundaries.
02Withheld-claim rules for faults and safety.
03Account, entitlement and consent rules.
04Telematics event and code catalogue mapping.
05Vehicle-record and connection-state retrieval.
06Subscription, network and update-state checks.
07Alert explanation and data-age marking.
08Vehicle-action request and authorisation routing.
09Evaluation suite, slices and past-case replay.
10Identity, disclosure and audit logging.
11Case write-back and desk handoff.
12Observability, deployment 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 brand, one channelProductionLive connected-services deskAdvancedMulti-brand / OEM programme
Introduced at Pilot
Alerts and codes explained from the record✓✓✓
Caller entitlement and identity checks✓✓✓
Fault, safety and recall answers withheld✓✓✓
Vehicle actions authorised by a person✓✓✓
Data-age marking on the reading behind an answer✓✓✓
Baseline evaluation✓✓✓
Introduced at Production
Subscription, network and update state—✓✓
Command routing and acknowledgement—✓✓
Case write-back and desk handoff—✓✓
Observability and evaluation—✓✓
Introduced at Advanced
Multi-brand and OEM programme controls——✓
Build priceFrom $5,000From $8,000Custom quote
Final build priceConfirmed after discovery based on brands and platforms in scope, contact channels, telematics and account-system integrations, case volume, authorisation routing 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 connected-services scripts and what an answer may never claim→Withheld-claim rules for faults and safetyWeek 1
02How entitlement, consent and removing a user work today→Account, entitlement and consent rulesWeek 1
03Access to the telematics event feed and your code catalogue→Telematics event and code catalogue mappingWeek 2
04Subscription, network and software-update state for the vehicles in scope→Subscription, network and update-state checksWeek 3
05Who may authorise a vehicle action, and what stops one→Vehicle-action request and authorisation routingWeek 4
06Cases that went wrong, including the ones a supervisor took back→Evaluation suite, past-case replay and failure-mode testingWeek 4
07Named connected-services agents and a supervisor→Case write-back and desk handoff, then supervised handlingWeeks 5–6
Nothing else is requiredDeployment, documentation and Agent Care handover are ours.
Delivery timeline
Four phases across six weeks
Phases are drawn over the weeks they actually occupy. Week 5 carries both the replayed cases and the first requests your agents authorise.
PhaseW1W2W3W4W5W6
DiscoveryW1
BuildW2 – W3
EvaluateW4 – W5
Pilot & LaunchW5 – W6
Week focusW1Boundaries, entitlement rules and what an answer may never claimW2Telematics events, codes and the vehicle-record readW3Subscription, network and update state, and data-age markingW4Evaluation suite, past-case replay and authorisation routingW5Case write-back, slice testing and the first supervised casesW6Your agents work live cases, then Agent Care starts
Reading the bandAuthorisation routing is built in week 4, before a request the agent raises reaches any vehicle in week 5.
At the end of W6Cases have run beside your existing desk, with every vehicle action requested by the agent, authorised by a person and left open until the vehicle acknowledges it.
DurationSix-week plan shown · typical delivery 4–6 weeks depending on scope confirmed in discovery.
Next step · Automotive AI agent
Build a connected-services agent around your own vehicle data.
Show us a month of connected-services contacts — the alerts, the failed commands and the features that stopped — with the vehicle records behind them. We'll answer them from your own telematics and mark every case where the record could not carry the answer the desk gave.
