Why Data fragmentation & system interoperability keeps Occupancy, utilization & tenant experience unsolved — and how an agent platform changes it

📄 Formatted PDF editions (English · 繁體中文) are free for subscribers — subscribe to get them →

Executive Summary

The biggest business pain our CRE-intelligence corpus surfaced this cycle is Occupancy, utilization & tenant experience — 1,416 signal instances across 209 primary-source documents in the AISB CRE-intelligence corpus (AISB corpus, trailing window ending 2026-06-25). The sharper question is: why has a decade of PropTech spend and a wave of AI tooling failed to solve it? The dominant tool-failure theme in the same corpus is Data fragmentation & system interoperability — 376 instances across 132 documents (AISB corpus, same window).

The external market data tells the same story from the other direction. JLL's Global Occupancy Planning Benchmark Report 2026 puts global office utilization at 56% — meaning nearly half of paid-for office space sits empty on an average day even after two years of return-to-office mandates (JLL 2026). CBRE's 2025 Americas Office Occupier Sentiment Survey found that 66% of organizations report office space that is less than 60% utilized on an average basis, while 73% report utilization effectively at capacity on peak days (CBRE 2025). That peak-versus-average whiplash — full on Tuesday, empty on Friday — is precisely the problem a well-instrumented, well-integrated data layer is supposed to manage. It is not being managed, and this report explains why.

Our thesis, developed across the report:

1. The pain persists because the data needed to solve it lives in five to ten systems that were never designed to talk to each other — BMS/BAS, access control and badge systems, room and desk reservation, occupancy sensors, the lease/stacking system (IWMS), the CMMS, HR headcount, and increasingly Wi-Fi analytics. Each PropTech point tool solves its slice and re-creates the integration problem for the next buyer.
2. The semantic layer — not the transport layer — is the real bottleneck. Protocols like BACnet moved building data for decades; what has never scaled is a shared meaning layer (which sensor is in which zone, serving which tenant, feeding which decision). ASHRAE Standard 223P, the industry's semantic-interoperability effort, remains a proposed standard as of this writing (ASHRAE SSPC 223 status, per AISB interop research, 2026-06).
3. Three forces have matured in 2024–2026 that change the calculus: (a) large-language-model tooling that can automate point-naming and semantic mapping tasks that previously required manual integrator labor (BMS-RAG research reported near-100% F1 on some public point-classification datasets (ScienceDirect 2026), as catalogued in the AISB interop corpus); (b) an open agent-tool protocol — the Model Context Protocol — that became neutral, foundation-governed infrastructure when Anthropic donated it to the Linux Foundation's new Agentic AI Foundation on 2025-12-09, with platinum members including AWS, Google, Microsoft, and OpenAI (Linux Foundation press release, 2025-12-09); and (c) a legal lever: the EU Data Act's user data-access rights became applicable on 2025-09-12, explicitly covering connected products such as HVAC and building-automation equipment, with "accessible by design" obligations following on 2026-09-12 (European Commission, Data Act; Morgan Lewis, 2025-09).
4. An agent platform attacks the problem differently from a point tool: instead of forcing every dataset into one schema before any value is delivered, agents read the building's existing exports where they live, normalize meaning on demand, carry provenance on every answer, and hand work across domains (technical services ↔ space planning ↔ soft services) the way a human operations team does — but with an audit trail.

Bottom line: the gap is not a lack of tools. It is the absence of a trustworthy, auditable, integrated operating layer that turns fragmented data and one-off AI pilots into compounding decisions. This report names the pain with evidence, dissects why point-solution PropTech has structurally failed to close it, sets out how an agent-platform approach differs, and closes with recommendations, a step-by-step implementation playbook, and the metrics an owner-operator should track.

Who this report is for and how to read it. Section 1 evidences the pain for asset managers and workplace leaders who need the numbers for an internal case. Section 2 is the analytical core — why the tool market has structurally failed to close the gap — and is the section to read if you read only one. Section 3 sets out the agent-platform alternative and, in Section 3.5, a vendor-neutral buyer's checklist that applies to any provider, including AISB. Sections 4–5 are the action layer: six recommendations and a staged playbook with pre-committed kill criteria. Section 6 frames ROI honestly — including a worked illustration explicitly labeled as arithmetic, not forecast — and Section 7 states the limits of everything before it. Figures are sourced inline throughout; anything labeled "AISB estimate" has no authoritative public source and is offered with its range.

1. The Pain — what the industry is actually struggling with

Evidence base. This analysis is grounded in 209 primary-source CRE intelligence documents collected over the trailing window — 1,416 signal instances on Occupancy, utilization & tenant experience, the dominant operational pain, versus 376 on the Data fragmentation & system interoperability tool-failure theme (AISB CRE-intelligence corpus, 2026-06). Unlike survey-based market reports, AISB publishes from a daily-collected primary corpus; external benchmarks below are cited to their named publishers.

1.1 The occupancy paradox: full and empty at the same time

The defining feature of post-2020 office operations is that the same building is simultaneously over- and under-utilized. CBRE's 2025 Americas Office Occupier Sentiment Survey quantifies it: 73% of organizations report office utilization effectively at capacity on peak attendance days, but only 34% report average attendance at capacity, and 66% report space less than 60% utilized on an average basis (CBRE 2025). JLL's Global Occupancy Planning Benchmark Report 2026 measured global utilization at 56%, with the gap between actual and target utilization narrowing from 25 to 18 percentage points — progress driven substantially by organizations lowering their targets to more realistic levels rather than by filling their buildings (JLL 2026).

Attendance policy is tightening — the same JLL report finds 62% of organizations now require fixed in-office days, up from 49% a year earlier (JLL 2026) — and enforcement is real: CBRE found the share of organizations measuring policy compliance rose to 69% in 2025 from 45% in 2024 (CBRE 2025). Yet the operational outcome the policy is meant to produce — a building sized, conditioned, staffed, and serviced to match actual human presence — remains out of reach for most portfolios.

Why? Because answering even the first-order questions requires joining data that lives in different systems, owned by different teams, on different refresh cycles:

Question an owner/occupier asks weekly	Systems that must agree to answer it
"How many people were actually in Building A on Tuesday?"	Badge/access control + visitor management + Wi-Fi analytics + occupancy sensors
"Which floors can we release at lease renewal?"	Utilization sensors + reservation system + lease/IWMS + HR headcount projections
"Why is the 8th floor always cold at 4pm?"	BMS trend logs + occupancy data + CMMS work-order history
"Is the café sized right for our peak days?"	Badge data + food-service POS + reservation calendar
"Did the churn project actually improve experience?"	Move-management records + ticket/complaint data + survey/NPS + utilization

Every row of that table crosses at least two organizational silos and at least two vendor data models. In the AISB corpus, this cross-system join — not any single system's inadequacy — is the recurring shape of the complaint: the occupancy signal exists somewhere, but not where the decision is being made, not at the moment it is being made, and not in a form the decision-maker trusts.

1.2 Tenant experience: the same fragmentation, felt by humans

Tenant and employee experience is the human-facing surface of the same data problem. The experience failures our corpus surfaces most frequently are not exotic: rooms booked but unoccupied while people wander looking for space; comfort complaints that loop between the FM help desk and the controls contractor because neither sees the other's data; amenity investments sized to badge-swipe theory rather than observed behavior; and "return to office" mandates that collide with elevators, parking, and desk supply on exactly the peak days CBRE identifies as already at capacity (CBRE 2025).

Each of these is a join failure. The reservation system knows the room was booked; the sensor knows nobody came; the BMS conditioned it anyway; the help desk fielded the complaint about the room that was "never available"; and no system is responsible for reconciling the four. The tenant experiences the un-reconciled residue.

1.3 Why this pain ranks first now

Three timing factors elevate occupancy/utilization/experience above the other pains in our corpus this cycle:

• Lease events force the question. Portfolio decisions deferred during 2020–2023 are hitting renewal windows, and utilization evidence — or its absence — now directly prices real money. JLL's benchmark framing of an 18-point actual-to-target gap (JLL 2026) is, in cash terms, the share of rent paying for structurally empty space.
• Attendance mandates raise the stakes of being wrong. With 62% of organizations mandating fixed days (JLL 2026), a wrong answer about peak capacity is no longer an analytics embarrassment; it is a visible daily failure for every employee.
• Energy and compliance pressure couple to occupancy. Conditioning empty space is the cheapest energy waste to eliminate — but only if occupancy data can actually reach the BMS decision loop, which is precisely the integration this report's second theme says is missing.

1.4 Anatomy of the fragmented occupancy stack

To make the abstraction concrete, walk one occupancy signal through a typical mid-size office asset and note where it fragments. The numbered systems below are generic categories, not vendor references.

1. Access control / badge. Owned by security. Records entries (and, in many deployments, not exits), keyed to employee identity — which makes it simultaneously the most complete presence census and the most privacy-sensitive dataset in the building. Export is typically a nightly or weekly report designed for security audits, not analytics; identity must be stripped or aggregated before any utilization use.
2. Room/desk reservation. Owned by IT or workplace teams. Records intent, not presence — the corpus's recurring "booked but empty" complaint (Section 1.2) is the measured gap between this system and reality. Refreshes in real time but exports via its own API and schema.
3. Occupancy sensors. Owned by facilities or the workplace-analytics budget. Records presence, but only where sensors were installed — coverage follows the pilot's original footprint, not the questions now being asked. Vendor cloud, vendor schema, vendor dashboard.
4. Wi-Fi / network analytics. Owned by corporate IT. The broadest cheap proxy for presence, with known biases (devices ≠ people; guests and multi-device users distort counts). Rarely joined to any of the above because the network team was never asked.
5. BMS/BAS. Owned by engineering. Knows what the building did about presence (conditioning schedules, setpoints, actual loads) but almost never knows presence itself; occupancy-coupled control remains the exception, not the rule, in the existing stock.
6. IWMS / lease admin. Owned by corporate real estate. Holds the financial meaning of every square meter — and typically refreshes on a monthly or quarterly cadence that cannot see Tuesday-vs-Friday dynamics.
7. CMMS / ticketing. Owned by FM. Records the human residue of the mismatches (comfort complaints, "room not available," cleaning issues) — the symptom log that is almost never joined to the cause data in 1–6.

Seven systems, at least five owners, three refresh cadences (real-time, nightly, monthly), and no shared identifier beyond — at best — a room name that is spelled three different ways. This is what "data fragmentation & system interoperability" means at ground level, and why the corpus counts it as the dominant tool-failure theme (376 instances / 132 documents; AISB corpus, 2026-06). Every occupancy initiative that fails, fails somewhere in this table.

Note also what is absent: none of these systems is wrong, broken, or badly made. Each is competent at its procured purpose. The failure is emergent — a property of the seams, not of the parts — which is exactly why buying an eighth competent part has never fixed it.

2. Why PropTech & AI tools haven't solved it

The corpus points to Data fragmentation & system interoperability as the dominant reason the tools have not closed this gap (376 instances across 132 documents; AISB corpus, 2026-06). This section dissects the failure modes structurally — deliberately without disparaging any named vendor, because the failures are systemic, not the fault of any single product.

2.1 The stack was never designed as a stack

A typical mid-size commercial building runs, conservatively, five to ten operational systems relevant to occupancy and experience: BMS/BAS, access control, CCTV/analytics, room/desk reservation, occupancy sensing, CMMS, IWMS/lease admin, visitor management, parking, and increasingly EV charging and Wi-Fi location analytics. These arrived over decades, procured by different budget holders (security, facilities, IT, corporate real estate, HR), from different vendors, on different contract cycles.

Two layers matter for interoperability, and only one of them ever scaled:

• Transport. BACnet (ASHRAE Standard 135) and its peers successfully standardized how building-automation devices move data. This layer is broadly solved and has been for years (AISB interop synthesis 2026).
• Semantics. What a point means — "this temperature sensor serves the northeast VAV zone on floor 8, which is leased to Tenant X and scheduled as collaboration space" — was never standardized in practice. ASHRAE Standard 223P, the formal semantic-interoperability effort, remains a proposed standard as of this writing; community ontologies (Project Haystack, now at Haystack 5 with the Xeto schema language, and Brick, in the process of aligning with RealEstateCore) are the strongest convergence signal in a decade but carry no force of mandate (AISB interop research synthesis, 2026). In our research, only a small minority of buildings have any machine-readable semantic tagging at all — plausibly single digits as a share of the installed base. This is a directional reading of our deployment research, not a measured statistic (AISB qualitative estimate 2026).

The result: every analytics or AI product that wants to answer an occupancy question must first re-derive the meaning of the building's data — a labor cost the industry pays over and over, per building, per vendor, per project.

2.2 The integration tax is paid per-tool, and it never amortizes

Manual point-mapping — the process of tagging what each BMS point means so software can use it — is skilled, tedious work. Public authoritative pricing does not exist; the working range in our research is roughly $10,000– $75,000 per building depending on point count and complexity, with a rough midpoint around $30,000 (AISB estimate 2026). The estimate is an industry-interview and public-rate-card synthesis from our interop research; no authoritative public source exists, which is itself evidence of the opacity problem.

The structural issue is not the absolute number. It is that the tax is paid once per analytics vendor, not once per building. Each new tool re-maps the same points because the mapping lives inside the vendor's silo, is expressed in the vendor's schema, and is treated as the vendor's asset. When the contract ends, the semantic work typically leaves with it. Our corpus calls this the "mapping tax," and it is the single most concrete mechanism by which fragmentation taxes every occupancy initiative.

2.3 Pilot purgatory: why demos scale poorly

The corpus's most persistent tool-failure narrative is the pilot that never becomes an operation. The mechanism is consistent:

1. The pilot is scoped to one building whose data was hand-groomed for it.
2. Value is demonstrated against that groomed data.
3. Scaling requires repeating the grooming across the portfolio — the integration tax again, multiplied by building count — and the business case that looked compelling per-pilot collapses at portfolio grooming cost.
4. The tool survives as a dashboard on the buildings it started with, and the underlying decision process never changes.

This is not a vendor-competence story; it is an economics story. Point tools capture value above the integration layer while the cost lives in the integration layer, and no single point tool has the incentive — or the contractual standing — to fix the layer for everyone.

2.4 The incentive structure preserves fragmentation

Three incentive facts, each documented in the AISB interop research synthesis (2026-06-13), explain why the market has not self-corrected:

• Buyers pay for outcomes, not plumbing. Owners rationally refuse to fund "integration middleware" as a line item; they fund energy savings, space decisions, tenant satisfaction. So integration is always someone's cost of goods, never anyone's product — and it is minimized, not solved.
• Integration complexity is a renewal moat. For an incumbent that already holds a building's data, the cost a customer would incur to re-map everything for a competitor is retention leverage. There is no commercial reason to volunteer away that moat, and mainstream incumbent platforms generally require onboarding into the vendor's own cloud environment (AISB interop research synthesis, 2026-06-13 — stated as a structural observation, not a criticism of any named vendor's legitimate product strategy).
• Consolidation absorbs, rather than opens, the AI-native challengers. The strongest recent example: Trane Technologies completed its acquisition of BrainBox AI — an AI-for-HVAC company whose technology was deployed across 14,000+ buildings — announced closing 2025-01-03 (Trane Technologies / BrainBox AI announcement, as catalogued in AISB interop research, 2026-06-13). Successful building-AI capabilities tend to end up inside larger ecosystems, which is rational M&A but does not produce an open interoperability layer.

Meanwhile, the independent "building-data-layer" companies demonstrate the services-heavy economics of the middleware path: Mapped, one of the most prominent independents, had raised a cumulative $42.8M through its 2025-06 Series B (Crunchbase, Tier-2 source, via AISB interop research 2026-06-13) — respectable, but an order of magnitude below what category-defining infrastructure businesses in adjacent industries (payments, health data) raised, reflecting how hard this market is to scale when every deployment carries per-building mapping labor. KODE Labs' $14.35M GSA contract covering 150 federal buildings in the National Capital Region, awarded September 2024 in collaboration with EY (KODE Labs press release 2024), also reported by Crain's Detroit Business, shows real demand exists — and that it currently clears the market at bespoke-services prices.

2.5 What the AI wave changed — and what it didn't

The 2024–2026 LLM wave genuinely moved one piece: semantic mapping is now substantially automatable. Research the AISB corpus catalogues as BMS-RAG (ScienceDirect 2026) reported state-of-the-art results using retrieval-augmented LLMs to classify BMS points against the Brick ontology across six real-world datasets, approaching 100% F1 on some of them (ScienceDirect 2026); our practical planning estimate is that 75–85% of points can be auto-tagged in typical conditions, with the remainder needing human confirmation — a planning estimate of our own, not a figure derived from the F1 study, whose results are on curated benchmark datasets (AISB estimate 2026). If that holds in production settings, the per-building mapping tax compresses substantially — our synthesis' planning estimate is from a ~$30K midpoint toward $5–10K (AISB estimate 2026) (honest caveat from our own review: the savings case is strongest for mid-size and larger buildings; small buildings were never expensive to map).

What AI did not change:

• Access politics. Auto-tagging helps only after you can reach the data. Vendor-cloud gating, licensing walls, and legitimate OT-security isolation (per NIST SP 800-82 practice) still stand between an AI tool and the points (AISB interop synthesis 2026).
• The trust deficit. Owners do not act on recommendations they cannot audit. A black-box model that says "release floor 8" without traceable evidence produces a meeting, not a decision. Provenance — which source, which standard, which confidence — is a platform property, not a model property, and most AI point tools do not carry it.
• Cross-domain accountability. An occupancy insight is only valuable when someone re-stacks a floor, retunes an AHU schedule, resizes a cleaning contract. Those are different teams and different systems. A tool that stops at insight leaves the join — again — to humans.

2.6 The legal layer just shifted under everyone

One development from outside PropTech deserves its own subsection, because it rebalances access politics: the EU Data Act became applicable on 2025-09-12 (Regulation (EU) 2023/2854; European Commission Data Act page; Morgan Lewis client alert, 2025-09). Its user data-access rights explicitly reach connected products including HVAC and building-automation equipment: users (which can include building owners and operators of connected equipment) gain the right to access the data their devices generate in a structured, machine-readable form — continuously, not as a one-time export — and to direct it to third parties of their choice; a second wave of "accessible by design" obligations for newly placed products applies from 2026-09-12 (European Commission, Data Act explained; Morgan Lewis, 2025-09; Greenberg Traurig, 2025-09).

Two honest caveats: this is EU law, with extraterritorial pull only insofar as products are placed on the EU market; and enforcement practice is young. But the direction is unambiguous — the legal default for equipment data is tilting from "vendor's asset" toward "user's right," and portfolio owners negotiating BAS/vendor contracts anywhere in the world can now point to a major regulatory regime that treats continuous machine-readable data access as table stakes. Our research found that legal-industry commentary on the Act overwhelmingly addresses manufacturers' obligations; almost no one is translating it for the building-owner side (AISB interop research synthesis, 2026) — a gap this report series will continue to cover.

2.7 Why standards alone will not close the gap — and what finally might

It is tempting to conclude that the industry simply needs to finish its standards work. The history counsels patience about that theory:

• ASHRAE Standard 223P — the formal semantic-interoperability standard — has been in development for years and remains proposed (unpublished as a final standard) as of this writing (AISB interop synthesis 2026). Even at publication, adoption would be voluntary and retrofit-incentive-free for the existing stock.
• Project Haystack reached its strongest version yet (Haystack 5, with the Xeto schema language) and Brick is aligning with RealEstateCore — the best convergence signal in a decade (AISB interop synthesis 2026). But both are community standards: they define vocabularies, not obligations, and the unglamorous work of applying them to millions of existing buildings is precisely the mapping tax of Section 2.2.
• Green Button (NAESB REQ.21) is the under-appreciated success story: a standardized, OAuth-based path to utility meter data available through roughly 60% of US utilities (AISB interop estimate 2026) — proof that when a data path is standardized and zero-hardware, it actually gets used. It covers the meter, not the building's interior systems.

The honest synthesis: the transport layer scaled because it shipped inside products; the semantic layer stalls because it ships as homework. Standards define the answer key, but someone still has to do the labeling — and until 2024–2026 the labeling was human, per-building, and per-vendor.

What changes the equation now is the combination identified in the Executive Summary: LLM auto-tagging collapses the labeling labor (Section 2.5); MCP gives the tagged data a neutral, foundation-governed way to reach any agent (Linux Foundation, 2025-12-09); and the EU Data Act converts "please export my data" from a favor into a right in a major market (applicable 2025-09-12; European Commission). None of the three is sufficient alone. Together they make the semantic layer, for the first time, cheaper to solve than to keep re-buying.

A regional footnote our research flags as a blind spot in the English-language discourse: the interoperability conversation, its benchmarks, and its vendor scorecards are overwhelmingly US/EU-framed. Major APAC certification and performance frameworks — Singapore's Green Mark, Taiwan's EEWH and smart-building labeling, Japan's CASBEE — have effectively no coverage in published interoperability benchmarks (AISB interop synthesis 2026). For APAC portfolio owners this means imported "best practice" tooling assumptions frequently mismatch local stack realities; for the research community it is an open field. AISB's research agenda addresses this gap directly in forthcoming APAC-focused work.

3. The AISB Agent-Platform Analysis

AISB is an agent platform, not a point tool: a fleet of specialized CRE squads — Technical Services, Space Planning, Project Management, Construction, Soft Services, Architecture & Design, and a Knowledge Engine — that share one audited knowledge layer and hand work between each other under a common governance and provenance discipline. This section explains, as analysis rather than advertisement, why that architecture addresses the failure modes of Section 2 differently — and where it honestly does not.

3.1 The core inversion: read where the data lives

Point-solution PropTech implicitly demands: first centralize and normalize everything into my schema, then I deliver value. That demand is exactly where the integration tax, the pilot purgatory, and the access politics live.

An agent platform inverts it: the agent is the adapter. Agents consume the building's existing exports — scheduled BMS trend reports, CSVs from the badge system, reservation-system exports, utility Green Button data — available via roughly 60% of US utilities through standardized OAuth and REST (AISB interop estimate 2026) —, CMMS extracts — in the formats the systems already produce. Semantic normalization happens at read time, per question, using exactly the LLM capability Section 2.5 established (auto-tagging against Haystack/Brick vocabularies), rather than as a monolithic up-front project. The startup energy approaches zero: no OT network access is requested on day one, no vendor cloud migration, no rip and replace. "Read-first, advisory-only" is not a limitation to apologize for; for the trust- and security-constrained FM environment described in Section 2.5, it is the posture most likely to get in the door.

The industry plumbing for this pattern matured on a neutral foundation in December 2025: the Model Context Protocol (MCP) — the open standard by which AI agents connect to tools and data sources — was donated by Anthropic to the Linux Foundation's newly formed Agentic AI Foundation on 2025-12-09, alongside contributions from Block and OpenAI, with platinum members including AWS, Google, Microsoft, Bloomberg, and Cloudflare (Linux Foundation press release, 2025-12-09; Anthropic announcement, 2025-12). Agent-to-system connectivity is therefore no longer proprietary plumbing — it is foundation-governed infrastructure, the way the web's protocols are. The building domain's MCP coverage is still embryonic (our research found only an early open-source BACnet MCP server prototype and a global blank where Haystack/Brick/Green Button MCP servers should be; AISB interop research synthesis, 2026-06-13) — which is a gap, and also a map of what gets built next.

3.2 Provenance as the product

Section 2.5 named the trust deficit as the failure AI did not fix. The agent platform's answer is architectural: every recommendation carries its provenance — the source documents or data extracts it rests on, the squad responsible, the standard it is anchored to (IPMVP for savings verification, ASHRAE guidance for comfort and ventilation claims, BOMA for area efficiency), and a stated confidence. Recommendations are auditable by construction, and the platform's own review pipeline (domain-squad review, then executive/expert review, then a legal-risk gate) runs before outputs reach a client — the same pipeline this very report passes.

This matters commercially, not just epistemically: the difference between "a dashboard said so" and "here is the trend log, the occupancy extract, the standard, and the calculation" is the difference between an insight and a decision an asset manager will sign.

3.3 Cross-domain handoff: the join failure, addressed structurally

Every row of the Section 1.1 table was a cross-system join failure. In an agent platform those joins are native handoffs: the same occupancy question routes through the Space Planning squad (utilization analysis, policy-to-demand calibration, test-fits), hands technical consequences to Technical Services (BMS scheduling against observed occupancy, M&V of the resulting energy delta), and service consequences to Soft Services (cleaning/catering contracts resized to observed patterns, vendor-KPI vs. occupant-experience divergence checks). Because the squads share one knowledge layer, the badge data one squad ingested is the same evidence the next squad's recommendation cites — the reconciliation that Section 1.2 showed no one owns today has an owner.

Applied concretely to this report's pain theme:

• Occupancy truth. Fuse the available presence signals (badge, Wi-Fi, sensors, reservations) into a single auditable utilization picture, with privacy handled as a first-class design constraint (aggregation and de-identification before analytics; individual-level surveillance is explicitly out of scope).
• Utilization → space decisions. Turn the fused picture into peak-vs-average demand curves — the exact CBRE 73%-peak / 34%-average divergence (CBRE 2025) — and from there into evidence-carrying stack/release/test-fit options at lease events.
• Utilization → operating cost. Schedule HVAC and services against observed presence, and verify the delta with IPMVP-anchored M&V rather than asserted savings.
• Experience loop. Correlate complaint/ticket streams with the comfort and reservation data that explain them, so experience fixes target causes rather than symptoms.

3.4 What an agent platform does not solve — honest limits

Symmetry requires the anti-claims, and our own expert review demands them:

• It does not replace the systems. The BMS still runs the building; the IWMS still holds the leases. The platform reads, reasons, and recommends; write-back to building controls remains human-gated as a matter of policy and safety, not a temporary limitation.
• It does not abolish the mapping problem — it compresses and pools it. The 75–85% auto-tagging estimate (Section 2.5, AISB estimate 2026) still leaves a human-confirmation tail, and results on any specific portfolio are an empirical question the playbook (Section 5) is designed to answer before scale-up.
• It is only as good as the exports it can reach. A portfolio whose vendors contractually block data export has a procurement problem first and an analytics problem second — which is why Section 4's recommendations start with contract language, and why the EU Data Act development (Section 2.6) matters even to non-EU owners as negotiating precedent.
• Agent output quality requires governance. Ungoverned LLM output in an operational setting is a liability, not an asset. The platform posture described here presumes review gates, provenance discipline, and audit trails; an "agent platform" without those properties inherits the same trust deficit as the black-box dashboards it replaces.

3.5 A buyer's checklist: what to demand from any agent platform

This report's analysis should raise the bar for AISB as much as for anyone else. An owner evaluating agent-platform claims — from any provider — should require affirmative answers to all of the following before treating the platform as an operating layer rather than another point tool:

1. Read-first posture. Can it deliver its first value from existing exports, without OT network access, vendor-cloud migration, or new hardware? If the deployment plan starts with an integration project, the integration tax has simply been renamed.
2. Portable semantics. Is the semantic map it builds expressed in open vocabularies (Haystack/Brick) and contractually deliverable to the owner? (Recommendation R6.)
3. Provenance on every output. Source, standard, confidence, and responsible party attached to each recommendation — machine-checkable, not marketing copy.
4. Human-gated actuation. Any write-back to building systems behind an explicit human approval gate, with comfort/safety vetoes. An "autonomous" platform that auto-writes setpoints on day one is a liability posture, not a maturity signal.
5. Cross-domain handoff. Can an occupancy finding natively become a space recommendation, an HVAC-schedule recommendation, and a services recommendation — with shared evidence — or does each domain restart from raw data?
6. Verification discipline. Does the platform volunteer M&V (IPMVP where applicable) on its own claimed savings, and publish its misses? A provider that never reports a null result is not measuring.
7. Privacy by architecture. Aggregation/de-identification of presence data before analytics, documented; individual-level profiling out of scope by design, not by policy PDF.
8. Audit trail. Every agent action logged in a reviewable ledger the owner can inspect — the property that turns "AI did something" into an accountable operation.

The sharpest objection to this report is that an agent platform simply becomes the next renewal moat — a point tool wearing a fleet costume. The checklist above is how a buyer tests that claim against any vendor, explicitly including AISB. AISB publishes this checklist knowing it will be graded against it; that is the point. A market that procures against these eight questions gets an interoperable operating layer regardless of which vendors win.

3.6 Privacy: the constraint that shapes the whole design

Because presence data is people data, the fusion this report recommends (badge + reservations + sensors + Wi-Fi) sits under GDPR-class regimes and their APAC counterparts (Singapore PDPA and peers), and — for any biometric modality — stricter rules again. Two design consequences follow, and both are load-bearing for the architecture rather than compliance garnish:

• Aggregate before analyzing. Utilization questions are almost never about individuals; they are about zones, floors, days, and patterns. A pipeline that de-identifies and aggregates at ingestion answers every question in Section 1.1's table while holding no individual trajectory — which converts the privacy conversation with works councils and tenants from a negotiation into a demonstration.
• The occupant is a stakeholder, not a sensor target. Experience analytics that occupants perceive as surveillance destroy the very experience they claim to optimize. Transparent signage, documented data flows, and visible aggregation are experience features in themselves.

This is also where an audited agent platform differs practically from an ungoverned analytics stack: provenance and access logging (Section 3.2) mean an owner can show a regulator or tenant exactly which data, at which aggregation, produced which decision — the difference between asserting compliance and evidencing it.

4. Recommendations

For owner-operators, corporate occupiers, and property managers confronting the occupancy/utilization/experience pain:

• R1. Stop buying point tools for occupancy, utilization & tenant experience in isolation; adopt an integrated operating layer with cross-domain handoffs. Evaluate any new tool on one question first: does it reduce or re-create the integration tax for the next tool? A product whose semantic mapping work is portable (expressed in Haystack/Brick vocabularies, exportable on contract end) reduces it; a product whose mapping is proprietary re-creates it.
• R2. Demand provenance on every AI output — source, standard, confidence, responsible party. If a recommendation cannot show its evidence chain, treat it as a hypothesis, not a decision input. This single procurement criterion filters most of the trust-deficit failure mode of Section 2.5.
• R3. Instrument a single source of truth for presence before layering AI on top. Reconcile badge, reservation, sensor, and Wi-Fi signals into one auditable utilization dataset — with privacy aggregation built in — because every downstream decision (stacking, energy, services, experience) inherits its quality. The CBRE peak/average divergence of 73% peak vs 34% average (CBRE 2025) cannot even be seen in a portfolio that measures presence one system at a time.
• R4. Run AI against a measurable decision, not a dashboard. Pick decisions with a verifiable delta — an M&V-verified energy schedule change, a lease-event floor release, a services contract resize — and hold the tooling to the verified outcome (IPMVP where applicable). A pilot without a decision attached is pilot purgatory by construction (Section 2.3).
• R5. Put data access in the contract. At every BAS/vendor renewal, require continuous, structured, machine-readable export of the data your equipment generates, and portability of any semantic mapping produced during the engagement. The EU Data Act (applicable 2025-09-12; European Commission) has made this posture the regulatory default in a major market; use it as precedent language even where it does not bind.
• R6. Treat semantic mapping as an owned asset. Whoever performs the tagging, the resulting building ontology (points → zones → tenants → uses) should be deliverable to you, in an open vocabulary, so the tax of Section 2.2 is paid once rather than per vendor.

5. Implementation Playbook

A staged, kill-criteria-carrying sequence an owner-operator can run on one asset and scale on evidence. Duration figures are planning guides, not commitments; every stage's exit is an artifact, not a meeting.

Step	Action	Owner	Output (exit artifact)
1	Baseline the pain: assemble current utilization evidence, decision backlog (lease events, comfort complaints, service contracts), and the cost currently attributed to empty/misused space	FM / asset manager	Pain baseline memo with numbers and named data gaps
2	Map data sources & access: inventory the 5–10 relevant systems, what each can already export today, contract/licensing constraints, and privacy obligations	IT / ops + procurement	Source inventory + access matrix (green/amber/red per system)
3	Stand up the presence source-of-truth: fuse available exports (badge, reservations, sensors, Wi-Fi) with privacy aggregation; auto-tag semantics against open vocabularies; human-confirm the tail	Agent platform (e.g., AISB squads) + FM	Auditable utilization dataset + owned semantic map
4	Deploy the relevant squads on one asset against one decision each: a space decision (Space Planning), an operating-schedule decision (Technical Services), a services-contract decision (Soft Services)	Agent platform + decision owners	Three evidence-carrying recommendations with provenance
5	Execute and verify: implement the accepted recommendations; verify the deltas (IPMVP-anchored M&V for energy; before/after utilization and ticket/experience metrics for space and services)	Engineering / FM	Verified-delta report — the pilot's honest scorecard
6	Scale-or-stop gate: scale to the next assets only if Step 5 verified value net of effort; otherwise stop and publish the reasons internally	Owner	Portfolio rollout decision + updated playbook

5.1 Step-by-step notes (what each step actually involves)

Step 1 — Baseline the pain (weeks 1–2). Resist the instinct to start with data plumbing. Start with the decision backlog: which lease events fall in the next 18 months, which floors are contested, which comfort complaints recur, which service contracts renew. Attach the currently believed utilization numbers to each — however weak their evidence — because the gap between believed and measured is itself a finding the program will report. The exit artifact is a one-page memo a CFO could read: the decisions, the money attached, and the named data gaps standing between today and an evidence-carrying answer.

Step 2 — Map data sources & access (weeks 2–4, parallel). For each of the systems in Section 1.4's anatomy, record three facts: what it can export today without new licensing (green), what it could export with configuration or a support ticket (amber), and what is contractually or technically blocked (red). The red list goes straight to procurement with Recommendation R5's contract language — and, for EU-market equipment, the Data Act's access rights (applicable 2025-09-12; European Commission) as negotiating precedent. Do not let a red system block the pilot: Section 3.1's read-first posture means the pilot runs on the green list.

Step 3 — Presence source-of-truth (weeks 4–8). Fuse the green-list exports with privacy aggregation applied at ingestion (Section 3.6). Auto-tag semantics against Haystack/Brick vocabularies and human-confirm the tail — budgeting for the 75–85% auto-tag planning estimate of Section 2.5 (AISB estimate 2026) means expecting real human hours on the remainder, not assuming magic. The two exit artifacts — the fused utilization dataset and the owner-held semantic map — are the program's durable assets; everything later is analysis on top of them.

Step 4 — Squads against decisions (weeks 8–12). One asset, three decisions, three domains: a space decision tied to a real lease event or re-stack; an operating-schedule decision tied to observed presence; a services decision tied to a renewing contract. Each recommendation ships with full provenance (Section 3.2) and a pre-registered success metric — pre-registered meaning written down before implementation, so Step 5 cannot quietly move the goalposts.

Step 5 — Execute and verify (weeks 12–20). Implement what the decision owners accept; measure against the pre-registered metrics; use IPMVP-anchored M&V for the energy claim specifically, because energy is where unverified marketing percentages are most endemic (Section 6, item 3). Publish the misses alongside the hits in the verified-delta report — the program's credibility for Step 6 depends more on an honest miss than on a flattering average.

Step 6 — Scale-or-stop (week 20+). The portfolio decision is now an evidence question: verified delta per asset × asset count vs. rollout effort, with the semantic-map asset (Step 3) reducing the mapping effort required on later assets (AISB estimate 2026). If the evidence says stop, stop — Section 2.3's pilot purgatory is mostly a graveyard of programs that could not say stop.

Kill criteria (pre-committed): if Step 3 cannot reach at least the majority of presence signals through existing exports, escalate to procurement (R5) before spending on analytics; if Step 5 shows no verified delta on any of the three decisions, do not scale — the honest conclusion is that the asset's decisions, not its dashboards, were already efficient.

Metrics to track from day one (the report's scorecard for the whole program): decision-cycle time (question → evidence-carrying recommendation); share of decisions carrying full provenance; verified savings (M&V); data-coverage % (presence signals reachable / total); semantic-map coverage (% of points tagged and owner-held); tool-count and integration-spend trajectory; and an experience indicator (ticket recurrence or occupant satisfaction) tied to the specific fixes shipped.

6. ROI Considerations

Illustrative, not a forecast. The figures in this section are planning-scale illustrations assembled from the sourced estimates named above. They are not a guarantee, not a prediction for any specific building, and not investment advice. Every portfolio should replace them with its own Step-1/Step-5 measured numbers.

Where the value concentrates, in decreasing order of directness:

1. Space decisions at lease events. This is the large-denominator item. JLL's 56% global utilization (JLL 2026) and CBRE's finding that 66% of organizations run below 60% average utilization (CBRE 2025) frame the ceiling: for many occupiers, a material fraction of rent currently purchases structurally empty average-day space, partially offset by peak-day constraints. An evidence-carrying release/re-stack decision at a single lease event can dwarf every other line in this section — which is why the playbook anchors Step 4 on a real lease event rather than a generic analytics goal.
2. Integration-tax compression. If the BMS-RAG-class auto-tagging results — near-100% F1 on some public datasets (ScienceDirect 2026) — translate to production at our 75–85% planning estimate (AISB estimate), per-building semantic-mapping cost compresses from a ~$30K midpoint toward $5–10K (AISB estimate 2026) — and, more importantly, becomes a one-time owned asset rather than a per-vendor recurring tax. Portfolio math scales linearly with building count; the caveat from our own review stands — small, simple buildings see little absolute saving.
3. Operating-schedule savings. Conditioning and servicing to observed presence rather than nameplate schedules is the classic occupancy-coupled saving. This report deliberately quotes no headline percentage: credible values are building-specific, and the discipline this report argues for is precisely to verify them via IPMVP-anchored M&V (Step 5) rather than to transplant a marketing number. The verified delta is the ROI line item; anything else is genre convention.
4. Experience and retention. The hardest to quantify and the most strategically valuable: fewer join-failure irritations (Section 1.2), faster complaint resolution because cause data is joined to symptom data, and amenity/service sizing that matches observed behavior. Track via ticket recurrence and occupant satisfaction rather than claiming a dollar figure this report cannot substantiate.
5. Avoided tool sprawl. Each point tool avoided (or retired) returns its subscription and its share of the integration tax. Tool-count trajectory is a first-class metric in Section 5 for this reason.

6.1 A worked illustration (hypothetical portfolio — illustrative arithmetic only)

To show how the pieces combine — and only to show the arithmetic shape, not to predict anyone's outcome — consider a deliberately hypothetical 20-building office portfolio. Every input below is either a sourced estimate from this report or an explicitly invented illustration parameter.

• Integration-tax line. At the Section 2.2 mapping-cost midpoint of ~$30K per building, range $10–75K (AISB estimate 2026), a portfolio that has historically deployed two analytics tools per building has paid the mapping tax roughly twice per asset — order of $1.2M across 20 buildings ($30K × 2 × 20 — illustrative arithmetic) (AISB estimate 2026). Compressing future mapping toward the $5–10K auto-tag-assisted planning range and making the map a one-time owned asset (Recommendation R6) turns a recurring ~$60K-per-building pattern into a single ~$5–10K-per-building event (AISB estimate 2026) — arithmetic on stated estimates, not a quote.
• Space-decision line. Suppose four of the twenty buildings hit lease events in the window (illustration parameter). The external benchmarks say the prior on meaningful average-day slack is high — 66% of organizations report sub-60% average utilization (CBRE 2025) — but whether these four buildings can release space, and how much, is exactly what Steps 3–4 exist to evidence. The illustration's honest form is therefore a question, not a number: on four lease events, what is one evidence-carrying released floor worth against the entire program cost? In most office markets, more than all other lines combined.
• Operating line. Deliberately left symbolic (Section 6, item 3): the program books only what Step 5's IPMVP-anchored M&V verifies.

The illustration's purpose is proportion, not prediction: the mapping-tax savings are real but bounded; the decision value is unbounded but must be earned per-decision with evidence. A program designed around the second, funded by the first, is the rational shape.

Reminder: illustrative, not a forecast. The 20-building portfolio, the two-tools-per-building history, and the four lease events are invented parameters for arithmetic transparency. Replace every line with measured values from your own Step 1 baseline.

The compounding argument — the platform thesis in one paragraph: each verified decision leaves behind (a) an owned semantic map increment, (b) a provenance-carrying precedent, and (c) a calibrated trust level with the humans who signed it. All three make the next decision cheaper and faster. Point tools do not compound this way because their residue is locked in their silo. That difference, not any single line item above, is the structural ROI case — and it is testable via the decision-cycle-time metric rather than a matter of faith.

7. Risks, caveats & honest limits

• Estimate discipline. Figures marked "AISB estimate" (mapping cost ranges, auto-tag rates, semantic-tagging prevalence, Green Button coverage) have no authoritative public source; they are research syntheses offered with stated ranges and should be replaced by measured values in any specific engagement. External figures are cited to their publishers and were not independently re-audited by AISB.
• Survey figures describe populations, not your building. CBRE's and JLL's numbers (CBRE 2025) are aggregates across respondent bases with their own methodologies; a specific portfolio can sit far from every average cited here.
• Regulatory reach. The EU Data Act analysis (Section 2.6) is a research summary, not legal advice; applicability to any given owner, product, or contract requires qualified counsel, and enforcement practice under the Act is still developing.
• Privacy is a hard constraint, not a feature toggle. Presence fusion (badge + Wi-Fi + sensors) touches employee and visitor data. The posture assumed throughout is aggregation/de-identification before analytics and compliance with applicable regimes (GDPR and local equivalents); individual-level occupant profiling is out of scope by design.
• AI results vary. Published point-classification results (BMS-RAG, ScienceDirect 2026-03) were achieved on specific public datasets; production buildings with multi-contractor, multi-era naming chaos are harder, which is exactly why the playbook human-confirms the tail and gates scale-up on verified results.
• No guarantees. Nothing in this report guarantees savings, utilization improvement, or experience outcomes. The entire argument of Sections 4–6 is that claims should be verified per-decision (IPMVP where applicable) rather than promised in advance.
• Vendor neutrality. Named companies appear as documented market facts (funding, contracts, acquisitions) drawn from cited sources; nothing in this report should be read as disparagement of any vendor's product quality or conduct. The failure modes analyzed are structural properties of the market, in which every participant — including agent platforms — operates.
• Review provenance. This is AI-assisted research, reviewed by the AISB CRE squads, C-level + Expert Council, and a CLO legal-risk gate before publication. It is not professional, engineering, or legal advice.

Appendix — sources, methodology & AI disclosure

Methodology. Pain points are ranked from the AISB CRE-intelligence corpus by weighted signal frequency × recency, with PropTech/AI tool-failure themes up-weighted (publisher's emphasis). The ranking is ordinal, not a market forecast. Corpus counts (1,416 instances / 209 documents on the pain theme; 376 / 132 on the tool-failure theme) are internal measurements of the AISB corpus over the trailing window ending 2026-06-25. External claims are attributed inline to their named publishers; estimates are flagged "AISB estimate" with ranges.

External sources cited inline: - JLL, Global Occupancy Planning Benchmark Report 2026 — https://www.jll.com/en-us/insights/occupancy-benchmark-report — global office utilization 56%; actual-to-target gap 25→18 percentage points; 62% fixed in-office day requirements (up from 49%). - CBRE, 2025 Americas Office Occupier Sentiment Survey — https://www.cbre.com/insights/reports/2025-americas-office-occupier-sentiment-survey — 73% at capacity on peak days vs 34% on average; 66% below 60% average utilization; policy-compliance measurement 69% (2025) vs 45% (2024). - European Commission, Data Act and Data Act explained https://digital-strategy.ec.europa.eu/en/policies/data-act — — Regulation (EU) 2023/2854; in force 2024-01-11; applicable 2025-09-12; design obligations 2026-09-12. - Morgan Lewis, EU Data Act Begins September 12 (2025-09); Greenberg Traurig, Action Required for Providers of Connected Devices (2025-09) — applicability to connected products incl. HVAC/building automation; continuous machine-readable access; third-party sharing on user request. - Linux Foundation press release (2025-12-09) — https://www.linuxfoundation.org/press/linux-foundation-announces-the-formation-of-the-agentic-ai-foundation — and Anthropic announcement — formation of the Agentic AI Foundation; MCP, goose, AGENTS.md as founding projects; platinum members AWS, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft, OpenAI. - BMS-RAG point-classification research (ScienceDirect 2026), as catalogued in the AISB interop research corpus — RAG+Brick point classification, six real-world datasets, near-100% F1 on some. - Market facts via AISB interop research synthesis (AISB 2026): Mapped cumulative funding $42.8M through Series B 2025-06 (Crunchbase 2025); KODE Labs $14M GSA contract, 150 federal buildings (public award); Trane Technologies completion of BrainBox AI acquisition announced 2025-01-03, 14,000+ buildings (company announcement).

Corpus documents (internal provenance, trailing window): - 2026-06-24.md · 2026-06-24.html · 2026-06-23.md · 2026-06-22.md · 2026-06-20.md · 2026-06-19.md - 2026-06-25/24/23/22/20/19/18/17-linkedin-signals.md - 2026-06-25-proptech-capital-vendor-survival.html - 2026-06-24-sensor-fusion-privacy-first-occupancy-stack.html - 2026-06-23-mv-2-0-non-routine-events.html - 2026-06-22-baas-portability-clause-data-layer.html - 2026-06-21-ai-chiller-rl-vs-mpc.html - 2026-06-20-bps-penalty-wall-2026.html - 2026-06-19-occupancy-analytics-18-point-gap.html - 2026-06-19-best-ai-building-management-systems-2026-compared.md - AISB CRE data-interoperability strategy synthesis (internal research, 2026-06-13)

Glossary (terms as used in this report):

• BMS/BAS — Building Management/Automation System: the control layer for HVAC and related plant. Knows what the building did; rarely knows who was in it.
• BACnet (ASHRAE Standard 135) — the dominant open transport protocol for building-automation data. Solves movement, not meaning.
• ASHRAE Standard 223P — the proposed (unpublished as final, as of this writing) semantic-interoperability standard for building data.
• Project Haystack / Brick / RealEstateCore — community semantic vocabularies/ontologies for tagging what building points mean; Haystack 5 introduced the Xeto schema language, and Brick is aligning with RealEstateCore (AISB interop synthesis 2026).
• Point mapping / semantic tagging — the labor of labeling each BMS point's meaning so software can use it; the "mapping tax" of Section 2.2.
• MCP (Model Context Protocol) — the open protocol by which AI agents connect to tools and data sources; foundation-governed under the Linux Foundation's Agentic AI Foundation since 2025-12-09 (Linux Foundation).
• Agent platform — as used here: a governed fleet of specialized AI agents sharing one audited knowledge layer, with provenance on outputs, cross-domain handoffs, and human-gated actuation — as distinct from a single-purpose point tool.
• IWMS — Integrated Workplace Management System; lease/space/portfolio administration.
• CMMS — Computerized Maintenance Management System; work orders and maintenance history.
• IPMVP — International Performance Measurement and Verification Protocol; the M&V discipline this report requires for any savings claim.
• M&V — Measurement & Verification: proving a delta against a baseline rather than asserting it.
• Green Button (NAESB REQ.21) — standardized, consent-based access to utility meter data via OAuth/REST.
• EU Data Act (Regulation (EU) 2023/2854) — EU law granting users of connected products rights to access and share the data those products generate; applicable 2025-09-12, with design obligations from 2026-09-12 (European Commission).
• OT / NIST SP 800-82 — Operational Technology and the NIST guidance governing its security isolation; the legitimate reason building networks resist casual cloud connectivity.
• Utilization vs. occupancy vs. attendance — this report uses attendance for people entering a site, occupancy for presence in a space at a time, and utilization for occupancy measured against capacity or target — the JLL 56% figure is a utilization measure (JLL 2026).
• Pilot purgatory — the recurring pattern (Section 2.3) in which a groomed-data pilot demonstrates value that portfolio-scale grooming costs then erase.
• Provenance — the evidence chain attached to an output: sources, standard, confidence, responsible party.

AI disclosure: AI-assisted research grounded in AISB's primary CRE corpus. Before publication this report passes AISB CRE-squad review, then C-level + Expert Council review, then a CLO legal-risk gate.