Thermal Zoning That Explains Itself: Inside the Zoning Agent Built on Buildings AI

The missing middle layer

A building enters BuildingsAI as geometry exported from the architect’s authoring tool, and leaves as an energy model. Both ends of that journey are well served. Import works. Simulation works. In between sits a step that is neither automated nor enjoyable: deciding which spaces belong to which thermal zone.

Thermal zoning is one of the first real design decisions on a project, and it shapes everything downstream - load calculations, system selection, and the simulation itself. It is also tedious. A mid-size floor can hold dozens of spaces that must be grouped, so each zone could plausibly share a single thermostat, and the exercise repeats floor after floor. The rules are easy to state and fiddly to apply same floor, compatible loads and schedules, matching solar exposure, conditioned kept apart from unconditioned, special rooms on their own, sensible zone sizes.

Most tools offer one of two options: draw every zone by hand or accept an automatic result - one zone per room, one zone per floor - that no engineer would put their name on. The second is fast and useless, and it is worth being precise about why. The problem is not that the zones are wrong, exactly. It is that they cannot be defended. Zoning output is judged by whether a reviewing engineer can look at a zone and immediately see why those spaces are together.

We built the Zoning Agent to fill that gap. What follows is less a feature tour than a case study, because the interesting part was never “an LLM can group rooms.” The interesting part is how you constrain an agent, so its output is explainable, honest about uncertainty, and safe to run on data that is partly fiction.

The messy-data reality

Naive automation does not fail on the zoning logic. It fails on the input. A representative export in our own test set contained all the following:

Roof surfaces exported with a floor-type label, while the geometry plainly showed a horizontal surface at the top of the space.
Missing floor-level references on some spaces, so the level had to be recovered from the geometry rather than read straight off
No true-north rotation is recorded anywhere in the file, meaning every orientation is relative to model north rather than true north.
Metric geometry paired with an imperial space-type library, so any area or setpoint comparison is wrong unless the units are reconciled first.
Space type names from the authoring tool that do not match the names in the space-type library, so a straightforward lookup quietly misses.

Then there is a subtle problem, and the one that actually shaped the design. At the point in the pipeline where zoning happens, a large share of the fields in that file are not real. HVAC parameters, condition-type flags and schedule references embedded in the geometry export are exporter defaults, not design intent. They are well-formed, plausible, and meaningless. Read them and the agent produces a confident answer built on values nobody chose.

So, there are two distinct failure modes to design against: trusting labels over geometry and treating defaults as decisions. Both produce output that looks fine and is not.

The design response

1. Draw the trust boundary before writing the logic.

Feature extraction is the first module in the agent, and its job is narrower than it sounds: turn the source file into one neutral record per space, reading only what is reliable at this stage. That means geometry (vertices, real surface roles, adjacency, exterior exposure), floor level, floor area, and the space type assignment - which is used as a key into the space type library, where the real setpoints, schedules, occupancy and outdoor-air requirements live. Everything else in the export is excluded by construction rather than by convention.

The rest follows from that boundary. Where a surface label and the geometry disagree, the geometry wins, and the disagreement is reported rather than silently corrected. Where the true-north rotation is missing, model north is assumed, and that assumption is printed in the output, not buried in a default. Units are reconciled once, at extraction, so every comparison downstream is like-for-like. A useful side effect: because the record is neutral, nothing in the zoning logic knows or cares which authoring tool a building came from, so a new source format is an extraction concern and never a zoning concern.

2. Keep the reasoning deterministic.

The grouping rules are code, not prompt. Spaces are partitioned by floor first, then by conditioning status, then special spaces - server and IT rooms, mechanical and electrical rooms, elevators, kitchens, stairwells, labs - are isolated into zones of their own, then by compatible space type and properties, then by solar exposure. Perimeter spaces facing different orientations are separated because their loads peak at different times of day; core spaces group apart from perimeter; a corner or through-space with two significant façades is treated as its own exposure category rather than forced onto one side. An optional area cap can split oversized groups when system type or firm convention calls for it; it is off unless you set one, and a single space larger than the cap becomes its own zone and is flagged, because a space cannot be split.

Zoning is a rule-following task with a long tail of edge cases - precisely the kind of work an LLM should not be improvised. Deterministic rules mean the same building yields the same zones every time, which in turn means the output is testable, diffable, and debuggable when an engineer disagrees with it.

3. Confine the model to intent.

Exactly one module contains an LLM: the intent layer. Its job is translation - mapping natural language onto a closed vocabulary of actions the engine already supports propose a level, set the area cap, isolate a space type, merge down to a target zone count, rename a zone, change a conditioning status, approve, reopen. A validating dispatcher sits behind it, so an utterance that does not resolve a known action with well-formed arguments is refused rather than improvised.

That single constraint buys most of the honesty the agent is judged on. “Make the zones bigger,” with no number attached, gets a question back instead of a silently chosen threshold. A request to zone a level that does not exist is declined for a reason. The model never touches geometry, never invents a zone, and never picks a value that belongs to the engineer.

4. Propose, don’t impose - one level at a time.

An early version tried to zone the whole building in one shot. It was the wrong unit of work: a single wrong default at the top of a five-storey building means the engineer rejects everything, and there is no cheap way to say which part was wrong. Review now happens at one level at a time. The agent proposes that the engineer adjusts in plain language, and approval locks the level. Reopening an approved level is an explicit act, never a side effect. Corrections made mid-session - raising the cap, isolating a space type, merging all corridors - carry forward to levels not yet approved, so the same fix is not retyped on every floor.

One correctness lesson from this loop is worth stating plainly, because it generalizes well beyond zoning. In the first implementation, approving a level regenerated the proposal and locked the result. That is subtly, dangerously wrong: if any parameter changed between review and approval - a cap raised, a space type isolated - the locked zones would differ from the zones the engineer actually looked at, with no error and no diff. Approval now locks the cached, reviewed object. It is a small change, and it is exactly the class of bug that destroys trust in an agentic workflow: not a wrong answer, but an answer that quietly stops matching the one you agreed to.

A floor, end to end

What this looks like in use, on a level of an office building that has been imported and space-typed:

“Ideally, how many zones would this building need?”

A per-level estimate, with nothing committed and nothing locked - enough to sanity-check scope before any work is done.

“Propose zoning for level 2.”

A full set of zones, each with a one-line rationale an engineer can read briefly:

L2_PER_EW_Office · Level 2 · Perimeter East West · Office · 3 spaces · conditioned

L2_CORE_Office · Level 2 · Core (no exterior wall) · Office · 4 spaces · conditioned

L2_SERVER · Level 2 · Server room · isolated by rule · 1 space · conditioned

“Too many zones - bring level 2 down to five.”

It merges the natural grouping toward the target by relaxing the softer criteria first (orientation, then space type), and reports exactly what it combined. What it will not do is mix conditioned with unconditioned, or fold the server room into anything, whatever the target counts

“Rename L2_PER_EW_Office to ‘Open Plan East’ and set the store to unconditioned.”

Applied to the proposal under review - which is the version that gets locked

“Looks good - approve level 2.”

The level is locked exactly as reviewed. The raised cap and the isolated space type carry forward to levels 3 and 4 automatically.

"Give me the final zoning"

A single building-wide proposal - with an honest note of any level still pending and any space left unassigned, rather than a false “all done.”

The whole exchange replaces an afternoon of manual grouping with a conversation - and, more importantly, produces a result the engineer can defend line by line.

It proposes you decide - and it can defend every zone it drew.

What it deliberately does not do

The agent is read-only. It never edits the source geometry or project data; it emits a standalone proposal document for the UI to review, and persisting anything is the backend job, only after an engineer approves. That constraint is not a limitation we are apologizing for - it is what makes the propose-and-review loop safe to run early and often

The known gaps are written down rather than hidden, in the same spirit:

Deep-core spaces in taller multi-storey buildings need more validation than our current test set provides.
Unconditioned space types are handled by rule but under-tested against real data.
Rotated buildings depend on a true-north value the exports we have seen do not carry.
Space type name mismatches still cause lookups to miss; unresolved spaces are zoned into clearly marked provisional zones and reported with the closest matching candidates, never given a made-up type.

The engine defaults - grouping key orders, exposure thresholds, splitting behavior, merge scoring - are deliberately frozen. They will be tuned against feedback from practicing HVAC engineers looking at real output, not tuned against our own intuition in advance.

Takeaways

Little of this is specific to thermal zoning. If you are building a domain agent on top of engineering data that was exported by somebody else’s tool, five things transferred well:

Define the trust boundary before the logic. Decide which fields are real at this stage of the pipeline and exclude the rest structurally. Plausible defaults are more dangerous than missing values.
Let geometry outrank labels. When the two disagree, compute the answer and report the disagreement - do not silently pick a side.
Keep the reasoning deterministic; confine the model to translation. An LLM is excellent at turning “group all the corridors” into a validated action, and a poor choice for deciding what a corridor is.
Make the unit of review small and make locking capture what was reviewed. Approval that regenerates instead of freezing is a trust bug even when the output happens to match.
Flags don’t fabricate - and ship the gaps in writing. An assumption stated in the output costs one line and buys the reviewer the ability to check it.

The result is not an autopilot, and it is not trying to be. It automates the tedious first pass and leaves the engineering judgment where it belongs - with the engineer, who now spends their time on the ten percent they disagree with instead of the ninety they would have typed out by hand.

Nothing is invented, nothing is hidden, nothing is locked without you.

Take the Next Step: Start Your Free Trial or Book a Demo