What an independent MSI's point database looks like to an LLM in 2026
By Yves Habchy · June 2026
"I call it the ontology Wars. It's like the clone Wars and star Wars."
Brian Turner (CEO, OTI; ex-CEO Buildings IOT), Nexus Labs podcast Ep #034
Update, 2026-06-07. I built a v0.1 alpha of the gateway layer described below. Code at github.com/Yveshby27/brick-bacnet-mcp. The article underneath is unchanged. It is the question; the code is one attempted answer. The conversation ask at the bottom is the part I care about most.
What changed between November 2024 and Q4 2026
Between November 2024 and the fourth quarter of 2026, four announcements changed what an independent MSI's point database is worth.
On November 12, 2024, Johnson Controls announced "the first customer-facing generative AI applications" in OpenBlue, integrated into the OpenBlue Enterprise Manager suite. The release framed it as "Integrated generative AI tools that proactively recommend impactful energy savings projects."
On October 21, 2024, Honeywell and Google Cloud announced a partnership titled "Honeywell and Google Cloud to Accelerate Autonomous Operations with AI Agents for the Industrial Sector." The deliverable was Gemini on Vertex AI bound to Honeywell Forge data, described as "Purpose-Built, Industrial AI Agents." The first solutions shipped to Honeywell customers in 2025.
Siemens has been shipping Building X with semantic enrichment and a built-in generative-AI query layer, sitting inside the Xcelerator marketplace.
And on October 27, 2025, Tridium published the Niagara 5 FAQ. Niagara 5 is in alpha now (Q1 2026), with early access in Q3 2026, beta at the end of Q3 2026, and general availability in Q4 2026. It ships with built-in AI for auto-discovery, fault detection, and system tuning. The Niagara Summit 2026 was themed around BMS plus Edge plus Cloud plus AI convergence.
Meanwhile, two things happened on the AI side of the table. ASHRAE Standard 223P, "Designation and Classification of Semantic Tags for Building Data," moved through the second half of its DOE-funded research term running October 2023 through September 2025. It is the first serious convergence answer to the Haystack-versus-Brick fragmentation. And the Model Context Protocol became the de facto pattern for exposing tools and data to LLM agents. AWS shipped its IoT SiteWise MCP server in September 2025. The broader AWS MCP server reached general availability on May 9, 2026. A solo developer named ezhuk has been maintaining a FastMCP-based BACnet MCP server, currently at v0.3.7, with four stars on GitHub. It exposes Read Property and Write Property tools at the BACnet protocol level over a Streamable HTTP endpoint.
The vendor agentic platforms keep their AI inside their own stacks. The MSI tier, meaning independent integrators running mixed-vendor portfolios across five to fifty buildings, has the point databases but no clean way to expose them in semantic-tagged form to whatever AI workflow a client wants to run.
The named pain
The first pain is vendor-bounded AI. An MSI running Alerton, Andover, Distech, and JCI in the same client portfolio cannot run OpenBlue across that portfolio. OpenBlue runs against JCI controls. Honeywell Forge agents lean into Honeywell-stack portfolios. Tridium is a Honeywell subsidiary, which absorbs the Niagara ecosystem upward but does not give the multi-vendor MSI a clean AI layer. Siemens Building X is "open" in marketing terms, but the semantic-enrichment layer is curated inside the Xcelerator partner program. The MSI's actual portfolio rarely looks like a single-vendor reference site.
The second pain is the semantic mapping work. Brian Turner has been on record about this for years. On Nexus Labs Episode 34, "Ontology Wars and the Role of the MSI," he framed the structural problem this way:
"we've got all these different, Really big thought leaders out there competing for how to classify data, how to name data, how to relate data."
"My client for the most part is not choosing an ontology. They're buying a solution. They're buying a set of use cases."
"at the end of the day, the ontology doesn't deliver any outcome. It only enables, right? It's not an outcome."
The MSI sits between vendors who each push their own stack and ontology, and owners who want outcomes regardless of stack. When a client picks an ontology, the MSI inherits the alignment work:
"if they said to us, that's great. I love haystack, but we're, really bought in to this new Microsoft thing. Then, then it's incumbent upon me to figure out how to align. Haystack with Microsoft."
The third pain has been the technical substrate underneath all of the above. Therese Sullivan, principal at BuildingContext and a Project Haystack contributing editor, has been writing about this in AutomatedBuildings since 2017. In her January 2017 piece, she described how the new semantic layer was forming:
"Brick Schema builds on the concept of tags from Project Haystack and enriches the schema with an underlying ontology that crystallizes the concepts defined by the tags."
What ASHRAE 223P is finally doing is consolidating that work into a BACnet-compatible standard the industry can target. But the alignment work between an as-built point database and any of those schemas is still done by someone. Most of the time that someone is the MSI.
The fourth pain is timing. AutomatedBuildings ran a two-part series on the changing MSI role in late 2025. Kelly Sinclair's November 27 piece, "The Rise of the System of Systems Integrator (the Instigator)," framed the new shape of the role. MSIs "instigate conversations and integrate technologies that have never spoken to each other before." The December 14 follow-up piece, "The Evolution of the Master Systems Integrator," went further:
"The role of the Master Systems Integrator (MSI) has fundamentally evolved from a project-based implementer to a strategic partner essential for portfolio success."
Clients are already asking about AI today. Niagara 5 native AI is not generally available until Q4 2026.
What is already tried
Each of the named vendor stacks solves the AI question inside its own controls portfolio. OpenBlue, Forge, Building X, and Niagara 5 do this. That is the strength and the constraint at the same time.
ezhuk's BACnet MCP server is the closest existing thing to the layer this article is about. It is a solo-maintained Python project on FastMCP 2.0. It exposes Read Property and Write Property at the BACnet protocol level over a Streamable HTTP endpoint. It does what it says, and it does not pretend to do more. An LLM agent connecting to it gets raw object-and-property pairs. There is no semantic normalization. If the agent is supposed to reason about the discharge air temperature sensor on AHU-3 in Building 7, it has to figure that out from device 1234 object analog-input 56 plus whatever the technician typed into the object name field a decade ago.
Open-source tooling covers adjacent slices. Eclipse VOLTTRON has a BACnet driver, but it is a platform commitment, not a drop-in for an MSI who already has Niagara stations running. Brick Schema and the Mortar testbed sit at the ontology and research dataset layer. Brick gives the target vocabulary, not the runtime ingest path. Project Haystack's tooling lives inside commercial products. SkySpark from SkyFoundry, FIN and Sedona from J2 Innovations, Niagara Analytics Framework from Tridium for Niagara-resident data.
Lynxspring ships a dedicated hardware appliance for the BACnet-to-Haystack bridge problem. The Onyxx BH311 Data Pump is a BACnet/IP, BACnet/Ethernet, and BACnet/MS-TP client that maps BACnet points into Haystack-tagged points, with browser-based configuration and per-point tagging. The fact that the pain is real enough that Lynxspring shipped a physical box for it is itself a data point.
None of these give an independent MSI a Brick/Haystack-aware BACnet/IP MCP they can put in front of their existing portfolio, so that an LLM agent, whichever one the client wants, can read the building in semantic terms.
The gap
There is a specific layer missing. It is read-only, Brick and Haystack and 223P aware, mixed-vendor by design, and consumable by any MCP host. The vendor agentic platforms ship that layer only inside their own controls portfolios. The open-source tools either work at the protocol level (ezhuk's MCP, VOLTTRON drivers) or at the schema and tooling level (Brick, Haystack, the Mortar testbed). Nothing in the middle does the runtime ingest and the semantic normalization at the same time.
Concretely, this would mean an LLM agent calling the gateway sees Building 7 → AHU-3 → discharge_air_temp_sensor rather than a BACnet device-object-property triple. It would work across an Alerton, Distech, JCI, Honeywell, and Tridium portfolio because BACnet/IP is the common protocol. It would stay read-only in the first version. Keeping write paths out keeps the compliance and liability surface narrow for small-commercial buildings. And it would drop into Claude Desktop, Cursor, or any MCP host the client's agent runs in.
This is not a Niagara native module. It is not a hosted fault-detection platform. It is not an OpenBlue replacement. It is the specific gateway layer the MSI tier needs, in the shape an MCP host expects.
The ask
I have been reading AutomatedBuildings.com, Nexus Labs, the BACnet Institute, the Project Haystack and Brick documentation, the ASHRAE 223P drafts, and the public material from JCI, Honeywell, Siemens, and Tridium. I am a software engineer, not a Niagara MSI. I do not run a building portfolio. I have not commissioned BACnet points. I have been reading this material because the pattern of where the vendor agentic stacks stop and where the integrator tier has to pick up looks like a specific gap that nobody is filling in the way the MSI tier needs.
I might be wrong about the shape of the gap. If I am, the people who would know are the independent integrators who actually do this work every week.
If you run an independent MSI shop with a five to fifty building portfolio, and the semantic mapping between BACnet point databases and whatever AI workflow your client wants to run is expensive enough that you have thought about how to automate it, I would like to compare notes. If you have already built or bought your way around this and have opinions about why what is out there is or is not enough, I would also like to compare notes.
The actual ask is twenty minutes. No demo. No waitlist. I have a v0.1 alpha at github.com/Yveshby27/brick-bacnet-mcp. It is research-instrument shaped, not a product. I am still earlier than "product." If I am wrong about the gap, I would rather find out from one MSI than from six months of building more of the wrong thing.
If you would rather react to working code than to a research note, that same alpha has a brick-bacnet-mcp --coverage-report command. Point it at one of your buildings and tell me what fraction of your point names the starter rule library actually tags. That is its own asymmetric twenty minutes.
You can reach me by LinkedIn DM or at yves.habchy@gmail.com. If a calendar link is easier, I will send one.