Turn a VIN, a symptom or half a part number into candidates with the build data, supersessions and catalogue conflicts behind each — ordering and the fitment call stay with your parts department.
Take the request as it arrives — a VIN and a symptom, a technician's description, or half a number at the counter.
02
Read what the vehicle was built as — model year, build date, plant, option codes and the market it was built for.
Reason
03
Search the catalogue the franchise publishes, and follow each number through its supersession chain to the one in force.
04
Check the build date against mid-year running changes, and the option codes against fitment that depends on a package.
05
Say where the catalogue, the supersession record and the fitment qualifiers do not agree on one number.
Decide
06
Hold any number under a stop-sale, a recall or a do-not-install notice, and name the bulletin that stopped it.
07
Route safety-critical, option-dependent and unresolved fitment to the parts manager or the technician who verifies it.
Out
08
Return candidates ranked, each with the build evidence, the supersession chain and what could not be resolved.
09
Retain what was asked, what was searched, what was returned, what was ordered and what came back off the vehicle.
→Product statement
The agent searches and evidences. Ordering, pricing, stock commitment and the decision that a part fits this vehicle belong to the parts department, and a technician confirms it at the bench.
Example workflow
One parts request, end to end
AgentHuman
1Request receivedA VIN and a symptom from the drive, a technician's request at the bench, or a partial number at the counter
2Vehicle resolved to its buildVIN decoded to model year, build date, plant, option codes and the market the vehicle was built for
3Catalogue searchedThe illustrated group, the fitment qualifiers, the option variants and the links in the supersession chain
4Fitment evidence assembledBuild date against running changes, option codes against variants, stop-sale status, and where sources disagree
No human action required
Stages 1 to 4 run without a person in the loop — the decode, the catalogue search and the supersession walk all finish before anyone opens the ticket, and nothing has been ordered at the end of them.
5DecisionSplits on whether the build data resolves the variant, and on what the part is attached to
Build data resolves the variant
Reaches the counter ready to check and order.
Variant unresolved, or the part is stopped
Held with the doubt named, for a person.
Parts manager
Reads the candidates, the build evidence behind each and what the agent could not resolve, checks the number against the vehicle in front of them, then orders under their own name.
Order · Correct · Send to the technician
Ordered — logged back▼
6Candidates filed against the ticketWritten to the counter ticket or the repair order; no order is placed and no stock is committed here
7Outcome evaluatedWhat the counter changed, what was ordered, what was returned and what came back off the vehicle later
Returns
A part returned, or swapped at the bench, is scored against what the agent proposed.
What should not run autonomously
Human approval stays in control
Outside the boundary — human approval required8 items
Placing an order or committing stock.
Quoting a price, a core charge or availability.
Certifying that a part fits a vehicle.
Releasing a number under an open stop-sale.
Automation boundaryAgent acts unaided
✓Decode the VIN to the build recorded against that vehicle.
✓Walk each supersession chain to the number in force today.
✓Check build date, option codes and market against the fitment record.
✓Name what is unresolved and where two catalogue sources disagree.
The agent writes candidates to the ticket, never to the order. A named person orders, and a technician confirms the fit.
Substituting a non-genuine or will-fit part.
Deciding that a recall or campaign applies.
Clearing a safety-critical part without a technician.
Changing catalogue precedence or supersession overrides.
Example output
One parts request, annotated
Everything the agent proposes is attached to the build it was read from and the catalogue entry behind it.
Lookup output · one counter requestIllustrative example
Technician asked
Came from
Decoded to
Returned
Confidence
Fitment
Front pads, judder under braking
A repair order at the bench
One VIN, one build date
Two candidates, one held
87%
Confirmed at the bench
As receivedThe request as the technician wrote it and the VIN it arrived against — nothing on this side is inferred.
Evidence usedBuild date and option codeSupersession chain walkedOpen stop-sale check
Why one was heldA stop-sale is open on the second number. The hold is on every tier, not an upsell.
ActionOrderCorrectSend to the technician
What the score decidesConfidence ranks what the counter checks first. It never decides that a part fits.
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 parts requestCounter, bench or the service drive
03Search & evidence
Search what this VIN was built as
Use the build record, the option codes, the market, the supersession chain and the fitment qualifiers the catalogue carries against that vehicle.
01Approved path
Put the evidence beside the number
The build date, the option code and the chain that led to the number arrive with the candidate, instead of being reconstructed across three catalogue screens.
02Human review
Say plainly what is unresolved
Where the sources contradict each other, where the option code is missing and where the part is safety-critical, the request waits for the person who verifies it.
04Build an evidence trail
Retain the request, the build decoded, the sources searched, the candidates returned, the stop-sale check, what was ordered and what came back — on both paths.
Integrations
Typical integrations
Five system groups connect to the same agent. Which of them are in scope is decided in discovery.
Parts cataloguesOEM catalogue · illustrated groups Interchange · aftermarket fitment data
Vehicle build dataVIN decode · option and build codes Factory build records · in-service data
DMS & parts inventoryCDK Global · Reynolds Tekion · Parts stock, orders and returns
Agent
Parts lookup & fitment
Decodes the build Walks supersessions Holds stopped numbers
Integration availability depends on the client's existing systems and API access.
Agent controls
Six layers between the model and the part you fit
Each control wraps the one inside it. A candidate clears every layer before the counter reads it, and the order itself sits outside all six.
L6 · Outermost — last line of defenceInward → L1 · closest to the model
L6Rollback / safe modeReturn lookup to your existing catalogue process if evaluations or return signals degrade.Roll back
L5TraceabilityRecord the request, the build decoded, the sources read, the candidates and what was fitted.Record
L4Fitment approvalA safety-critical or option-dependent number is confirmed by a named person before anything is ordered.Gate
L3Stop-sale holdNumbers are screened against the stop-sale, recall and do-not-install notices you connect.Hold
L2Supersession walkEach number is followed to the one in force today, and the chain is shown rather than summarised.Resolve
L1Build-data gateNo candidate is offered until the VIN resolves to a build the catalogue recognises.Verify
Model coreCandidates proposed — the numbers, the build evidence behind each, what is unresolved and confidence
L1 – L2Decide which numbers may be offered at all
L3Holds a number nobody may fit today
L4 – L5Leave the fitment call with a person, trail kept
L6Pulls automation back when signals degrade
How Nestack evaluates it
Evaluate the whole lookup — not only the number at the top.
Coverage runs the whole depth of the workflow, and every layer is cut by slice.
Surface — the candidate list the counter opens
Depth of coverage ▼
E1Final-output evaluationWas the number the counter ordered the one that fitted?
E2Step-level evaluationDid it read the right build date, option codes and market?
E3Tool evaluationDid it search the right catalogue and follow the chain to its end?
E4Stopped-number recallDid a stopped, recalled or superseded number reach the counter?
E5Slice evaluationHow does accuracy change across build, system and franchise?
E6Business outcomeWhat was returned, refitted, or came back off the vehicle?
Floor — the part that stayed on the vehicle
Failure modes
Where each failure originates in the agent
Seven failure modes plotted against the five stages of the agent lifecycle. None of them orders a part — the stop-sale hold, the counter's own check and the technician's verification at the bench are the controls that stop them.
Agent lifecycleDirection of processing →
01 · Build decode2 modes
PF-01
Built after the running change
The build date is ignored and the model year answers instead.
PF-02
Option code not in the build
A package-dependent variant is inferred from the trim name.
Stage resolvesThe VIN, the build date, the option codes and the market
02 · Catalogue search2 modes
PF-03
Two catalogue sources disagree
Two sources give two numbers and the conflict is dropped.
PF-04
No fitment published yet
A new build is not covered by the illustrated group.
Stage searchesThe illustrated group, the qualifiers and the interchange
03 · Supersession1 mode
PF-05
Chain stops one link early
A number replaced twice is offered as the current one.
Stage followsEach number through to the one in force today
04 · Output1 mode
PF-06
Stopped number reaches the counter
The stop-sale was posted after the last catalogue sync.
Stage returnsThe candidates the counter reads and orders from
05 · Change / Version1 mode
PF-07
One number splits into two
A bulletin re-splits a part and open tickets are not re-checked.
Stage tracksModel, catalogue, bulletin and stop-sale changes
Sev-1 · the wrong part goes on a vehicleSev-2 · the counter is pointed at the wrong variantSev-3 · the request stalls and is worked by hand
March and August builds can share a model year and still take different parts. The builds that moved mid-year, and the variants an option package decides, carry most of the wrong numbers. Nestack reports accuracy by slice, not only in total.
Slice performance — reported separately, not only in aggregateIllustrative example
Slice
Failure rate
Lift
Lift vs. threshold
Status
Mid-year running-change builds
5.2%
2.6×
Review
Option-dependent brake variants
4.3%
2.2×
Review
Long supersession chains
3.5%
1.8×
Watch
Routine service consumables
1.2%
0.6×
Normal
Bar: wrong-number rate lift vs. routine-consumable baseline · scale 0–4.0× · tick at 2.0×2 of 4 slices over threshold
Evidence-linked improvement
A part that came back off the car is a test case
A return, or a number swapped at the bench, is not a counter mistake to absorb. It changes the build rules, the supersession walk or the source we trust.
Improvement cycle · five stagesSwitchback — the path turns at Improve and returns at Learn
01Detect
Returns, refits or a wrong-number report move in a cohort.
02Diagnose
The build decode, source precedence, the supersession walk, the option qualifier and the stop-sale sync are each ruled in or out.
03Improve
Precedence and qualifier rules change under your parts department's change control, with a named approver.
04Verify
Re-run on stored requests from that build, system and franchise, including the ones that came back.
05Learn
The returned number becomes a standing check, and the reason enters your parts department's own notes.
Learn → DetectThe return edge. The next request is searched against one more conflict your counter has already resolved the hard way.
Typical build scope
Twelve workstreams across six weeks
The build scope read against the delivery timeline. Week structure follows the six-week plan — discovery, build data and catalogues, matching and holds, evaluation, integration, then supervised lookup and handover.
WorkstreamWeek 1Week 2Week 3Week 4Week 5Week 6
01Parts-lookup discovery and boundaries.
02VIN decode and build-record access.
03Catalogue, interchange and source precedence.
04Supersession chain and obsolescence rules.
05Option-code and running-change qualifiers.
06Symptom and partial-number matching.
07Stop-sale, recall and hold checks.
08Safety-critical routing to the technician.
09Evaluation suite, slices and return replay.
10Candidate write-back to the counter ticket.
11Catalogue-conflict reporting and escalation.
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 franchise, one catalogueProductionProduction DMS and catalogue integrationAdvancedMulti-rooftop / multi-franchise
Introduced at Pilot
Candidates with VIN build-record evidence✓✓✓
Supersession chains walked and shown✓✓✓
Option-code and running-change qualifiers✓✓✓
Stop-sale, recall and hold checks✓✓✓
Ordering and fitting stay with your people✓✓✓
Catalogue-conflict reporting✓✓✓
Introduced at Production
Multiple catalogues in one lookup—✓✓
Candidate write-back to the counter ticket—✓✓
Observability and evaluation—✓✓
Introduced at Advanced
Aftermarket and interchange sources——✓
Multi-rooftop and multi-franchise controls——✓
Build priceFrom $5,000From $8,000Custom quote
Final build priceConfirmed after discovery based on franchises and catalogues in scope, DMS and build-data access, request volume, safety-critical 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
01The catalogues you hold and the interchange sources you trust→Catalogue, interchange and source precedenceWeek 1
02How you reach build data and VIN decode for the makes you carry→VIN decode and build-record accessWeek 2
03Your supersession, obsolescence and substitution rules→Supersession chain and obsolescence rulesWeek 2
04Where stop-sale, recall and hold notices reach your parts department→Stop-sale, recall and hold checksWeek 3
05Which parts a technician must verify before anything is ordered→Safety-critical routing to the technicianWeek 4
06A year of returns and the counter tickets that produced them→Evaluation suite, return replay and failure-mode testingWeek 4
07Named parts staff and a technician to check what is proposed→Counter write-back, then supervised lookupWeeks 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 conflict reporting and the first lookups your counter orders from.
PhaseW1W2W3W4W5W6
DiscoveryW1
BuildW2 – W3
EvaluateW4 – W5
Pilot & LaunchW5 – W6
Week focusW1Parts-lookup discovery, catalogue sources and source precedenceW2Build-record access, VIN decode and supersession rulesW3Symptom matching, option qualifiers and stop-sale checksW4Evaluation suite, return replay and safety-critical routingW5Counter write-back, conflict reporting and the first supervised lookupsW6Your counter orders from the candidate list, then Agent Care starts
Reading the bandStop-sale and hold checks are built in week 3, before any candidate reaches a counter in week 5. A number nobody may fit should never be offered in the first place.
At the end of W6Your counter has been ordering from candidate lists beside its own catalogue searches, with every part fitted logged against the number that was proposed for it.
DurationSix-week plan shown · typical delivery 4–6 weeks depending on scope confirmed in discovery.
Next step · Automotive AI agent
Build a parts-lookup agent around your own catalogues.
Show us a month of counter tickets and the returns behind them — the VINs, the numbers ordered and the ones that came back. We'll search the same requests against your catalogues and mark every wrong number the build data would have caught first.
