Facilities AI agent · Room and resource booking
Room & Resource Booking AI Agent
Surface the bookings still holding a room nobody walked into, weigh each against the precedence rules your estate has set, and leave the release to the named person whose policy permits it.
- Typical delivery
- 4–6 weeks
- Deployment
- Your stack
- Sensors advise
- Policy releases
- After launch
- Agent Care
What this agent does
Proposes the release, never takes the room back
In
- 01
A request is made, and the agent reads what is genuinely free rather than what a calendar merely shows free.
- 02
A booking is confirmed, and it stands as a claim on a shared resource rather than a promise to the booker.
Reason
- 03
A booking lapses, and the agent proposes a release under a policy a named person already owns and can defend.
- 04
A sensor reads a room as empty, and that reading is evidence towards release and never the release itself.
- 05
A resource is held as a workplace adjustment, and it leaves the automatic list without a reason ever shown.
Decide
- 06
A precedence rule bites, and the order applied is the one your estate set, visible on the record, never invented.
- 07
A calendar would need editing, and the agent writes nothing outside the boundary agreed at implementation.
Out
- 08
A release is taken, and the record carries the rule, the evidence and the person whose policy allowed it.
- 09
Execute write actions only inside the approval boundaries agreed during implementation.
Product statement
The agent proposes releases and applies the precedence rules as configured. A named workplace lead owns the release policy and settles every contested claim.
Example workflow
One booking, request to release
- 1Booking evidence receivedBooking requests, calendar feeds, check-in records or occupancy signals
- 2Booking context assembledThe resource, the building it stands in, the class it belongs to and the rules that class carries
- 3Release proposal draftedThe booking, the signals against it, the rule it would fall under and completeness
- 4Controls appliedPrecedence checks, adjustment-exclusion checks, signal checks and release confidence
No human action required
Stages 1 to 4 run unaided, and nothing is given back at any of them — the agent is proposing, and the workplace lane opens at the completeness gate.
Goes to the workplace lead to release.
Adds a workplace coordinator read first.
Workplace review
The booking is held with its rule, its signals and the resource it would give back.
Release · Append evidence · Send to workplace
Released — by the workplace lead
- 6Booking and resource records updatedOnly where write access and records policy allow it
- 7Outcome evaluatedRelease accuracy, rule coverage, coordinator corrections and what the review found
Corrections
Each workplace correction is counted in the evaluation.
What should not run autonomously
Human approval stays in control
Outside the boundary — human approval required
8 items
- Releasing a room on sensor data alone.
- Setting the precedence order between claims.
- Editing a calendar outside the agreed boundary.
- Naming why an adjustment booking is excluded.
Automation boundary
Agent acts unaided
- ✓Read every claim against the resource it now holds.
- ✓Propose a release only under a policy a named person already owns.
- ✓Keep adjustment bookings out of the automatic release.
- ✓Show the precedence rule that was applied and the claim it favoured.
Nothing is released or overridden except by a named person, inside the agreed boundaries.
- Judging whether a room was genuinely unused.
- Telling a booker their claim outranks another.
- Setting which resources a class may reach.
- Changes to policy, classes or release rules.
Example output
One booking, annotated
Our visitor agent works a lobby and admits nobody by itself; this record is what one booking on one morning held.
Booking record · single claim
Illustrative example- Booking
- Meeting room, half day
- Recorded as
- Proposed for release, not confirmed
- Class
- Meeting room, half day
- Evidence of record
- Check-in window, 3 August 2026
- Confidence
- Held unreleased
- Held for
- The workplace lead, by name
As received
Drawn from the booking system and the check-in record — it reaches no further than those sources do.
What the record holds
- Booking request
- Check-in record
- Release proposal
Why no release here
A contested claim is settled under your policy, and never by a model output.
What the score decides
A proposal under the configured threshold collects a coordinator read before it moves.
Action
ReleaseAppend evidenceSend to workplaceValue
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 booking
From the resource it holds
Where the evidence is used
A booking trail shows who claimed a resource and who gave it back; it says nothing about whether the room suited the meeting, and no utilisation study is offered here.
A room is not a promise
A confirmed booking is a claim on shared capacity, and the release rules that govern it belong to the customer, applied visibly and never widened by the agent.
What was checked, and not found
Nothing was found in law that fixes when a held resource must be handed back, what an occupancy signal may be relied on for, or how long a booking trail is kept: the release policy, the signal rule and the retention period are all set by you, not by us.
Build an evidence trail
The booking, the resource it holds and the person who released it stay together.
Integrations
Typical integrations
Five system groups connect to the same agent. Which of them are in scope is decided in discovery.
Booking and calendar sources
- Room booking
- calendars
- Desk and resource requests
Occupancy signals
- Sensors
- check-in panels
- Room and desk presence
People and buildings
- HR system
- floor plans
- Team, site and class records
Agent
Room and resource booking
- Reads the claim
- Proposes the release
- Holds for the lead
Workplace case systems
- Service desk
- ticketing
- Release and dispute records
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 lead
Six layers stacked, each tighter than the one before. What reaches the floor is set out in the map below.
L6 · Outermost — last line of defence
Inward → L1 · closest to the model
- L1 – L2
- Test whether a release may stand
- L3
- Puts the release in a person's hands
- L4 – L5
- Keep the booking and the resource behind it
- L6
- Retreats to proposal only when signals degrade
How Nestack evaluates it
Evaluate the whole proposal — not only the release that comes out.
Coverage runs the whole depth of the workflow, and every layer is cut by slice.
Surface — the release a booker sees
- E1Final-output evaluationDid the release match the rule its class actually carries?
- E2Step-level evaluationDid the agent read the right booking, the right class and a live signal?
- E3Tool evaluationDid it read and write the correct booking record and the correct resource?
- E4Confidence calibrationDo thin proposals actually attract more coordinator corrections?
- E5Slice evaluationHow does performance change across specific resource classes?
- E6Business outcomeHow many proposals needed a correction before anything was given back?
Floor — the estate the workplace answers for
Failure modes
Where each failure originates in the agent
Seven failure modes, each placed at the stage where it first shows itself.
Agent lifecycle
Direction of processing →
01 · Retrieval
1 mode
- KG-03
Stale availability read
The availability read is not the one now in force.
Stage gathers
The bookings, the rooms, the rules and the signals
02 · Reasoning
2 modes
- KG-04
Release called too early
A booking is released before its notice runs.
- KG-06
Sensor reading taken as proof
An empty-looking room is worked as a vacated one.
Stage proposes
The bookings, their rules and completeness
03 · Tool / write
2 modes
- KG-02
Thin proposal passed forward
A proposal moves on without the coordinator read.
- KG-05
Bound to the wrong resource
A release is filed against a room nobody claimed.
Stage writes
Only where write access and approval policy allow it
04 · Output
1 mode
- KG-01
Released, rule unrecorded
The record shows a release but not what permitted it.
Stage returns
The release a lead takes and the record it leaves
05 · Change / Version
1 mode
- KG-07
Silent rule regression
A configuration change moves the rule, not the record.
Stage tracks
Model, prompt, release rules and booking fields
- Sev-1 · a room released on a sensor alone
- Sev-2 · an adjustment booking auto-released
- Sev-3 · signals degrade, proposal held back
Affected slices
Meeting rooms absorb the corrections
A resource-level release-accuracy figure can read clean while shared meeting rooms carry most of the rework. Nestack reports the correction rate by resource class, not only in total.
Slice performance — reported separately, not only in aggregate
Illustrative example| Slice | Failure rate | Lift | Lift vs. threshold | Status |
|---|---|---|---|---|
| Shared meeting rooms | 10.7% | 3.7× | Review | |
| Bookable desks and benches | 7.6% | 2.6× | Review | |
| Specialist and lab spaces | 4.7% | 1.6× | Watch | |
| Open collaboration areas | 1.9% | 0.6× | Normal |
Bar: correction-rate lift vs. open-area baseline · scale 0–4.0× · tick marks the 2.0× review threshold
2 of 4 slices over threshold
Evidence-linked improvement
What a ghost booking costs
A loop ends when the ghost booking has become a case the next release must pass. That suite is what the next request placed is measured against.
Improvement cycle · five stages
Switchback — the path turns at Improve and returns at Learn
- 01
Detect
Correction rate rises on shared meeting rooms.
- 02
Diagnose
The booking nobody cancelled and nobody used, on the day the floor ran out, is read back until one cause remains.
- 03
Improve
Number the change; the bookings that drove it are filed underneath it.
- 04
Verify
Each touched booking case is run once more, and one red holds it back.
- 05
Learn
It stays on as a standing test, and the release rules move alongside it.
Learn → Detect
The return edge. The next release 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, release proposals, evaluation, integration, then production validation and handover.
Workstream
Week 1Week 2Week 3Week 4Week 5Week 6
- 01Resource-class and automation-boundary discovery.Week 1
- 02Booking, calendar and occupancy sources.Week 1, Week 2
- 03Booking-to-resource and precedence-rule mapping.Week 1, Week 2
- 04Booking and occupancy ingestion.Week 2
- 05Booking, resource and class binding.Week 2, Week 3
- 06Release scoring and review routing.Week 3
- 07Workplace lead release workflow.Week 3, Week 4
- 08Calendar-system integration.Week 5
- 09Conflict and release cases.Week 4, Week 5
- 10Guardrails and allocation controls.Week 4
- 11Booking-trail instrumentation.Week 5, Week 6
- 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 tier | PilotOne building, one quarter | ProductionProduction booking workflow | AdvancedMultiple buildings / estates |
|---|---|---|---|
| Introduced at Pilot | |||
| Release proposals to your rules | ✓ | ✓ | ✓ |
| Workplace lead release | ✓ | ✓ | ✓ |
| Resource-inventory baseline | ✓ | ✓ | ✓ |
| Introduced at Production | |||
| Reporting by resource class | — | ✓ | ✓ |
| Release workflow in your systems | — | ✓ | ✓ |
| Approved write-back | — | ✓ | ✓ |
| Calendar-system integration | — | ✓ | ✓ |
| Introduced at Advanced | |||
| Multi-building precedence rules | — | — | ✓ |
| Cross-site release packs | — | — | ✓ |
| Large booking volumes | — | — | ✓ |
| Multi-building allocation controls | — | — | ✓ |
| Build price | From $5,000 | From $8,000 | Custom quote |
- Final build price
- Confirmed after discovery based on integrations, workflow complexity, booking 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.
You bring
We build with it
01Your resource classes and what each one permits
→Class mapping and booking capture
Week 102Representative booking, check-in and occupancy records
→Record binding, release logic and the proposal baseline
Week 203Your precedence order and who may change it
→Class mapping, rule binding and the automation boundary
Week 104Access to relevant APIs, feeds or exports
→Booking, calendar and sensor-source assessment, then integration setup
Week 205Bookings you would not want challenged
→Conflict cases and the evaluation run
Week 406What no booking record may settle
→Release scoring, review routing, guardrails and hold controls
Week 307A named workplace lead who releases
→Release 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
The widths are weeks of real work rather than spacing, and that is why one band has to carry two.
Phase
W1
W2
W3
W4
W5
W6
- DiscoveryW1
- BuildW2 – W3
- EvaluateW4 – W5
- Pilot & LaunchW5 – W6
Week focus
W1Booking workflow discovery, class mapping and the automation boundary
W2Source integration and the release-accuracy baseline
W3Release proposals, precedence logic and hold controls
W4Evaluation suite, conflict cases and failure-mode testing
W5Calendar integration, pilot bookings and targeted corrections
W6One booking quarter run under the workplace lead, then Agent Care handover
- Reading the band
- Each bar covers only the weeks its own work is named for. The fifth carries two because the work does.
- At the end of W6
- When the booking record validates, Agent Care takes the agent on.
- Duration
- Six-week plan shown · typical delivery 4–6 weeks depending on scope confirmed in discovery.
Next step · Facilities AI agent
Build a booking agent around the room that was held all morning and entered by nobody.
Show us one booking and the rule it would be released under. A named workplace lead gives a room back, never the agent and never a sensor. If desks, rooms and parking sit in different systems across your estate, then precedence is applied by whoever answers first.
- Typical delivery
- 4–6 weeks
- Deployment
- Your resource classes
- Sensors advise
- Policy releases
- After launch
- Agent Care available
Nestack Agents · Room and resource booking
AGT-AF-02 · Agent Care available after launch