AI Agents Can Now Build and Test Building Energy Models From Plain Language

A building’s lifetime energy bill is largely decided before anyone pours a foundation. Choices about form, envelope, equipment, controls, and operation lock in performance years in advance, and building energy modeling is the discipline that prices those choices before construction. Now researchers at the National Laboratory of the Rockies, working for the U.S. Department of Energy, have unveiled a system that hands that entire modeling workflow to artificial intelligence agents. The software, called OpenStudio-MCP, is described in the journal SoftwareX and lets large language models create, modify, simulate, and diagnose physics-based building energy models from nothing more than a plain-language request, with no human writing code at any point.

The open-source EnergyPlus engine, developed by the Department of Energy, performs the underlying calculations that predict how a design will perform. Most tools operate on its text input files, but practitioners typically work one layer up, in the OpenStudio software development kit, which provides a typed model structure and a library of reusable transformation scripts known as Measures. The new server deliberately builds on that SDK layer rather than raw input files, because the typed object structure is more composable and less error-prone to manipulate, and it connects AI agents to the broader ecosystems of OpenStudio-standards, ComStock, and the Building Component Library. Earlier protocol-based servers, such as EnergyPlus-MCP, work only at the input-file layer and defer geometry creation and HVAC loop construction to future work; OpenStudio-MCP tackles the full lifecycle from creation through simulation and evaluation.

The technical heart of the system is the Model Context Protocol, introduced by Anthropic in late 2024, which allows a language model to drive external software by calling validated, schema-typed tools instead of emitting free-form code. OpenStudio-MCP exposes 197 such tools, organized into self-contained skill modules that are discovered automatically at startup. They span model creation, geometry and thermal zoning, construction and schedule assignment, HVAC synthesis, simulation control, results extraction, quality assurance, and even large-scale parametric analysis on OpenStudio-server. A single call to add_baseline_system, for example, wires a complete air- and plant-loop topology corresponding to one of the ten baseline system types defined in ASHRAE Standard 90.1 Appendix G, a task that has historically required careful manual scripting.

Because language models can call operations out of order, select unsuitable systems, or simply invent SDK methods that do not exist, the server wraps the SDK at two levels. Low-level tools expose explicit OpenStudio operations as typed calls, while higher-level tools encode common workflows such as whole-building creation, baseline HVAC assignment, and result extraction. A separate knowledge layer serves curated workflow guides covering object dependencies, ASHRAE system-selection rules, and Measure authoring, which agents retrieve on demand. The server also guards against the finite context window of any language model: instead of dumping a 5,000-space model or a full 8,760-hour annual result into the conversation, it returns compact structured summaries, previews models without loading them, and distills entire simulations into a handful of summary numbers while the model files themselves remain server-side.

Perhaps the most striking capability is automated Measure authoring. Measures are programs, and extending analysis beyond the off-the-shelf library has traditionally required engineers to double as software developers, putting custom analysis out of reach for many architects and engineers who best understand the building. With OpenStudio-MCP, an agent scaffolds a new Measure from a plain-language request, writes its logic, runs its tests, and applies it inside a sandboxed environment that runs child processes as unprivileged users under a fail-closed Landlock filesystem policy, a seccomp filter denying outbound network access, and strict resource limits. The authors stress these are implemented controls rather than security guarantees, since the software has not undergone a formal external penetration test, but targeted adversarial probes using canary listeners and decoy secrets exercised cross-tenant file reads, environment-secret capture, filesystem escapes, and forged transfer requests.

To demonstrate the system end to end, the researchers gave an AI agent a natural-language request specifying a medium office building, its location, a baseline HVAC system, a comfort criterion, and a four-pipe active-chilled-beam retrofit, naming no tools. Working from an empty session with Claude Opus 4.8, the agent created and simulated a 27-zone, three-story, 53,600-square-foot office using the ASHRAE 90.1-2019 template with a variable-air-volume reheat system. The initial model narrowly failed the comfort criterion with 301.7 occupied unmet hours. Digging into sizing reports, the agent found that heating capacity was adequate but a 50 percent reheat-mode airflow cap was constraining morning warm-up after nighttime setback, raised the cap on all 27 terminals, and brought the model to 78.0 unmet hours at a site energy use intensity of 42.4 kBtu per square foot, squarely within the middle half of the observed U.S. office stock from the 2018 Commercial Buildings Energy Consumption Survey.

The agent then authored a Measure that replaced each terminal with a four-pipe beam connected to the existing chilled- and hot-water plants, verified SDK class names, passed its own tests, and validated 27 beam terminals with no errors, all without a human writing or reviewing code. The retrofit maintained comfort but increased site energy by 8.7 percent, driven by a 179 percent surge in fan energy, because the constant-volume beams forfeited the variable-volume air handler’s part-load fan savings and economizer hours. Crucially, the agent reported this adverse result, explained both mechanisms, and proposed remedies including a right-sized dedicated outdoor air system with energy recovery. The session used 98 calls to 36 tools, three annual simulations, and roughly 21 minutes, with no human intervention after the initial request.

Feasibility is not reliability, so the team built a reproducible benchmark of 16 graded tasks across six families, tested with Claude Opus 4.8, Opus 4.6, Sonnet 4.6, and Haiku 4.5 alongside GPT-5.4 and GPT-5.4-mini. Each trial was graded by two deterministic checks without any AI judging: whether the agent called an acceptable tool, and whether the saved model passed physical checks such as assembly R-values, HVAC loop membership, and pinned EnergyPlus outputs. The distinction proved essential, because in 18 of 23 outcome failures an agent replaced a roof assembly with one up to 1.86 square meters kelvin per watt worse while reporting success, an error visible only in the saved artifact, not in the agent’s confident report. Under a common configuration with all tool schemas loaded, GPT-5.4 and Opus 4.8 achieved 100 percent outcome rates, with Opus 4.6 at 95.8 percent, GPT-5.4-mini at 93.8, Sonnet at 91.7, and Haiku at 85.4.

The ablation results carry a practical lesson for anyone deploying agentic AI. Loading every tool schema up front raised the weakest model’s success rate by 12.5 points but inflated costs by 36 to 68 percent for stronger Claude tiers while changing outcomes by at most two tasks, meaning deferred schema discovery saves money for capable models at no accuracy loss. The curated knowledge layer, surprisingly, changed no model’s completion rate by more than 6.3 points. The completion budget also mattered: at a 120-second limit, 17 of Opus 4.8’s 18 failures were timeouts, yet it passed every trial in four of five configurations when given 600 seconds, showing that slow but productive work was being misclassified as failure. An unscaffolded baseline without the server showed agents can handle basic OpenStudio operations through direct scripting, but both tested models failed a task requiring exact counting of warnings in an EnergyPlus error file.

The researchers frame the work as broadening access rather than replacing rigor. Engineers and architects could request, test, and run bespoke retrofit analyses without writing Ruby, while organizations could offer shared modeling capacity to design firms, classrooms, or utility programs by issuing authentication tokens instead of provisioning workstations, turning energy modeling from a per-seat desktop activity into shared infrastructure. Validation and quality-assurance tools, audit records of every tool call, and artifact-based grading make the checking explicit, but the authors are careful to note that engineering judgment is not automated: generated artifacts and conclusions require review by a qualified practitioner before use in real engineering decisions. The code, benchmark harness, and archived trial records are openly available under a BSD-3-Clause-style license, inviting the building science community to put AI-driven modeling to the test.

Subject of Research: An open-source Model Context Protocol server enabling AI agents to perform full-lifecycle building energy modeling with the OpenStudio SDK.

Article Title: OpenStudio-MCP: a model context protocol (MCP) server for AI agent-driven building energy modeling with the OpenStudio SDK

Article References: Ball, B. L., Long, N., Fleming, K., & Goldwasser, D. (2026). OpenStudio-MCP: a model context protocol (MCP) server for AI agent-driven building energy modeling with the OpenStudio SDK. SoftwareX, 36, Article 103020. https://doi.org/10.1016/j.softx.2026.103020

Image Credits: AI Generated

DOI: 10.1016/j.softx.2026.103020

Keywords: OpenStudio-MCP, building energy modeling, Model Context Protocol, large language models, AI agents, EnergyPlus, OpenStudio SDK, HVAC synthesis, Measure authoring, ASHRAE 90.1, agent benchmark, sandboxing