Calculate your proptech boost!
Sign in
Free trial
Book demo

Frequently Asked Questions

FAQ about ProptechOS and RealEstateCore

Book a demo
Free trial

Getting started with ProptechOS

After signing up and signing in, starting to use ProptechOS follows a simple process:

  1. Onboard Building. If your use case requires just a few rooms, you can probably create them manually by yourself, and if you need an entire building you can use a blueprint to do it at scale. ProptechOS Onboarding will help you with the end-to-end process.
  2. Data source. Identify suitable existing devices for your use case.
    (If needed, procurement and installation of complementary IoT devices are done by an external vendor in coordination with ProptechOS.)
  3. Onboard Devices. A simple use case with just a few IoT devices can be set up manually and an entire legacy system can be onboarded using a taglist. ProptechOS Onboarding engineers can do both quickly. To finally get going, access for ProptechOS to connect to your devices is set up.
  4. Data from IoT devices, BIM, Building Management Systems and business functionalities are collected in ProptechOS. You are now ready to use ProptechOS.

Onboarding means getting your systems modelled in RealEstateCore and ready for apps and agents. Two things have changed the speed of this. First, System Machinea — an embedding model we trained from scratch on millions of hand-modelled tags — takes a new tag list, places each tag in that map, and returns a confidence score, auto-mapping the clear cases and flagging only the uncertain ones for review. Second, an onboarding agent runs the end-to-end process under zero standing privileges: it requests scoped access for the specific building, models the tags, validates the result, and hands back a summary. Recent examples give a sense of scale: around 17 buildings with 17 systems onboarded in roughly three hours, and about 1,000 buildings with 13,000 sensors in a single week. The main variable now is getting early access and the right contacts on your side; the modelling itself is a small part of the project. A dedicated onboarding engineer works with you throughout, and validation is done together with you.

A building is onboarded to ProptechOS and modelled in RealEstateCore. A building is made up of storeys, rooms and assets in rooms (e.g. a phonebooth, a desk, other furnishing, etc.). Buildings can also have zones which span one or multiple rooms or a specific area within a room. Additionally devices,  sensors, actuators and alarms can be placed in a room or at a specific coordinate in a room. Other building components like terrasses, roofs etc. have RealEstateCore representations and can be onboarded to ProptechOS. A building belongs to a real estate which is a legal object consisting of one or several buildings or pieces of land. All building components can have a geometric representation so that they can be found by coordinates and visualized in 2D or 3D. Based on these components the customer can build up their applications. For more details visit https://www.realestatecore.io/

ProptechOS is a SaaS cloud solution. ProptechOS itself does not require any hardware.

However, some legacy systems in buildings cannot connect to the internet. In such cases ProptechOS will install a physical Connector server on site that will serve as an uplink to ProptechOS platform. Many times, it is possible to use a cloud-based Connector, or a Connector on a virtual server on the customer local network.

There is no limit to how many users you can invite to your ProptechOS. Users may be assigned roles with pre-selected access and permission rights.

ProptechOS has a range of support options:

  • Email: Just send ProptechOS Onboarding [email protected] a note and our onboarding engineers will get right back to you.
  • Webinars: Many of the core use cases are described in a webinar here in the Resources section
  • RealEstateCore community – If you wonder about how to best use RealEstateCore, you can also also find your answer at realestatecore.io or the RealEstateCore community.

Yes, definitely!

  • Just click the plus-sign in the bottom right corner to create any object in your ProptechOS – Building, Room Sensor etc.
  • Choose “Onboard” > “Blueprint” in the top bar to onboard a whole storey or building using a DWG file.
  • Choose “Onboard” > “Tag list” in the top bar to onboard a whole system of devices using a CSV file.

Onboarding using Blueprints or Tag lists does require processing the DWG or CSV files so that they have the necessary information and the proper format. ProptechOS Onboarding team will help you get started.

Agentic Proptech and AI agents

Agentic Proptech is AI for real estate that is built to act, not just to answer. A generative AI assistant tells you what it found; an AI agent does the work — it senses data, reasons about it, decides within the limits you set, and acts, on a schedule or when something changes. ProptechOS is the layer that lets these agents work safely on top of the systems you already run. Your BMS, facility management system and ERP remain your systems of record; ProptechOS is the system of action layered above them, so agents can read the same data and take the same actions your team would, with guardrails and a full audit trail.

Generative AI is an assistant. You ask a question or hand it a document and it generates an answer, a summary or a dashboard in minutes — but you stay in the loop and drive every step. Agentic AI is a digital colleague. You give it an objective and it works for you — checking your water consumption every morning, guarding against power peaks around the clock, or triaging incoming tickets before a human sees them. The assistant reduces work from weeks or hours to minutes; an agent can reduce recurring work to zero human time, because it runs on its own once you have set it up.

Every agent has three parts, and it is worth keeping them separate:

  1. A system prompt — the agent’s role, objectives and instructions. This is what it should do. You edit it in plain language, and the agent’s behaviour changes with it.
  2. Permissions — what the agent can do. This is enforced separately from the prompt, with watertight guardrails, so an agent only ever reaches the data and tools it is meant to. We never leave it to the agent to decide what it is allowed to do.
  3. Triggers — when it runs. A timer (for example, every night at 02:00), an event, a change in data, or a message from another agent.

We use four archetypes that are becoming established across the industry:

  • Oracle — a generalist with a wide view over your data. It answers and oversees, much like chatting with a general AI model. Good for questions such as which tenant might churn or where the biggest energy waste sits.
  • Expert — the most common worker in a team of agents. An expert in one skill (say, analysing return temperature on district heating), not in one building. It knows exactly how to gather, analyse and act on data for a specific task or process.
  • Embodied — an AI that represents something physical, such as a building or a system. A building agent can run a health check each morning and flag anomalies or an unusual volume of alarms.
  • Task runner — a small, cheap, single-purpose model that runs constantly and never tires. It does simple monitoring and hands off to an expert colleague when something needs deeper analysis.

 

For automating your own processes, experts and task runners are the two main tools. You are probably already interacting with an Oracle.

Morgan Stanley estimates that around 37% of tasks in real estate can be automated with today’s technology — not in five years, today. We have mapped roughly 290 distinct processes across real estate and facilities operations, from lease management to pest control to elevator monitoring. Our library of expert agents currently covers around a quarter of them, and it grows continuously — most of that library did not exist six months ago, because the technology did not. The practical question is no longer whether this matters, but where you should start.

All of our own agent prompts are open source and published in the ProptechOS Agency, together with an agent prompt guideline. Because an agent is essentially a description of a work process, there is little reason to keep the generic ones proprietary. You can browse them by what they do and whether they only monitor data or can also control systems, and the Agency is available in several languages. Some customers keep their own agents private where the process encodes their specific expertise; others choose to share them with peers. See the  Agents page and the  ProptechOS Agency for the current library.

Through the same secured path as everything else in ProptechOS. Agents use our MCP interface to reach the data and tools in the platform, all modelled in RealEstateCore, so a presence sensor in a room has the same name across every building in your portfolio. That shared vocabulary is what lets an agent reason across ventilation, occupancy, energy and weather data without hallucinating. An agent works on your data in your data layer — not on a third party’s API — and it does so with its own identity, its own permissions and full logging.

No. You describe what the agent should do in plain language, and you can use your own — the models understand Swedish, Danish, German and more, and can handle a mix (for example, an English system prompt with your additions in another language). You do not need to get the agent perfect on the first try. You start with tight guardrails, review what it proposes, and refine the prompt over time until it earns more responsibility — much like onboarding a new colleague.

Yes. Agents work as a team, in hierarchies, and with humans when needed. A simple task runner can monitor incoming telemetry or tickets and call in an expert when it detects something worth a deeper look. An expert can escalate to the agent that represents a building, which can in turn escalate a decision to a human. In one demonstration of peak shaving, an energy expert first throttled EV chargers, then — when that was not enough — proposed lowering corridor heating, handed the plan to the building agent, which presented it to a person for approval before a supervisor agent carried it out. Three agents working within their own bounds, with a human approving the decision.

It means the agent prepares, analyses and proposes, but a person approves anything beyond what the agent is permitted to do on its own. You decide where that line sits. Early on, you might instruct an agent to analyse and suggest but never change a set point without asking you first. As you build confidence, you let it act autonomously on lower-stakes tasks. Approvals are visible in one place, so if you review five overnight proposals each morning you quickly learn how the agent behaves — and you can tighten or loosen its limits from there. You are always responsible for the agents that work for you.

A useful analogy: the tools an agent reaches through MCP are the kitchen — all the utensils and ingredients it needs. A skill is a recipe — a description of how to use those tools to get a specific result, such as a stuck-damper analysis. Without a skill, an agent has to work out the method itself each time, which is slower. With a skill, it can go straight to a reliable result. Skills are an area moving very quickly, and it is part of what makes agents both faster and more consistent.

Today, most agents are best thought of as a goldfish: they wake up, quickly gather all the data they need, do their work, and do not carry familiarity from one run to the next. That is why an “expert” is an expert in skill, not in accumulated knowledge of a particular building — it knows exactly how to gather, analyse and act, and re-reads the current data each time. Persistent, developing memory for agents is improving, and memory-capable models are starting to change this, but the design principle remains: reasoning and method live in the agent; the facts live in your data.

Results depend on your buildings, systems and data, so treat these as single-deployment examples rather than guaranteed outcomes. In one customer deployment, an early version of our nighttime ventilation analysis identified around 290 MWh per year of avoidable ventilation waste — roughly €60,000 per year at that site. The first time, that analysis took about two weeks of manual work; as an agent it now runs autonomously every night, so no one has to repeat it. In another large building, correcting ventilation set points cut air flow by around 30%. The pattern that makes this possible is reasoning, not fixed rules: in one run, the agent found a faulty presence sensor and, on its own, used a working CO₂ sensor to infer occupancy instead.

Agent security, permissions and governance

Agentic security builds on the data and IT security you should already have — identity, access control, encryption, network security — and adds two new avenues to manage. First, an agent is a new, capable but inexperienced actor with privileges: someone without direct access to data or actions could try to convince an agent to do something it should not. Second, an agent could drift beyond what it was instructed to do. We manage both by tightly controlling permissions and guardrails, and by logging everything. 

The principle is minimum privilege and minimum agency: an agent gets access only to the specific data it needs and only to the specific actions it must take — nothing more. We have moved to zero standing privileges and just-in-time access. Before an agent does anything, it has no access at all. When it needs to work, it declares exactly what it intends to do, with a reference to a legitimate task, and receives temporary permission scoped to just that work — which is then revoked. Agents are treated like digital employees: each has its own identity, so its actions can be traced to it, just as a person carrying out physical work needs a work order to enter a space.

Keep track of the risk level of each AI system you run. The EU AI Act defines four levels — minimal, limited, high and unacceptable risk — and in ProptechOS we assess each agent on its own. Most building use cases fall into limited risk (for example, an agent reading data or adjusting a heating or cooling set point). A smaller number, such as controlling elevators or locks, fall into high risk and warrant extra oversight. This applies to any AI component, not only agents — a smart optimisation system likely falls under the Act too. This is a summary to help you frame your setup, not legal advice; confirm your obligations with your own compliance team.

Yes, and for anything above minimal risk this is a need-to-have, not a nice-to-have. Every agent has an identity, and every action it takes is logged — what it did, when, and what the outcome was. Because current agents are language models, what they read and produce is text, which makes it straightforward to keep exact records: who set the agent up, who edited its system prompt, when it spoke to another agent, and who tasked it to act. That gives you an audit trail that reaches into the organisation and setup of the agents, not just their outputs.

Agents increasingly live outside the platform — in a vendor’s system or in your own tooling. For work done inside ProptechOS, we take full responsibility: everything is logged and auditable. For external agents, we ensure there is no access that is not tied to a specific identity. An external agent can be registered with its own identity in ProptechOS, and any action it takes — controlling a set point, changing data, turning something on or off — is logged with exactly who did it and what the result was. Shared conventions for tracing agent-to-agent work across systems are still emerging across the industry.

Group and organise agents the way you would any workforce, so you can apply the right policy at the right level. We organise both by structure — region, team, or the responsible technician — and by seniority: many low-risk task runners managed and audited as a group; experts per domain or region; and a small number of supervisor or executive agents that may hold higher privileges and carry a stricter policy framework. This keeps a growing team of agents auditable and maintainable as it scales.

Suitability/ Usage

ProptechOS is built for new and old buildings – enabling greenfield and brownfield Internet of Things. The majority of typical property portfolios are existing or old buildings. ProptechOS Onboarding engineers are experts at onboarding buildings that do not have a full featured BIM model and integrating legacy Building Management Systems. If the building is new, it will probably have a BIM model that will make onboarding easy, and enough sensors installed on site to support most use cases. An older building can be improved, optimized and automated with ProptechOS but might need complementary sensors to support some advanced use cases. If this is the case, ProptechOS will make sure that suitable IoT devices are installed in the buildings.
ProptechOS is suitable for any number of properties. It can even be run on a single building. Scalability of IoT has been a major motivation for developing ProptechOS, but apps and partner apps can deliver value on anything from one to 500 buildings in a portfolio.
ProptechOS is suitable for both commercial, residential and industrial portfolios. The only prerequisite for a successful implementation of ProptechOS is to have enough sensors and data points in your buildings to bear the use cases you are interested in.

Functionality

Yes. All data from buildings is saved continuously on ProptechOS during the time that the building is connected to the platform and will be saved long term. Data can be exported from ProptechOS. Historical data from before the building was onboarded may be added to ProptechOS upon request.
Yes. Telemetry data is instantly available in ProptechOS – either in the UI, the API or via the streaming API. Typically, telemetry that arrives to ProptechOS is available in the stream or API within 80 milliseconds (median latency is less than 10 ms).
Yes. ProptechOS has a state model embedded in the knowledge graph. Via the UI or the API, the state of each connected device is easily and instantly available.
Yes. ProptechOS turns all onboarded buildings with devices into smart buildings that can be controlled by users or certified applications in a safe and scalable way. This can be used to have rooms automatically adjusted before and after meetings, for letting your buildings help the energy grid by participating in demand-response programs or for a Machine Learning application to optimize the energy consumption of the building.

ProptechOS adopts the RealEstateCore API, which is open source. You or your IT partners can write any application on top of the API. To help you, ProptechOS has a suite of documentation, and code open for anyone to use. You are dependent on ProptechOS for your implementation. ProptechOS created and founded RealEstateCore but the community has grown beyond ProptechOS, with additional docs and tooling.

Yes, there are two ways to export data from ProptechOS. Extracting single time series by downloading them directly in the UI sensor view. Contact ProptechOS Onboarding if you are looking to export data for a very long time or for a large set of sensors.

To ensure data integrity, ProptechOS is restrictive about editing or writing historical telemetry  data (sensor observations are only written into ProptechOS via the edge interface and with valid device ids and device secrets). Therefore, users cannot yet import historical data for ingestion or update. This feature is coming, but in the meantime, just reach out to [email protected] and they will help you in a safe way.

Workflows is like If-This-Then-That for large-scale proptech, consisting of a Trigger (the source), routing, and a Dispatcher (the outcome).

You can re-use a trigger for multiple Workflows or have a single Workflow Dispatch to multiple destinations (multiple Dispatchers).

Some examples of workflow scenarios are:

  • If the elevator malfunctions, send a Critical severity alarm to the local technician and create a work order in the facility management system.
  • If the temperature in any conference room falls below 16°C or above 25°C send a Major alarm to the technical manager responsible for the building.
  • If a noise meter registers a peak during office hours, send an SMS to the account managers of the affected tenants, so that they can anticipate and prevent a bad tenant experience
  • If a percentage or number of devices flatline or go offline, send an alarm to the responsible technician to troubleshoot
  • If the utilization of a tenant unit has been 50% higher than normal over the last 2 days, create a work order to perform cleaning earlier than normal.
  • If the utilization of a site is 25% lower than usual send a request to adjust conference room prices

Technical functionality

ProptechOS uses a graph database for the RealEstateCore knowledge graph, a scalable blob-like storage for historical data and an actor-based model for hot and real-time data.
In the situation that the PLC/DUC would lose contact with the network, vital functions will continue to work, for instance, using the last read value (eg. outside temperature) or if needed they will go back to default values. If the system directly above ProptechOS loses contact with ProptechOS, any possible overrides will return to default mode.

Data and security

ProptechOS data can only be accessed via controlled interfaces. Hence, the security of the data at rest is only subject to the general internal security practices of the ProptechOS organization and the overall security of Microsoft Azure. ProptechOS’ Microsoft Azure resources are compartmentalized for different customers.
ProptechOS does not have any claim over customers’ building data or telemetry, neither onboarded data nor data generated while using ProptechOS. The customer agreement states that the customer and not ProptechOS is the data owner. The Customers may export data at any point.
The data you onboard to ProptechOS or the data generated by using ProptechOS is not used for anything else or by anyone else than you. The customer and not ProptechOS owns the data. ProptechOS has no right or intention to use your data elsewhere.

General questions

With RealEstateCore and your sovereign data ownership, you can rest assured to not be locked in. ProptechOS adopts RealEstateCore which is an open source standard describing how data from different systems should be classified and structured. ProptechOS follows RealEstateCore in the edge interface, the knowledge graph and the API.

  • Your Edge integrations into ProptechOS will work on any other system adopting the RealEstateCore edge interface.
  • Your App integrations on ProptechOS will work on any platform adopting the RealEstateCore API.
  • The data that is onboarded to ProptechOS can be exported and be imported with reasonable effort into any platform adopting the RealEstateCore ontology.

That is to say, ProtpechOS is built to be replaceable. Furthermore, RealEstateCore is developed to automatically be converted to other established standards at a very low cost, as it is based on standardized RDF semantic web technology. Consequently, using RealEstateCore and ProptechOS prevents vendor lock-in.

RealEstateCore is a leading global standard for Real Estate-related data. It is a description of how data from different systems should be classified and structured using semantic data technologies. It is the common “language” for smart buildings that provides increased control and accessibility of data.

ProptechOS created the first version of RealEstateCore, was among the founding members of the RealEstateCore Consortium and continues to work on the board and technical committees of RealEstateCore. RealEstateCore is published as open source, free for anyone to download and use.

RealEstateCore has collaborations with other important standards in the real estate related areas like BIM, control and monitoring, IoT and business data. Such joint work has resulted in official alignments with BRICK Schema, W3C BOT and ASHRAE, to bridge them together.

ProptechOS is built to be the best implementation of RealEstateCore and to realize the potential of the RealEastateCore ecosystem.

RealEstateCore is the designated domain-specific ontology for smart buildings in Azure Digital Twins. 

Azure’s Digital Twins Definition Language (DTDL) is used by developers to define entities used in the knowledge graph of Azure Digital Twins. However, because the DTDL can model any entity, there is a need for domain specific ontologies which are tailored to, for instance, real estate management. This is where RealEstateCore comes in. RealEstateCore is preloaded in Azure Digital Twins. More information: Azure/opendigitaltwins-building: Open Digital Twins Definition Language (DTDL) RealEstateCore Ontologyand Microsoft unlocks the full potential of the smart building ecosystem

ProptechOS is built on top of Microsoft Azure’s platform in close cooperation with the Azure product development team and takes full advantage of Azure’s high capacity and availability.

Since all buildings, systems, and apps are encoded in RealEstateCore, an alternative to ProptechOS can be used.

  • Investments in integrations to buildings and systems are still valid
  • Investments in applications are still valid
  • All data is owned by the client
  • All data is accessible via the API (without consent or cooperation from ProptechOS) and can be regressed in bulk with the cooperation from ProptechOS Onboarding.

If you want to cease using ProptechOS, you can get your data to use independently of ProptechOS. Your edge and application integrations can continue to be used if you switch to another platform that adopts RealEstateCore. If you switch to a non-RealEstateCore platform you can translate the ontology (it is already aligned to BRICK, Ashrae and W3C:BOT) and migrate the integrations efficiently.

Partner Support

For support with mapping sensors in RealEstateCore contact [email protected]. The Onboarding Team will need a list of your sensors to provide sensor mapping support.