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.
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
AgentHuman
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.
5DecisionSplits at the completeness gate
Evidence sufficient
Goes to the workplace lead to release.
Anything contested
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 required8 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 boundaryAgent 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 claimIllustrative example
Booking
Recorded as
Class
Evidence of record
Confidence
Held for
Meeting room, half day
Proposed for release, not confirmed
Meeting room, half day
Check-in window, 3 August 2026
Held unreleased
The workplace lead, by name
As receivedDrawn from the booking system and the check-in record — it reaches no further than those sources do.
What the record holdsBooking requestCheck-in recordRelease proposal
Why no release hereA contested claim is settled under your policy, and never by a model output.
ActionReleaseAppend evidenceSend to workplace
What the score decidesA proposal under the configured threshold collects a coordinator read before it moves.
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 bookingFrom the resource it holds
03Evidence
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.
01Approved path
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.
02Human review
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.
04Build 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 sourcesRoom booking · calendars Desk and resource requests
Occupancy signalsSensors · check-in panels Room and desk presence
People and buildingsHR 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 systemsService desk · ticketing Release and dispute records
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 defenceInward → L1 · closest to the model
L6Rollback / safe modeNarrow the agent to release proposals when evaluation or production signals degrade.Roll back
L5Version monitoringTrack model, prompt and release rules; changing what a class permits changes which bookings may lapse.Track
L4TraceabilityRecord each booking, the rule behind it, the resource it held and every read of that trail.Record
L3Lead releaseHold every proposal for a named workplace lead; the hold governs release, not whether a claim was fair.Gate
L2Policy guardrailsTest each proposal against the precedence, notice and adjustment rules configured for that class; an adjustment booking never enters the automatic list.Restrict
L1Confidence thresholdsRoute a thin proposal to a coordinator read before anybody loses a room they still intended to use.Require review
Model coreProposal assembled — the booking, the rule, the signals and completeness
L1 – L2Test whether a release may stand
L3Puts the release in a person's hands
L4 – L5Keep the booking and the resource behind it
L6Retreats 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
Depth of coverage ▼
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 lifecycleDirection of processing →
01 · Retrieval1 mode
KG-03
Stale availability read
The availability read is not the one now in force.
Stage gathersThe bookings, the rooms, the rules and the signals
02 · Reasoning2 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 proposesThe bookings, their rules and completeness
03 · Tool / write2 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 writesOnly where write access and approval policy allow it
04 · Output1 mode
KG-01
Released, rule unrecorded
The record shows a release but not what permitted it.
Stage returnsThe release a lead takes and the record it leaves
05 · Change / Version1 mode
KG-07
Silent rule regression
A configuration change moves the rule, not the record.
Stage tracksModel, prompt, release rules and booking fields
Sev-1 · a room released on a sensor aloneSev-2 · an adjustment booking auto-releasedSev-3 · signals degrade, proposal held back
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 aggregateIllustrative 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 threshold2 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 stagesSwitchback — the path turns at Improve and returns at Learn
01Detect
Correction rate rises on shared meeting rooms.
02Diagnose
The booking nobody cancelled and nobody used, on the day the floor ran out, is read back until one cause remains.
03Improve
Number the change; the bookings that drove it are filed underneath it.
04Verify
Each touched booking case is run once more, and one red holds it back.
05Learn
It stays on as a standing test, and the release rules move alongside it.
Learn → DetectThe 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.
WorkstreamWeek 1Week 2Week 3Week 4Week 5Week 6
01Resource-class and automation-boundary discovery.
02Booking, calendar and occupancy sources.
03Booking-to-resource and precedence-rule mapping.
04Booking and occupancy ingestion.
05Booking, resource and class binding.
06Release scoring and review routing.
07Workplace lead release workflow.
08Calendar-system integration.
09Conflict and release cases.
10Guardrails and allocation controls.
11Booking-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 building, one quarterProductionProduction booking workflowAdvancedMultiple 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 priceFrom $5,000From $8,000Custom quote
Final build priceConfirmed after discovery based on integrations, workflow complexity, booking 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 resource classes and what each one permits→Class mapping and booking captureWeek 1
02Representative booking, check-in and occupancy records→Record binding, release logic and the proposal baselineWeek 2
03Your precedence order and who may change it→Class mapping, rule binding and the automation boundaryWeek 1
04Access to relevant APIs, feeds or exports→Booking, calendar and sensor-source assessment, then integration setupWeek 2
05Bookings you would not want challenged→Conflict cases and the evaluation runWeek 4
06What no booking record may settle→Release scoring, review routing, guardrails and hold controlsWeek 3
07A named workplace lead who releases→Release 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
The widths are weeks of real work rather than spacing, and that is why one band has to carry two.
PhaseW1W2W3W4W5W6
DiscoveryW1
BuildW2 – W3
EvaluateW4 – W5
Pilot & LaunchW5 – W6
Week focusW1Booking workflow discovery, class mapping and the automation boundaryW2Source integration and the release-accuracy baselineW3Release proposals, precedence logic and hold controlsW4Evaluation suite, conflict cases and failure-mode testingW5Calendar integration, pilot bookings and targeted correctionsW6One booking quarter run under the workplace lead, then Agent Care handover
Reading the bandEach bar covers only the weeks its own work is named for. The fifth carries two because the work does.
At the end of W6When the booking record validates, Agent Care takes the agent on.
DurationSix-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.
