Turn a condition signal or an operator report into a work request with the asset history, the current manual revision and a parts list attached — a planner schedules it, a supervisor authorises it.
Take condition alerts, operator reports, inspection findings and PM due dates from the systems that raise them.
02
Pull that asset's own record — hierarchy position, configuration, past work orders and the manual revision in force.
Reason
03
Trend the signal against the asset's own baseline and mark condition that is drifting, not only condition that alarms.
04
Draft a job plan — task steps, trades, estimated hours and the isolation points the plant's own procedure names.
05
Draft a parts list from the bill of materials as fitted, marking what a rebuild changed since the last job.
Decide
06
Separate a probable instrument fault from a probable asset fault, and say which one the request rests on.
07
Match the fault against open and recently closed work orders on the asset before a second request is raised.
Out
08
Present a draft request with the evidence, the job plan, the parts list and a window production has not committed.
09
Retain the signal, the sources read, the revisions cited and every correction a planner or technician made.
→Product statement
The agent prepares and proposes. A planner schedules the job, a supervisor authorises it, and a technician works under the plant's own isolation and permit procedures.
Example workflow
One work request, end to end
AgentHuman
1Signal receivedA condition alert, an operator report, an inspection finding or a PM falling due
2Asset identifiedHierarchy position, configuration as fitted, criticality, past work orders and the manual revision in force
3Fault characterisedThe signal trended against this asset's own baseline, and the instrument checked before the asset is blamed
4Work preparedDraft job plan, trades and hours, parts against the bill of materials, and the isolation points the procedure names
No human action required
Stages 1 to 4 run without a person in the loop — the signal, the asset record and the draft plan are all assembled before a planner is asked to read anything. Anything safety-related ends that stretch on the spot.
5DecisionSplits on confidence and on whether the fault is duplicated, safety-related or on a critical asset
Routine, single request
Enters the planned backlog with its evidence.
Safety-related, critical or duplicated
Goes to the maintenance supervisor first.
Planner and maintenance supervisor
Reads the evidence, the job plan and the parts list, then plans the job, schedules it against production and authorises the work.
Plan the job · Correct · Reject
Planned — handed back▼
6Request filed for planningWritten to the maintenance system as a request only — not scheduled, not authorised, not closed by the agent
7Outcome evaluatedWhat the technician actually found, the parts actually used, schedule conflicts and the duplicate rate
Corrections
What the planner rewrites in the job plan is counted in the evaluation.
What should not run autonomously
Human approval stays in control
Outside the boundary — human approval required8 items
Authorising work on equipment.
Issuing, transferring or closing a permit to work.
Applying, removing or overriding a lock or tag.
Declaring an asset safe to work on.
Automation boundaryAgent acts unaided
✓Turn a condition signal or an operator report into a draft work request.
✓Attach the asset history, past repairs and the manual revision in force.
✓Draft the job plan and parts list, citing the isolation points the procedure names.
✓Flag drifting condition, probable instrument faults and duplicate requests.
The agent writes the work request and the draft plan. The authorisation, the permit and the lock are not its to write.
Closing a work order as complete.
Committing a job into a production window.
Changing an asset's criticality or PM interval.
Moving an asset to run-to-failure or off monitoring.
Example output
One condition signal, annotated
Everything the agent proposes is attached to the exact asset, work order and manual revision it was read from.
Work-preparation output · one condition signalIllustrative example
Signal source
Asset
Manual revision
Raised as
Confidence
Work authority
Condition system and operator
Pump P-214, criticality B
Rev 4, in force
Draft request — bearing wear
88%
Never the agent
As receivedThe signal, the asset it names and the revision in force at the time — read from the condition system, not inferred.
Evidence usedTrend vs. own baselineTwo prior bearing repairsRev-4 manual, task 6
Why it was raisedThe trend moved on this pump's own baseline, and the transmitter checked out.
ActionPlan the jobCorrectReject
What the score decidesConfidence decides how hard the planner checks, not whether work is authorised.
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 signal and reportCondition system, operator, inspection or PM due
03Prepare & propose
Work from the asset's own record
Use the plant's asset hierarchy, its work-order history, the manual revision in force and the bill of materials as fitted.
01Approved path
Hand the planner a job already prepared
The history, the manual, the past repairs and the parts arrive with the request, so planning starts from evidence rather than a one-line fault report.
02Human review
Send the doubtful ones to a supervisor
Safety-related, critical-asset and duplicated requests reach a maintenance supervisor before they enter the backlog, instead of queuing behind routine work.
04Build an evidence trail
Retain the signal, the sources read, the revisions cited, the parts proposed, the confidence and what the technician actually found — on both paths.
Integrations
Typical integrations
Five system groups connect to the same agent. Which of them are in scope is decided in discovery.
CMMS & EAMSAP PM · IBM Maximo · Infor EAM Oracle eAM · Plant CMMS
Integration availability depends on the client's existing systems and API access.
Agent controls
Six layers between the model and the job
Each control wraps the one inside it. A request clears every layer before a planner sees it, and the authority to work on the equipment sits outside all six.
L6 · Outermost — last line of defenceInward → L1 · closest to the model
L6Rollback / safe modeReturn work requests to your existing route if evaluation signals degrade.Roll back
L5TraceabilityRecord the signal, sources read, revisions cited, parts proposed and every correction.Record
L4Authorisation gateScheduling, authorisation, the permit and the lock stay with the people the procedure names.Gate
L3Duplicate matchOpen and recent work orders on the same asset are matched before a second request.Merge
L2Revision and fitmentNothing is cited from a superseded manual or a part the asset no longer carries.Withhold
L1Instrument checkA signal is tested against its own transmitter before it is blamed on the asset.Verify
Model coreDraft request produced — fault, evidence, job plan, parts list, proposed window and confidence
L1 – L2Keep the request about the right thing
L3Decides whether this is already known
L4 – L5Keep authority with a person, trail intact
L6Pulls automation back when signals degrade
How Nestack evaluates it
Evaluate the whole preparation — not only the request it raises.
Coverage runs the whole depth of the workflow, and every layer is cut by slice.
Surface — the request the planner opens
Depth of coverage ▼
E1Final-output evaluationDid the request name the fault the technician actually found?
E2Step-level evaluationDid it read the right asset, configuration and manual revision?
E3Tool evaluationDoes the request tie back to the exact asset, work order and part?
E4Signal attributionWas the request raised on an asset fault rather than an instrument fault?
E5Slice evaluationHow does accuracy change across asset classes, ages and criticality?
E6Business outcomeHow many were duplicates, and how often did the parts list hold?
Floor — what the technician actually finds
Failure modes
Where each failure originates in the agent
Seven failure modes plotted against the five stages of the agent lifecycle. None of them authorises work — the planner's read, the supervisor's authorisation and the plant's isolation and permit procedures are the controls that stop them. If one gets through and a technician is already at the machine, the asset, the revision and the plan held in the request are what the stop-work and the record correction are built from.
Agent lifecycleDirection of processing →
01 · Retrieval2 modes
MA-01
Sensor fault read as asset fault
A drifting transmitter is written up as a machine fault.
MA-02
History from a sister asset
Repairs from a same-model asset with a different build.
Stage gathersThe signal, the asset record, history and manual
02 · Reasoning2 modes
MA-03
Plan written to an asset that changed
A superseded revision, or a part a rebuild removed.
MA-04
Window production had committed
Preventive work proposed into a slot already sold.
Stage preparesThe fault named, the job plan and the parts list
03 · Request / write1 mode
MA-05
Same fault, two work orders
The alert and the operator report are raised separately.
Stage raisesThe work request written to the maintenance system
04 · Output1 mode
MA-06
Alert volume outruns the technicians
So much is raised that work orders close unread.
Stage presentsThe request, the evidence and the window proposed
05 · Change / Version1 mode
MA-07
Redundancy the criticality misses
A standby asset is ranked as if it stood alone.
Stage tracksModel, threshold, PM-interval and asset changes
Sev-1 · a technician works to a wrong planSev-2 · the asset record cannot be relied onSev-3 · the backlog fills, requests stop being read
A rebuilt asset is not the asset the record describes
Two pumps on a line are not the same problem. An asset with a full history and an unchanged build reads cleanly; one rebuilt, with a manual that never caught up, does not. 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
Rebuilt or modified assets
7.0%
3.5×
Review
Poorly documented old assets
5.2%
2.6×
Review
Operator-reported faults
3.8%
1.9×
Watch
Settled assets, full history
1.4%
0.7×
Normal
Bar: lift in requests that missed the actual fault · scale 0–4.0× · tick marks 2.0×2 of 4 slices over threshold
Evidence-linked improvement
What the technician found goes back into the request
The technician's finding is the answer key. What was actually wrong, which parts were used and what the plan missed come back as cases to get right.
Improvement cycle · five stagesSwitchback — the path turns at Improve and returns at Learn
01Detect
Requests that missed the fault, duplicates or parts-list errors move on an asset class.
02Diagnose
Traced to the signal read, the asset identified, the revision cited or the build assumed.
03Improve
The retrieval rule, plan template or criticality input changes under your change control, with a named approver.
04Verify
Re-run against held-out requests from that class, including the ones the technician overturned.
05Learn
The overturned request is kept as a case and the reason enters the work-management review.
Learn → DetectThe return edge. A change to a PM interval or a criticality rating is an asset-strategy change — your reliability engineer approves it before it ships, not after.
Typical build scope
Twelve workstreams across six weeks
The build scope read against the delivery timeline. Week structure follows the six-week plan — discovery, asset and document access, plan drafting, evaluation, integration, then supervised running and handover.
WorkstreamWeek 1Week 2Week 3Week 4Week 5Week 6
01Work-management discovery and boundaries.
02Asset hierarchy and criticality mapping.
03CMMS, historian and condition-system access.
04Asset, work-order and part identity keys.
05Signal and operator-report ingestion.
06Manual, drawing and bill-of-material retrieval.
07Job-plan and parts-list drafting.
08Instrument-fault and duplicate checks.
09Production-window and schedule-conflict checks.
10Evaluation suite and held-out asset classes.
11Work-request write-back and planner routing.
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 asset class, one lineProductionProduction CMMS integrationAdvancedMulti-plant / multi-system
Introduced at Pilot
Work requests drafted with the evidence✓✓✓
Asset history and past repairs attached✓✓✓
Manual-revision currency checks✓✓✓
Authorisation by a named supervisor✓✓✓
Baseline evaluation✓✓✓
Introduced at Production
Job-plan and parts-list drafting—✓✓
Instrument-fault and duplicate checks—✓✓
Work-request write-back and planner routing—✓✓
Observability and evaluation—✓✓
Introduced at Advanced
Condition-trend and drift flagging——✓
Multi-plant and enterprise controls——✓
Build priceFrom $5,000From $8,000Custom quote
Final build priceConfirmed after discovery based on the asset classes in scope, CMMS, historian and condition-system integrations, document and bill-of-material quality, 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 asset hierarchy and the criticality ratings behind it→Asset hierarchy and criticality mappingWeek 1
02Access to the CMMS, the historian and the condition system→System access assessment, then asset, work-order and part identity keysWeek 2
03OEM manuals, drawing revisions and the bills of material as fitted→Manual, drawing and bill-of-material retrievalWeek 3
04Your standard job plans and the isolation procedures they cite→Job-plan and parts-list draftingWeek 3
05The production windows you protect and how they get committed→Production-window and schedule-conflict checksWeek 4
06Work orders from the last year, with what the technician actually found→Evaluation suite, held-out asset classes and failure-mode testingWeek 4
07A named planner and a maintenance supervisor→Planner routing and write-back, then supervised runningWeeks 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 held-out asset classes and the first requests your planner works from.
PhaseW1W2W3W4W5W6
DiscoveryW1
BuildW2 – W3
EvaluateW4 – W5
Pilot & LaunchW5 – W6
Week focusW1Work-management discovery, asset hierarchy and criticality ratingsW2CMMS, historian and condition-system access, then identity keysW3Manual and bill-of-material retrieval, job-plan and parts-list draftingW4Evaluation suite, instrument-fault checks and production-window conflictsW5Held-out asset classes, first supervised requests and targeted correctionsW6Your planner works from the request, then Agent Care starts
Reading the bandInstrument-fault and duplicate checks are built in week 4 — before any request reaches a planner's backlog in week 5.
At the end of W6Requests have run alongside your existing route and been planned by the planner who schedules from them, then Agent Care takes over monitoring.
DurationSix-week plan shown · typical delivery 4–6 weeks depending on scope confirmed in discovery.
Next step · Manufacturing AI agent
Build a maintenance assistant around your work-management process.
Show us one asset class, its work-order history and the job plans and manuals your planners work from today. We'll prepare requests from your own condition signals and operator reports, then report what the technician actually found against what the agent proposed.
