Automotive AI agent · Connected services
Connected-Car & Telematics Support AI Agent
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.
- Typical delivery
- 4–6 weeks
- Deployment
- Your stack
- Vehicle actions
- Not the agent's
- After launch
- Agent Care
What this agent does
Explains the alert, does not act on it
In
- 01
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
- 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.
Reaches the desk ready to read out.
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 required
8 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 boundary
Agent 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 alert
Illustrative example- Customer asked
- Why did the tyre alert come on?
- Channel
- Owner app, then the services line
- Matched to
- One account, one VIN
- Returned
- The reading and its time
- Confidence
- 89%
- Safe to drive
- Not the agent's to say
As received
The customer's own words and the channel they came in on, kept beside the reading — nothing on this side is inferred.
Evidence used
- Account and VIN entitlement
- Logged sensor reading
- Overnight temperature drop
Why no cause is given
The vehicle reported a low reading, not a puncture. What caused it is a person's call.
What the score decides
Confidence decides how much the desk re-checks, not what reaches the vehicle.
Action
AuthoriseCorrectEscalate to the OEMValue
Where AI adds value
The same four claims, placed at the point in the workflow where each one applies.
Where the value lands
Value 01 – 04
Every connected-services contact
Owner app, the services line or an OEM queue
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.
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.
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.
Build 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 data
- Vehicle event feeds
- diagnostic codes
- Connection and module state
Connected-services platform
- OEM services portal
- entitlement records
- Subscription status
Vehicle command & update
- Command queue
- acknowledgement log
- Update campaigns
- install status
Agent
Connected-car & telematics support
- Checks entitlement
- Explains the reading
- Requests, never sends
Customer & case systems
- Owner app
- services-line telephony
- Case records
- consent lists
Observability & evaluation
- OpenTelemetry
- Langfuse
- Supported monitoring/evaluation sources
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 defence
Inward → L1 · closest to the model
- L1 – L2
- Decide what may be read and what may be said
- L3
- Marks how old the reading behind an answer is
- L4 – L5
- Leave the command with a person, trail kept
- L6
- Pulls 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
- 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 lifecycle
Direction of processing →
01 · Entitlement / match
2 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 resolves
The caller, the account, the VIN and what it entitles
02 · Vehicle record
2 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 reads
The logged event, the module state and the connection
03 · Explanation
1 mode
- CC-05
Alert explained as a fault
A cold-snap pressure drop is answered as a puncture.
Stage explains
What the vehicle reported, when, and what it leaves out
04 · Request / handoff
1 mode
- CC-06
Command queued, not delivered
The car was asleep; the customer was told it locked.
Stage requests
The vehicle action a person authorises and watches
05 · Change / Version
1 mode
- CC-07
Update moves the feature
A vehicle-software change retires what the answer describes.
Stage tracks
Model, prompt, platform and vehicle-software changes
- Sev-1 · data reaches the wrong person
- Sev-2 · the customer is told more than was read
- Sev-3 · the answer thins and is re-checked
Affected slices
A car changes hands; the account does not
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 aggregate
Illustrative 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 stages
Switchback — the path turns at Improve and returns at Learn
- 01
Detect
Desk corrections, repeat contacts or unacknowledged commands move in a cohort.
- 02
Diagnose
The gap is in entitlement, the record read, the age of the reading, the wording, or the platform itself.
- 03
Improve
The rule or the wording changes under your connected-services change control, with a named approver.
- 04
Verify
Re-run on stored cases from that cohort, including the ones the desk had to take back.
- 05
Learn
The corrected case joins the regression set and the limit it exposed enters the desk's own script.
Learn → Detect
The 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.
Workstream
Week 1Week 2Week 3Week 4Week 5Week 6
- 01Connected-services discovery and boundaries.Week 1
- 02Withheld-claim rules for faults and safety.Week 1, Week 2
- 03Account, entitlement and consent rules.Week 1, Week 2
- 04Telematics event and code catalogue mapping.Week 2
- 05Vehicle-record and connection-state retrieval.Week 2, Week 3
- 06Subscription, network and update-state checks.Week 3
- 07Alert explanation and data-age marking.Week 3, Week 4
- 08Vehicle-action request and authorisation routing.Week 4
- 09Evaluation suite, slices and past-case replay.Week 4, Week 5
- 10Identity, disclosure and audit logging.Week 5
- 11Case write-back and desk handoff.Week 5, Week 6
- 12Observability, deployment and Agent Care handover.Week 6
12 workstreams · 6 weeks · bar shows the weeks a workstream is active — several run in parallel
Final 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 tier | PilotOne brand, one channel | ProductionLive connected-services desk | AdvancedMulti-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 price | From $5,000 | From $8,000 | Custom quote |
- Final build price
- Confirmed 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 build
- Build 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 bring
We build with it
01Your connected-services scripts and what an answer may never claim
→Withheld-claim rules for faults and safety
Week 102How entitlement, consent and removing a user work today
→Account, entitlement and consent rules
Week 103Access to the telematics event feed and your code catalogue
→Telematics event and code catalogue mapping
Week 204Subscription, network and software-update state for the vehicles in scope
→Subscription, network and update-state checks
Week 305Who may authorise a vehicle action, and what stops one
→Vehicle-action request and authorisation routing
Week 406Cases that went wrong, including the ones a supervisor took back
→Evaluation suite, past-case replay and failure-mode testing
Week 407Named connected-services agents and a supervisor
→Case write-back and desk handoff, then supervised handling
Weeks 5–6
Nothing else is required
Deployment, 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.
Phase
W1
W2
W3
W4
W5
W6
- DiscoveryW1
- BuildW2 – W3
- EvaluateW4 – W5
- Pilot & LaunchW5 – W6
Week focus
W1Boundaries, entitlement rules and what an answer may never claim
W2Telematics events, codes and the vehicle-record read
W3Subscription, network and update state, and data-age marking
W4Evaluation suite, past-case replay and authorisation routing
W5Case write-back, slice testing and the first supervised cases
W6Your agents work live cases, then Agent Care starts
- Reading the band
- Authorisation routing is built in week 4, before a request the agent raises reaches any vehicle in week 5.
- At the end of W6
- Cases 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.
- Duration
- Six-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.
- Typical delivery
- 4–6 weeks
- Deployment
- Your telematics and services stack
- Vehicle actions
- Authorised by a person, always
- After launch
- Agent Care available
Nestack Agents · Connected-car & telematics support
AGT-AUT-06 · Agent Care available after launch