Every AI pitch in real estate now uses the same vocabulary: agents, automation, autonomous operations. Behind the shared language sit two very different products. One reads documents and answers questions. The other changes setpoints, issues work orders, and closes the loop. For asset managers and property owners deciding where to invest next, that distinction is the whole decision.
This post is a buyer’s guide to evaluating the difference.
The market sounds the same. The deployments don’t.
Walk the floor at any industry event this year and the messaging converges fast. AI for real estate, agentic proptech, autonomous building operations — the slide decks look nearly identical.
The deployed reality is harder to find on a slide. What we consistently hear from landlords is a familiar pattern: building systems remain fragmented, AI features bundled into incumbent platforms sit largely unused, and the AI that does get deployed lives off to the side — a language model connected to a document archive, answering questions about it.
That is a useful capability. A team that can query lease archives or O&M manuals in natural language saves real time. But it leaves the operational core untouched. The chiller still drifts. The ticket still waits. The work order still gets dispatched by a human who noticed something too late.
What “agentic” actually requires
A genuinely agentic platform does not stop at surfacing an anomaly. It reasons to a root cause, scans related systems for connected issues, determines the appropriate response, and executes it — whether that means pushing a scoped work order with full diagnostic context, or issuing a command directly to building systems within defined authorisation.
Three problems keep most AI at the conversational level rather than the operational one.
- Data fragmentation.
Building systems from different vendors use different protocols and naming conventions. A chiller in one system may be identified by a floor number, in another by a serial code. An AI that cannot reliably identify what it is looking at cannot safely change operational states.
- Execution access.
Reading sensor data is different from writing to a building management system. Identifying that a zone is overcooled is different from adjusting the setpoint. Solving the first does not solve the second.
- Governance.
Autonomous action without traceability, permissions, and audit trails is not something most property owners will deploy at scale — and that is good judgment. But in more advanced markets, this problem is being solved now, and the organisations solving it are pulling ahead.
What serious buyers are evaluating in 2026
The evaluation criteria have shifted. CRE teams are no longer comparing dashboards. They are assessing whether a platform can close the loop — detect, diagnose, decide, act, and log — across a portfolio of buildings.
Portfolio-level scalability without headcount growth is the commercial test that matters most. Legacy analytics tools were designed to make expert operators more efficient. In practice, they often made them busier — generating alert volumes that became their own operational burden, requiring the same experienced building operators who are retiring faster than they can be replaced. A mid-size commercial portfolio running a legacy analytics platform might surface hundreds of fault alerts per week. Some are critical; most are noise. Distinguishing between them still falls on a human.
The right platform inverts that model. A smaller team can oversee a larger asset base because the agents are handling the triage, the diagnosis, and in many cases the resolution. That is a different cost structure — and a different asset management proposition.
Financial connection to NOI is the second test. Sustainability metrics matter, but owners need to know what a platform does to net operating income: reduced energy spend as a percentage of OpEx, avoided capital expenditure from predictive maintenance, improvement in asset value from consistently higher operational performance. Platforms that lead with dashboards but cannot connect their output to the P&L are increasingly being passed over.
Explainability is the third. A platform engineering teams do not trust is one they will work around. Operators need to follow the reasoning behind any action — what the platform observed, how it diagnosed the issue, why it responded as it did. Teams that can follow that logic develop confidence in the platform’s judgment over time and progressively expand the scope of what they delegate to it.
Why the data model decides what the AI can do
The reason most AI in real estate stops at answering questions is rarely the quality of the model. It is the substrate underneath.
To act, an agent needs a machine-readable map of the building — which sensor serves which system serves which space — plus live read access to operational state and authorised write access to change it. A language model pointed at a folder of PDFs can only ever talk about those PDFs.
ProptechOS provides that substrate through RealEstateCore, an open semantic data model for real estate developed in the Nordic market and now running on Microsoft Azure globally. Every device, system, and space across the portfolio is represented in one semantic model, so an agent reasoning about a fault in one building applies the same logic in the next. The digital twin is the map; the platform’s verified integrations are the hands.
This architecture also enables attribution — when an agent changes a setpoint or closes a work order, the platform records the action and ties the resulting energy or cost delta to it. Conversational AI has nothing to attribute. Outcome-based commercial models do.
What this looks like in production
At KLP Eiendom’s Eufemia building in Oslo — a BREEAM-NOR Excellent certified office complex housing Microsoft and PwC — ProptechOS analytics detected a ventilation configuration fault invisible during normal business hours. Demand-controlled ventilation features built into the system were not operating as intended, causing the building to process 262 million cubic meters of air annually during off-peak hours. Once identified and corrected, off-peak air processing dropped by 31%, delivering 292,000 kWh in annual energy savings — approximately 7.5% of total building energy consumption — and around €60,000 in annual cost reductions. No new hardware required.
Read the Eufemia case study: https://proptechos.com/case-studies/energy-reduction-eufemia/
At Vasakronan — Sweden’s largest commercial real estate company, with 168 properties across 2.4 million square metres — running the ProptechOS Optimize application reduced district cooling and heating costs by 36% at Kista Science Tower, with plans to extend the approach across the broader Stockholm portfolio.
Read the Vasakronan case study: https://proptechos.com/case-studies/proptechos-optimize-application-contributes-to-vasakronans-energy-optimization/
At Locum, Region Stockholm’s healthcare property company, the shift has been structural. Hospitals generate alarm volumes no team can triage manually — and a missed fault in that environment does not just affect a building, it affects patient care. With ProptechOS unifying data from SCADA, FM platforms, and sensor networks, AI agents now monitor building systems against 85 KPIs across 113 data points. A Supervisor Agent filters output before it reaches the FM system. An Executor Agent closes the loop on work orders requiring no site visit. A regulatory inspection report that previously needed a two-day consultant engagement now takes four hours.
Read the Locum case study: https://proptechos.com/case-studies/locum-ai-agents-hospitals/
These are operating results measured in kilowatt-hours and closed work orders — the kind a question-answering layer cannot generate on its own.
How ProptechOS is built for this
The evaluation criteria above — integration across infrastructure, portfolio-level scalability, financial connection to NOI, explainability, and time to value — describe the operational reality ProptechOS was built around.
The platform connects buildings through RealEstateCore, an open semantic data model for real estate developed in the Nordic market and running on Microsoft Azure globally. Every device, system, and space across a portfolio is represented in one model, so an agent reasoning about a fault in one building applies the same logic in the next. That shared foundation is what makes the results from Eufemia, Vasakronan, and Locum transferable rather than one-off.
Every action an agent takes is logged and attributable. Engineering teams can follow the reasoning behind any recommendation — what was observed, how it was diagnosed, why it responded as it did. That traceability builds the operational trust that allows organisations to progressively expand what they delegate to the platform over time.
Eight questions to ask any AI vendor
The test is not whether a vendor uses the word “agent.” It is what the agent can do after it produces an answer.
1. Can the agent write back to operational systems, or only read from them?
2. Can it create and route a work order automatically?
3. Can it adjust a setpoint under defined permissions?
4. Can it verify the result of its own intervention against live sensor data?
5. Is every action logged and attributable to the specific agent that took it?
6. Does the system understand relationships between assets, spaces, systems, and operational data — or does it reason from documents alone?
7. Can it operate consistently across a portfolio with multiple buildings and vendors?
8. Are permissions, policies, and human oversight built into the execution model from the start?
A platform that cannot answer yes to most of these is an interface, not an operating capability.
The question to ask your current vendor
After your AI produces its recommendation, what happens next — and who does it?
Explore how AI agents perform operational work across a live portfolio, or contact our team.
