Status: community draft, not a standard. We are not a certification body, and a score against this list certifies nothing. It is a structured way to start a conversation that mostly isn't happening. Comment via hello@ai-smart-buildings.com; v0.2 will credit contributors.
Sometime soon, the most demanding new "occupant" in your building won't sign a lease. It will be a software agent — reading trend data, reconciling work orders, drafting the report a human used to spend Friday assembling. Before any of that, one question decides everything: can an agent actually read your building?
Agent-ready is not the same as smart. A building can have a modern BMS, thousands of points, and a wall of dashboards — and still be unreadable from the outside: no scheduled exports, no key to the point names, no read-only access path, no contract clause saying the data is even yours. Conversely, an older building with a clean point list, a nightly CSV export, and a sensible access policy can be more agent-ready than a flagship tower.
This checklist is 14 questions in four dimensions. Every item can be answered No / Partial / Yes by someone who knows the building — no site visit, no vendor meeting. It mirrors, item for item, our free Agent-Ready Building Scorecard at tools.ai-smart-buildings.com/agent-ready, which turns your answers into a weighted 0–100 score entirely in your browser. Advisory tool, read-only philosophy: nothing touches your BMS, and no answer leaves your device.
How scoring works
No = 0, Partial = 1, Yes = 2. The four dimensions are weighted: Data Export 35% · Semantic Readiness 25% · Access Governance 25% · Agent Consumption Surface 15%, giving a 0–100 score and four tiers: Agent-Blind (0–25), Agent-Readable (26–50), Agent-Ready (51–75), Agent-Native (76–100). The weights are a judgment call, stated openly — export capability is weighted highest because nothing downstream matters if data can't leave the building. If you'd weight differently, that's exactly the comment we want.
A. Data Export Capability — 35%
Can data leave the building without a service call?
An agent's first interaction with a building should be read-only consumption of what already exists — trend exports, utility data, reports the building already produces. That is the read-first philosophy behind this whole list: start from the building's existing exhaust, because the activation energy is near zero and nothing can break. If data can't get out on a schedule, every later dimension is theoretical.
- Can your BMS produce scheduled, automated trend exports (CSV or similar)?
Counts as Yes: recurring exports configured once and delivered on a schedule — not a technician pulling files by hand.
- Can you access your utility data through Green Button or a utility API?
Counts as Yes: Green Button Connect or an equivalent utility portal/API exporting interval meter data. The zero-hardware path most owners never switch on.
- Is your BMS API licensed and enabled — not just technically present?
Counts as Yes: you know what API access your license includes, and it is switched on. Many systems ship with an API that is unlicensed, disabled, or priced per point.
- Can you retrieve historical trend data older than 12 months?
Counts as Yes: long-term history lives somewhere durable. Short on-controller buffers silently overwrite the past.
B. Semantic Readiness — 25%
Would an outsider — or an agent — understand your point names?
Data without meaning is noise: an agent can fetch AHU2_SAT, but only semantics tells it that's the supply air temperature on air handler 2. Documentation and tagging are how meaning survives contractor turnover — an undocumented convention in a retiring technician's head is the most fragile asset in the building. Partial credit is deliberate here: tagging one air handler is genuinely better than tagging none.
- Is your point naming convention documented anywhere?
Counts as Yes: a written key to your names — even a single page counts.
- Do you have any Project Haystack or Brick tagging on your points?
Counts as Yes: Haystack tags or Brick classes applied to some or all points, by any vendor or tool.
- Is your point list inventory current?
Counts as Yes: the list matches what is installed today — not the as-built from years ago.
C. Access Governance — 25%
Could you grant safe access tomorrow — and prove what happened?
Governance is what makes "yes" a safe, reversible decision instead of a leap of faith. A documented network boundary, a read-only path, an ownership clause, and an access log together mean you can let an analysis party in without ceding control — and revoke it just as cleanly. This is also where the advisory-only stance earns its keep: read-only access with an audit trail is easy to grant precisely because it cannot break anything.
- Is your OT/IT network segmentation documented?
Counts as Yes: a written description — even one diagram — of how building systems are separated from the corporate network.
- Does a read-only third-party access path exist?
Counts as Yes: a defined way to give an outside party view/export access without write privileges to controls.
- Do your vendor contracts include a data ownership clause?
Counts as Yes: contract language stating the building's data belongs to the owner. Silence defaults in the vendor's favor.
- Is there an audit trail on data access?
Counts as Yes: logs showing who accessed or exported building data, and when. Trust needs receipts.
D. Agent Consumption Surface — 15%
Is there anything a software agent could plug into today?
This dimension is weighted lowest on purpose: consumption surfaces are the easiest layer to add once the first three exist, and an agent can do real work from exports alone. But a building that exposes a programmatic surface — an API, a structured asset register, a CMMS endpoint — moves from "an agent could read it with help" to "an agent can simply show up."
- Do you expose any API or MCP surface for building data?
Counts as Yes: any programmatic interface — a REST API, an MCP server, or a read-only integration endpoint.
- Do you keep a machine-readable floor / asset register?
Counts as Yes: floors, zones and major equipment in structured form (spreadsheet, JSON, IWMS export) — not only PDF drawings.
- Does your work-order (CMMS) system have an API?
Counts as Yes: API access actually enabled on your plan. Work-order history is the richest operational record most buildings own.
The four tiers
- Agent-Blind (0–25). The building's data is effectively invisible to software — locked in proprietary systems, paper, and people's heads. The first moves are cheap and read-only.
- Agent-Readable (26–50). Some data gets out, slowly and with help. An agent could read the building today — with a human translator alongside.
- Agent-Ready (51–75). Structured, governed, exportable. An agent could do useful read-only work today.
- Agent-Native (76–100). The building presents data the way agents consume it. The constraint is what you ask of it — not access.
What this is not
This is v0.1 of a community draft. It is not a standard, not a certification, and not a substitute for the open frameworks it points to — Project Haystack, Brick Schema, Green Button. The 14 items, the three-level answers, and the weights are all open to challenge. We expect to be wrong somewhere, and would rather be corrected in public than politely ignored in private.
If you own, operate, integrate, or build software for buildings and any item is missing, redundant, mis-weighted, or naive — write to hello@ai-smart-buildings.com. v0.2 will incorporate and credit contributors. Score your own building first at tools.ai-smart-buildings.com/agent-ready — it takes three minutes, runs entirely in your browser, and nothing here touches your BMS.
Research compiled by the AISB agent fleet from primary sources; every claim verified against the public record. Cost figures are labeled industry estimates. Full source list available on request — hello@ai-smart-buildings.com.