> For the complete documentation index, see [llms.txt](https://docs.buildings.ability.abb/collection/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.buildings.ability.abb/collection/academy/building-intelligence-ai-and-machine-learning-in-buildingpro-suites/agents/agents-in-the-smart-building-domain.md).
# Agents in the Smart Building Domain
Smart buildings generate large volumes of data, often spread across multiple subsystems and interfaces: asset configurations, live telemetry, alarms, time-series trends.\
Extracting insights from this data traditionally requires navigating between dashboards, configuring new charts, inspecting raw data or relying on pre-built reports.\
\
Agents offer a different interaction model. Instead of the user navigating to the data, the agent navigates for the user.\
An agent receives a natural-language request, decomposes it into steps, uses tools to resolve and retrieve the relevant information and returns a structured, explainable result.\
\
In BuildingPro Suites agents serve as the interface layer between business users and the platform's data and feature surface. But instead of replacing platform capabilities they make them accessible without requiring users to understand the underlying data model, query languages or UI navigation paths.\
* Asset hierarchies are deep and project-specific. A single portfolio can contain thousands of assets across dozens of types, organized by location, function, and logical grouping. Navigating this manually is slow.
* Metrics live on different asset types at different levels of the hierarchy. "Energy usage" might be recorded by meters three levels below the building the user is asking about. An agent resolves that chain automatically.
* The questions users ask are often ad-hoc and exploratory. Pre-built dashboards cover known questions; agents cover the rest.
Beyond data retrieval, agents enable a fundamentally different interaction pattern with application features.
**The traditional pattern:**
1. User wants to configure something (e.g. an alarm rule, a dashboard, a report)
2. User navigates to the relevant feature in the application
3. User reads documentation or tooltips to understand the available options
4. User fills in forms, selects parameters, navigates between related screens
5. User validates the result
This creates friction even for expert users. For occasional users or those unfamiliar with the data model, it creates a barrier that makes features effectively inaccessible.\
An agentic integration changes this entirely. Instead of the user navigating to the feature, the agent receives the feature's capabilities up front: what it does, what inputs it accepts, and what outputs it produces. This is embedded in the agent's context as tool definitions and system instructions. The user expresses their intent in natural language, and the agent:
**The agentic pattern:**
1. User describes what they want in natural language
2. The agent already has the *essence* of the feature's documentation embedded in its context: the parameters, constraints, valid configurations.
3. The agent translates the natural-language request into the technical configuration, Selects the appropriate feature/tool and executes it
4. The agent translates the technical result back into natural language for verification
This is not about removing the UI. It is about removing the friction between *knowing what you want* and *knowing how to express it in the application's terms*.The agent acts as a bidirectional translator:
* **Natural language -> technical configuration:** "Alert me when any room on the 3rd floor exceeds 26°C for more than 30 minutes" becomes a concrete alarm rule with the right asset scope, attribute, threshold, and duration.
* **Technical configuration -> natural language:** The agent explains what it created, so the user can verify without needing to parse the technical representation.
This pattern scales across features. Each new agentic integration follows the same principle: give the agent the context it needs to operate a feature (its schema, constraints, valid options), and it becomes an interface that users can operate through conversation rather than navigation.\
The benefit compounds with platform complexity. The more features, menus, and configuration options a platform has, the more value an agent provides by collapsing the navigation and learning overhead into a single conversational interface.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.buildings.ability.abb/collection/academy/building-intelligence-ai-and-machine-learning-in-buildingpro-suites/agents/agents-in-the-smart-building-domain.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.