MondayLive! is a weekly conversation at mondaylive.org where the building automation community discusses the technologies, standards, and ideas shaping the industry.
What happens when software is no longer simply recommending an action, but is authorized to purchase, negotiate, allocate resources, or change the operation of a building?
That question moved to the center of this week’s MondayLive! discussion.
The session started with edge computing, C4SB demonstrations, and standards work, but the larger theme quickly became clear: as systems become more autonomous, connectivity alone is no longer enough.
The harder problem is trust.
Trust Is Becoming Infrastructure
For years, interoperability discussions have focused on whether systems can exchange data.
Agentic systems introduce a more difficult question: should they be allowed to act on what they receive?
Trust in this environment cannot simply mean that two systems connected successfully. It requires some way to establish identity, authority, capability, context and accountability.
That distinction matters as computing moves closer to physical systems and software gains greater ability to initiate actions without a human approving every individual step.
The discussion increasingly moves from can these systems communicate? to under what conditions should one system trust another enough to act?
From Building Identity to Agent Identity
Several projects discussed during the session point toward pieces of that trust infrastructure.
C4SB’s Digital Building Profile work is aimed at creating a more consistent, machine-readable description of buildings, their systems and capabilities. A building that can describe itself consistently becomes easier for software to understand without every integration starting from scratch.
UDMI takes a related approach at the device and system level, establishing structured ways for equipment to describe its state and capabilities.
CNS/CP extends the conversation toward the relationships between systems: what a participant provides, what another participant is requesting, and the context in which that relationship is allowed to exist.
These may appear to be technical plumbing issues, but they become increasingly important when software is expected to make decisions.
Before an agent can safely act, it needs to know much more than where another system is located.
It needs to know what it is, what it can do, what authority it has and under what conditions that authority applies.
When Machines Decide
This is where the conversation became much more interesting.
Human transactions contain layers of context that are easy to overlook. We recognize organizations, job roles, contracts, approvals, and responsibilities. We can ask questions when something looks wrong.
Software transactions compress much of that into credentials, APIs, policies, and machine-readable instructions.
An API call might trigger a purchase, change an operating setpoint, commit computing resources, or initiate another automated workflow.
At that point, authentication is only the beginning.
The system also needs to determine whether the action is appropriate, whether the agent actually has authority to perform it, whether that authority still applies, and what happens if the action is wrong.
Agent-to-Agent Trust
The problem becomes harder when both sides are autonomous.
If one agent instructs or engages another, how does the receiving agent know the request is legitimate?
How does the first agent know what the second agent is actually capable of doing?
And when an agent is acting on delegated authority from an organization, how far does that authority travel?
These questions expose limitations in systems originally designed around human users.
An authenticated identity does not automatically establish permission. A declared capability does not necessarily establish competence. And a successful connection does not mean that every action available through that connection should be allowed.
Greggory Don Butler explored this distinction in The Crossing Is Not the Permission.
His argument, authority context may travel between independently governed systems, but execution authority ultimately has to be established where the action occurs.
That difference becomes critical in an agent-to-agent environment.
Runtime Validation Changes the Model
One of the most useful distinctions raised during the session was between configuration-time approval and runtime validation.
Configuration-time approval asks whether something was permitted when the system was installed or configured.
Runtime validation asks whether the specific action is still appropriate now, under current conditions.
That difference sounds small. It is not.
Buildings change. Occupancy changes. Equipment fails. Credentials expire. Organizations change policies. Operating conditions shift.
An action that was valid yesterday may not be valid today.
For autonomous systems, trust, therefore, cannot be treated only as a configuration setting. Some decisions may need to be evaluated at the moment an action is requested.
That means checking identity, capability, context, policy, and authority before execution, not simply assuming that an earlier approval remains valid.
Capabilities Need Evidence
The same principle applies to agent capabilities.
Saying an agent can optimize a building, negotiate a transaction, or operate equipment is a claim.
For another system to trust that claim, it needs evidence.
That could eventually involve defined capabilities, test results, certification, provenance, operational limits, or other machine-verifiable credentials.
This is where standards become much more important.
The goal is not simply to help systems communicate. It is to make claims about identity, capabilities, and authority understandable across organizational and technical boundaries.
Identity, Provenance, and Transparency
The discussion ultimately came back to three fundamentals: identity, provenance, and transparency.
A trustworthy autonomous system needs some way to answer basic questions:
Who or what initiated this action?
What authority did it have?
Where did the instruction originate?
What information influenced the decision?
What changed as a result?
Can the action be audited, challenged or reversed?
Those questions are familiar to cybersecurity and enterprise governance. Agentic systems make them operational requirements.
The Takeaway
The most important shift may not be from human operators to autonomous agents.
It may be the shift from trusting systems because we configured them to requiring systems to continuously demonstrate why a particular action should be allowed.
Building automation is an unusually useful place to explore this problem because the consequences are physical. Software decisions can affect energy, equipment, comfort, security, and eventually transactions between buildings, utilities, and other services.
The industry has spent decades working on interoperability.
The next challenge is harder:
Once everything can communicate, what gives one machine the right to act on another?
That is where the agent-to-agent trust discussion begins.
Further Reading
- The Crossing Is Not the Permission, by Greggory Don Butler
- Universal Device Management Interface (UDMI)
- Readiness: AI at the Edge
- MondayLive!
- AutomatedBuildings.com
