Ground every request in the asset it names, classify it against the severity scheme your own estate runs, and hand anything touching life safety to a named person.
2Request context assembledThe fault described, the asset it points at, the building it sits in and the scheme it is read against
3Routing proposal draftedThe request, the asset, the severity class and completeness
4Controls appliedAsset-match checks, severity checks, duplicate checks and routing confidence
No human action required
Stages 1 to 4 run unaided, and nothing is dispatched at any of them — the agent is triaging, and the facilities lane opens at the completeness gate.
5DecisionSplits at the completeness gate
Routing sufficient
Goes to the facilities manager to dispatch.
Anything unmatched
Adds a facilities coordinator read first.
Facilities review
The request is held with its asset, its severity class and the wording it was read on.
Dispatch · Append evidence · Send to facilities
Dispatched — by the facilities manager▼
6Work order and asset records updatedOnly where write access and records policy allow it
7Outcome evaluatedRouting accuracy, severity coverage, coordinator corrections and what the review found
Corrections
Each coordinator correction is counted in the evaluation.
What should not run autonomously
Human approval stays in control
Outside the boundary — human approval required8 items
Dispatching a trade into an occupied building.
Setting the severity a request is run under.
Closing a ticket on behalf of a trade.
Calling a reported fault resolved without looking.
Automation boundaryAgent acts unaided
✓Tie each request to one asset in the register before it.
✓Classify against the severity scheme your own estate.
✓Show the wording a class was read on, beside the class itself.
✓Chase the trade that accepted, and escalate on the rules you set.
Nothing is dispatched or closed except by a named person, inside the agreed boundaries.
Judging whether a fault is what it was reported as.
Telling an occupant when a trade will attend.
Setting the response rules a severity class carries.
Changes to assets, trades or severity schemes.
Example output
One request, annotated
This record is what one request carried between the occupant who raised it and the trade who took it on.
Work order · single requestIllustrative example
Request
Recorded as
Severity
Evidence of record
Confidence
Held for
Door will not latch, Sev-2
Tied to one asset in the register
Fire door, escalated
Occupant report, 3 August 2026
Held undispatched
The facilities manager, by name
As receivedTaken from the occupant report and the asset register — it reaches as far as those sources do.
What the record holdsOccupant reportAsset register entryPrior fault history
Why no dispatch hereWhether a trade attends this door is a facilities call, not a model output.
ActionDispatchAppend evidenceSend to facilities
What the score decidesBelow the configured threshold a request picks up a coordinator read before dispatch.
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 requestFrom the occupant who raises it
03Evidence
Where the evidence is used
Our maintenance triage agent works tenant repairs against a statutory clock for a property manager; here there is no tenant and no statute, and the discipline is routing and severity.
01Approved path
The ticket is not the fault
A ticket records what somebody reported and what was done about it; whether the fault has gone is settled by a person who looked, never by a status field.
02Human review
What was checked, and not found
No statute was located that fixes how an internal facilities request must be classified, how quickly a trade must attend or when a work order may be closed, and none is claimed here: the severity scheme, the response rules and the closure test are all set by the customer.
04Build an evidence trail
The request, the asset it names and the trade who accepted it stay on the ticket.
Integrations
Typical integrations
Five system groups connect to the same agent. Which of them are in scope is decided in discovery.
Request and intake sourcesHelpdesk · occupant portal Occupant and sensor reports
Asset and space registerCAFM · asset register Asset records and locations
Trades and contractorsTrade rota · contracts Trade and coverage records
Agent
Facilities request triage
Reads the request Routes to the trade Holds for the manager
Work order systemsCMMS · ticketing Ticket and closure records
Integration availability depends on the client's existing systems and API access.
Agent controls
Six hurdles between the model and the manager
Six hurdles set in line, the tallest at the end. Whatever clears them all is named in the map below.
L6 · Outermost — last line of defenceInward → L1 · closest to the model
L6Rollback / safe modeNarrow the agent to request triage when evaluation or production signals degrade.Roll back
L5Version monitoringTrack model, prompt and severity rules; changing what a class requires changes who a request reaches.Track
L4TraceabilityRecord each request, the asset behind it, the class it ran under and every read of that ticket.Record
L3Manager dispatchHold the work order for a named facilities manager; the hold governs dispatch, not whether the fault is real.Gate
L2Severity guardrailsTest each request against the severity scheme, the escalation rules and the asset register your estate runs; life safety goes to a person.Restrict
L1Confidence thresholdsRoute a weak asset match to a coordinator read before anybody is asked to send a trade out.Require review
Model coreRequest triaged — the asset, the severity class, the routing and completeness
L1 – L2Test whether a routing may stand
L3Puts the dispatch in a person's hands
L4 – L5Keep the request and the asset behind it
L6Holds the dispatch unmade when signals degrade
How Nestack evaluates it
Evaluate the whole triage — not only the work order that comes out.
Coverage runs the whole depth of the workflow, and every layer is cut by slice.
Surface — the ticket an occupant reads
Depth of coverage ▼
E1Final-output evaluationDid the ticket name the asset the fault actually sits on?
E2Step-level evaluationDid the agent read the right asset, the right scheme and a live rota?
E3Tool evaluationDid it read and write the correct asset record and the correct ticket?
E4Confidence calibrationDo weak asset matches actually attract more coordinator corrections?
E5Slice evaluationHow does performance change across specific asset classes?
E6Business outcomeHow many requests needed a correction before a trade was sent?
Floor — the estate the occupier answers for
Failure modes
Where each failure originates in the agent
Seven failure modes, each named where in the run it first shows up.
Agent lifecycleDirection of processing →
01 · Retrieval1 mode
KH-03
Stale register read
The asset record read is not the one now in service.
Stage gathersThe requests, the assets, the trades and the wording
02 · Reasoning2 modes
KH-04
Severity read too low
A life safety fault is routed as a repair.
KH-06
Room taken for the asset
A ticket names a place and no equipment.
Stage proposesThe requests, their severity and completeness
03 · Tool / write2 modes
KH-02
Weak match passed forward
A request moves on without the coordinator read.
KH-05
Repeat report suppressed
A recurring fault is merged away unseen.
Stage writesOnly where write access and approval policy allow it
04 · Output1 mode
KH-01
Dispatched, asset unrecorded
A dispatch sits on the record with no asset behind it.
Stage returnsThe work order a trade reads and a manager owns
05 · Change / Version1 mode
KH-07
Silent severity regression
A configuration change moves the class, not the routing.
Stage tracksModel, prompt, severity rules and ticket fields
Sev-1 · a fire door routed as a light fittingSev-2 · wrong asset reaches the work orderSev-3 · source degrades, ticket held unsent
A trade-level routing-accuracy figure can read clean while life safety and fire assets carry most of the rework. Nestack reports the correction rate by asset class, not only in total.
Slice performance — reported separately, not only in aggregateIllustrative example
Slice
Failure rate
Lift
Lift vs. threshold
Status
Life safety and fire assets
10.2%
3.7×
Review
Mechanical and plant assets
7.3%
2.6×
Review
Electrical and lighting assets
4.5%
1.6×
Watch
Fabric and fittings
2.2%
0.8×
Normal
Bar: correction-rate lift vs. fabric and fittings baseline · scale 0–4.0× · tick marks the 2.0× review threshold2 of 4 slices over threshold
Evidence-linked improvement
What a wrong severity costs
The loop shuts when the misrouted safety request is a regression case. That suite is what the next ticket triaged is measured against.
Improvement cycle · five stagesSwitchback — the path turns at Improve and returns at Learn
01Detect
Correction rate rises on life safety and fire assets.
02Diagnose
The request that read like a light fitting and was actually a fire door is read back until one cause remains.
03Improve
Any change goes out numbered, with the requests that caused it attached.
04Verify
One request case still failing is enough to hold the release back.
05Learn
One case joins the suite, one line joins the triage record.
Learn → DetectThe return edge. The next request is measured against a suite 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, sources, request triage, evaluation, integration, then production validation and handover.
WorkstreamWeek 1Week 2Week 3Week 4Week 5Week 6
01Severity-scheme and automation-boundary discovery.
02Occupant, asset and trade sources.
03Request-to-asset and severity-routing rule mapping.
04Request and asset ingestion.
05Request, asset and trade binding.
06Severity scoring and review routing.
07Manager dispatch workflow.
08Work-order system integration.
09Routing and severity cases.
10Guardrails and dispatch controls.
11Ticket-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 site, one yearProductionProduction triage workflowAdvancedMultiple sites / estates
Introduced at Pilot
Triage to your severity scheme✓✓✓
Facilities manager release✓✓✓
Asset-register baseline✓✓✓
Introduced at Production
Reporting by trade—✓✓
Dispatch workflow in your systems—✓✓
Approved write-back—✓✓
Work-order-system integration—✓✓
Introduced at Advanced
Multi-site severity schemes——✓
Cross-site escalation packs——✓
Large request volumes——✓
Multi-site severity controls——✓
Build priceFrom $5,000From $8,000Custom quote
Final build priceConfirmed after discovery based on integrations, workflow complexity, request 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 severity scheme and what each class requires→Scheme mapping and request captureWeek 1
02Representative occupant, asset and trade records→Record binding, severity logic and the routing baselineWeek 2
03Your escalation rules and who may override one→Severity mapping, asset binding and the automation boundaryWeek 1
04Access to relevant APIs, feeds or exports→Occupant, asset and trade-source assessment, then integration setupWeek 2
05Tickets you would not want reviewed→Severity cases and failure-mode testingWeek 4
06What no request record may prove→Severity scoring, review routing, guardrails and release controlsWeek 3
07A named facilities manager to dispatch→Dispatch 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
What each bar spans is working time and not layout, so the fifth week has to carry two of them.
PhaseW1W2W3W4W5W6
DiscoveryW1
BuildW2 – W3
EvaluateW4 – W5
Pilot & LaunchW5 – W6
Week focusW1Triage workflow discovery, severity mapping and the automation boundaryW2Source integration and the request-routing baselineW3Request triage, severity logic and release controlsW4Evaluation suite, routing cases and failure-mode testingW5Work-order integration, pilot requests and targeted correctionsW6One maintenance season run under the facilities manager, then Agent Care handover
Reading the bandEach bar spans only the weeks its own work is named for. Two land together on the fifth because the work does.
At the end of W6Once the ticket record validates, Agent Care assumes the agent.
DurationSix-week plan shown · typical delivery 4–6 weeks depending on scope confirmed in discovery.
Next step · Facilities AI agent
Build a triage agent around the request that named a room when the fault sat on an asset.
Show us one request and the asset it was tied to. Who settles that a request touching a fire door leaves the queue for a person — your own severity scheme does, and the agent shows the wording it classified on rather than the class alone.
