In praise of unglamorous protocols

There is a comfortable fiction in most agentic AI architectures: the world is a set of JSON endpoints. Authenticate, POST, read the 200. The demo works because the demo's world is other software. But walk into a mechanical room and the fiction ends. The air handler answers to BACnet objects with numeric instance IDs. The power meter speaks Modbus registers — sixteen bits at a time, no schema, no self-description. The lighting rides DALI, a bus designed when a ballast was a physical thing you could bruise a knuckle on.

These protocols are unglamorous. They are also undefeated. BACnet has been the lingua franca of building automation since the mid-nineties. Modbus dates to 1979 and still ships in new equipment today. They persist for a reason software engineers should respect rather than sneer at: they are simple, they are documented, and the equipment they control runs for decades. The chiller does not care about your framework's release cadence. It will outlive three of them.

What the mechanical room teaches you

Working at this layer imposes a discipline that HTTP lets you defer. There are no transactions. There is often no acknowledgment worth the name — you write a value to a point and read it back later to learn whether the world agreed. Devices drop off the bus and reappear. Two controllers may sit behind one gateway with the polling budget of a modem. A retry, so cheap and harmless against a web API, can hammer a serial line into uselessness or slam a damper actuator through cycles it was never rated for.

In other words: the physical world punishes exactly the sloppiness that modern software tolerates. Which is why we think building automation is not a niche integration problem for agentic AI. It is the honest version of the problem.

Wrapping decades in a capability

The reference pattern wraps these protocols in governed capabilities. BACnet is a managed early-access listing, not a claim of a commissioned public connector. A real deployment should expose bounded intents rather than raw bus access and keep the building automation and life-safety systems authoritative.

That indirection is where forty years of protocol quirks go to be tamed:

• Idempotency where the device cooperates. A platform key can suppress known duplicate attempts, while reliable read-back or connector-specific reconciliation is needed to establish device state.
• Single-flight per entity. One governed command per scoped device can be serialized inside the runtime; other controllers and operators remain outside that lock.
• Fail closed on known uncertainty. Missing read-back, stale state, or an out-of-policy value should hold the action. Existing building and life-safety controls remain authoritative.
• Records for attempted physical effects. Supported paths should retain intent, policy, command, response, and read-back state without presenting an unknown outcome as confirmed.

Respect the installed base

The installed base makes compatibility valuable, but not every site can be governed safely without new sensors, gateways, network segmentation, or commissioning work. A deployment should identify those requirements rather than promise no new hardware.

The quiet thesis is that SaaS and hardware can share a capability vocabulary while retaining different risk controls. Physical deployments demand stricter commissioning, authority limits, read-back, and independent safeguards than a manifest alone can provide.

Keep reading: A hotel, room by room · Capability, then connector