Main site

Facilities AI agent · Request triage

Facilities Request Triage AI Agent

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.

Typical delivery
4–6 weeks
Deployment
Your stack
Person decides
Severity shown
After launch
Agent Care

What this agent does

Routes the request, never dispatches the trade

In

  1. 01

    A request arrives, and what an occupant describes is a symptom; the fault behind it is still to be found.

  2. 02

    An asset is named, and a request nobody can tie to the register is incomplete rather than urgent.

Reason

  1. 03

    A class is set against your own scheme, and the agent shows the wording it read alongside what it decided.

  2. 04

    A request touches life safety, security or access control, and it leaves the queue for a person.

  3. 05

    A trade accepts, and that acceptance belongs on the trade record; what an occupant hears is written apart.

Decide

  1. 06

    A repeat lands, and one fault reported three times over is a finding about the asset, not noise to bury.

  2. 07

    A ticket ages, and the agent chases and escalates on your rules while closing nothing for anybody else.

Out

  1. 08

    A job is called done, and nothing is marked resolved that the agent did not itself observe resolved.

  2. 09

    Execute write actions only inside the approval boundaries agreed during implementation.

Product statement

The agent classifies, routes, chases and escalates. A named person dispatches the trade, accepts the work and closes the ticket.

Example workflow

One request, intake to dispatch

  1. 1Request evidence receivedOccupant reports, helpdesk calls, sensor alerts or inspection notes
  2. 2Request context assembledThe fault described, the asset it points at, the building it sits in and the scheme it is read against
  3. 3Routing proposal draftedThe request, the asset, the severity class and completeness
  4. 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

  1. 6Work order and asset records updatedOnly where write access and records policy allow it
  2. 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 required

8 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 boundary

    Agent 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 request

Illustrative example
Request
Door will not latch, Sev-2
Recorded as
Tied to one asset in the register
Severity
Fire door, escalated
Evidence of record
Occupant report, 3 August 2026
Confidence
Held undispatched
Held for
The facilities manager, by name

As received

Taken from the occupant report and the asset register — it reaches as far as those sources do.

What the record holds

  • Occupant report
  • Asset register entry
  • Prior fault history

Why no dispatch here

Whether a trade attends this door is a facilities call, not a model output.

What the score decides

Below the configured threshold a request picks up a coordinator read before dispatch.

Action

DispatchAppend evidenceSend to facilities

Value

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 request

From 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.

04

Build 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 sources

    • Helpdesk
    • occupant portal
    • Occupant and sensor reports

  • Asset and space register

    • CAFM
    • asset register
    • Asset records and locations

  • Trades and contractors

    • Trade rota
    • contracts
    • Trade and coverage records

Agent

Facilities request triage

  • Reads the request
  • Routes to the trade
  • Holds for the manager

  • Work order systems

    • CMMS
    • ticketing
    • Ticket and closure records

  • Observability & evaluation

    • OpenTelemetry
    • Langfuse
    • Supported monitoring/evaluation sources

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 defence

Inward → 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 – L2
Test whether a routing may stand
L3
Puts the dispatch in a person's hands
L4 – L5
Keep the request and the asset behind it
L6
Holds 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

  1. E1Final-output evaluationDid the ticket name the asset the fault actually sits on?
  2. E2Step-level evaluationDid the agent read the right asset, the right scheme and a live rota?
  3. E3Tool evaluationDid it read and write the correct asset record and the correct ticket?
  4. E4Confidence calibrationDo weak asset matches actually attract more coordinator corrections?
  5. E5Slice evaluationHow does performance change across specific asset classes?
  6. 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 lifecycle

Direction of processing →

  1. 01 · Retrieval

    1 mode

    • KH-03

      Stale register read

      The asset record read is not the one now in service.

    Stage gathers

    The requests, the assets, the trades and the wording

  2. 02 · Reasoning

    2 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 proposes

    The requests, their severity and completeness

  3. 03 · Tool / write

    2 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 writes

    Only where write access and approval policy allow it

  4. 04 · Output

    1 mode

    • KH-01

      Dispatched, asset unrecorded

      A dispatch sits on the record with no asset behind it.

    Stage returns

    The work order a trade reads and a manager owns

  5. 05 · Change / Version

    1 mode

    • KH-07

      Silent severity regression

      A configuration change moves the class, not the routing.

    Stage tracks

    Model, prompt, severity rules and ticket fields

  • Sev-1 · a fire door routed as a light fitting
  • Sev-2 · wrong asset reaches the work order
  • Sev-3 · source degrades, ticket held unsent
See the complete Facilities failure-mode catalogue

Affected slices

Life safety work absorbs the corrections

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 aggregate

Illustrative example
SliceFailure rateLiftLift vs. thresholdStatus
Life safety and fire assets10.2%3.7×Review
Mechanical and plant assets7.3%2.6×Review
Electrical and lighting assets4.5%1.6×Watch
Fabric and fittings2.2%0.8×Normal

Bar: correction-rate lift vs. fabric and fittings baseline · scale 0–4.0× · tick marks the 2.0× review threshold

2 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 stages

Switchback — the path turns at Improve and returns at Learn

  1. 01

    Detect

    Correction rate rises on life safety and fire assets.

  2. 02

    Diagnose

    The request that read like a light fitting and was actually a fire door is read back until one cause remains.

  3. 03

    Improve

    Any change goes out numbered, with the requests that caused it attached.

  4. 04

    Verify

    One request case still failing is enough to hold the release back.

  5. 05

    Learn

    One case joins the suite, one line joins the triage record.

  6. Learn → Detect

    The 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.

Workstream

Week 1Week 2Week 3Week 4Week 5Week 6

  1. 01Severity-scheme and automation-boundary discovery.Week 1
  2. 02Occupant, asset and trade sources.Week 1, Week 2
  3. 03Request-to-asset and severity-routing rule mapping.Week 1, Week 2
  4. 04Request and asset ingestion.Week 2
  5. 05Request, asset and trade binding.Week 2, Week 3
  6. 06Severity scoring and review routing.Week 3
  7. 07Manager dispatch workflow.Week 3, Week 4
  8. 08Work-order system integration.Week 5
  9. 09Routing and severity cases.Week 4, Week 5
  10. 10Guardrails and dispatch controls.Week 4
  11. 11Ticket-trail instrumentation.Week 5, Week 6
  12. 12Deployment, documentation 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 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 price
Confirmed after discovery based on integrations, workflow complexity, request volume, approval controls 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.

  1. 01Your severity scheme and what each class requires

    Scheme mapping and request capture

    Week 1

  2. 02Representative occupant, asset and trade records

    Record binding, severity logic and the routing baseline

    Week 2

  3. 03Your escalation rules and who may override one

    Severity mapping, asset binding and the automation boundary

    Week 1

  4. 04Access to relevant APIs, feeds or exports

    Occupant, asset and trade-source assessment, then integration setup

    Week 2

  5. 05Tickets you would not want reviewed

    Severity cases and failure-mode testing

    Week 4

  6. 06What no request record may prove

    Severity scoring, review routing, guardrails and release controls

    Week 3

  7. 07A named facilities manager to dispatch

    Dispatch workflow, then pilot and production validation

    Weeks 5–6

Nothing else is required

Deployment, 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.

Phase

W1

W2

W3

W4

W5

W6

  1. DiscoveryW1
  2. BuildW2 – W3
  3. EvaluateW4 – W5
  4. Pilot & LaunchW5 – W6

Week focus

W1Triage workflow discovery, severity mapping and the automation boundary

W2Source integration and the request-routing baseline

W3Request triage, severity logic and release controls

W4Evaluation suite, routing cases and failure-mode testing

W5Work-order integration, pilot requests and targeted corrections

W6One maintenance season run under the facilities manager, then Agent Care handover

Reading the band
Each 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 W6
Once the ticket record validates, Agent Care assumes the agent.
Duration
Six-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.

Typical delivery
4–6 weeks
Deployment
Your asset register
Person decides
Severity shown
After launch
Agent Care available

Nestack Agents · Facilities request triage

AGT-AF-03 · Agent Care available after launch

Build a triage agent

Four questions so the call starts from your actual setup — then pick a time that suits you.

About you
Your requests

No obligation. We’ll map the workflow, name the automation boundary and tell you if an agent is the wrong answer.