Creating semantic hierarchies that make the UNS legible to AI agents

TL;DR

A Unified Namespace is not a new idea, this post digs into how we take the established concept of a UNS to fit the evolving needs of manufacturing’s data teams.

• A well-designed semantic hierarchy in the Unified Namespace transforms MQTT topic trees from human-readable labels into machine-parseable structures that AI agents can navigate, query, and reason over autonomously.
• ISA-95 alignment provides a proven scaffolding for topic hierarchies, but agents need richer semantics than the standard alone provides; combining ISA-95 levels with explicit entity typing and relationship encoding closes the gap.
• Grounding agent reasoning in the UNS hierarchy means agents can resolve ambiguity, scope their queries, and chain inferences without relying on hardcoded topic paths or external lookup tables.
• HiveMQ platform provides the enterprise-grade MQTT backbone for UNS deployments, while HiveMQ Data Intelligence adds the Semantic Graph layer that formalizes the ontology agents consume.

Who is this blog for? This post is for engineers who are building or refining a UNS and want to make it legible to autonomous agents.

The Unified Namespace is not a new idea. If you are reading this, you have likely already deployed one, or you are deep enough into the architecture to know that the challenge is making that hierarchy meaningful to something other than a human reading a Grafana dashboard.

As AI agents become first-class consumers of operational data, the question shifts from "Can a person find the data?" to "Can an agent discover, interpret and reason over the data without human guidance?"

In this post, we cover what ‘legible’ actually means in a machine context, how ISA-95 alignment helps (and where it falls short), and the specific design decisions that determine whether your hierarchy grounds agent reasoning or forces brittle workarounds.

Why do AI agents need a different kind of hierarchy than humans?

A human operator scanning a topic tree like site/acme-detroit/area/stamping/line/press-04/plc/temperature can infer context from naming conventions, positional order, and domain knowledge. An agent cannot. Or more precisely, an agent can be trained or prompted to parse a specific naming convention, but that approach does not scale. It creates fragile bindings between the agent's logic and the topic structure. When you change a level, rename a segment or add a new site, the agent breaks.

Agents need explicit semantics encoded into the hierarchy itself so that navigation and interpretation are deterministic rather than heuristic.

Three properties make a hierarchy agent-legible:

1. Typed levels. Each level of the hierarchy has an explicit type (enterprise, site, area, line, cell, asset, measurement) that an agent can query programmatically, not infer from position.
2. Consistent granularity contracts. An agent traversing the tree can predict what it will find at each depth. If line/press-04 sometimes contains direct measurements and sometimes contains sub-assets, the agent cannot build reliable traversal logic.
3. Resolvable references. When a topic payload references another entity (a work order, a material batch, a maintenance schedule), the reference is a resolvable path or identifier within the same namespace, not an opaque foreign key that requires an external lookup.

These properties are what separate a topic tree that works for dashboards from one that works for autonomous reasoning.

How does ISA-95 alignment help and where does it fall short?

ISA-95 provides a hierarchical model (Enterprise > Site > Area > Work Center > Work Unit > …) that maps naturally to MQTT topic levels. This is why most UNS implementations start with ISA-95 as the scaffolding. For agent-legible design, ISA-95 gives you two things for free:

Predictable depth semantics. An agent that knows the hierarchy follows ISA-95 can infer that level 1 is always an enterprise, level 2 is always a site, and so on. This is a coarse form of typed levels without requiring explicit metadata at every node.

Scope boundaries for reasoning. ISA-95 levels map to operational scope. An agent tasked with "optimize energy consumption for the stamping area" can programmatically resolve "stamping area" to a specific subtree and scope its data queries accordingly. Without ISA-95 alignment, "area" is just a string.

Where ISA-95 falls short for agents:

No entity typing below Work Unit. ISA-95 defines organizational hierarchy but does not prescribe how you model individual assets, sensors, or measurements within a work unit. This is exactly where agents need the most structure, because the leaf nodes are where the data lives.

No relationship semantics. ISA-95 is a tree. Real operations are a graph. A CNC machine belongs to a production line (ISA-95 hierarchy) but also relates to a maintenance schedule, a material specification, and an energy circuit. ISA-95 does not capture these cross-cutting relationships.

No payload schema governance. ISA-95 tells you where to put topics, not what the payloads should contain. Two temperature topics at the same hierarchical level might publish in Celsius vs. Fahrenheit, with different JSON structures, and ISA-95 has nothing to say about that.

The practical implication: use ISA-95 for levels 1 through 4 or 5 of your topic hierarchy. Below that, you need an explicit ontology that defines entity types, required properties, and valid relationships. This is where HiveMQ Data Intelligence’s Semantic Graph becomes essential; it provides the formal ontology layer that ISA-95 alone cannot.

What does an agent-legible topic structure actually look like?

Let us walk through a concrete example. Consider a stamping press in an automotive plant.

Human-optimized (typical UNS):

acme/detroit/stamping/line-3/press-04/temperature
acme/detroit/stamping/line-3/press-04/pressure
acme/detroit/stamping/line-3/press-04/cycle-count

This is readable. It is also ambiguous to an agent. Is press-04 an asset or a location? Is temperature the die temperature, the hydraulic oil temperature, or the ambient temperature? The agent has to guess or be hardcoded.

Agent-optimized:

acme/detroit/stamping/line-3/asset/press-04/measurement/die-temperature
acme/detroit/stamping/line-3/asset/press-04/measurement/hydraulic-oil-temperature
acme/detroit/stamping/line-3/asset/press-04/status/cycle-count

Key differences:

The asset/ and measurement/ segments are type markers. An agent can wildcard-subscribe to +/+/+/+/asset/+/measurement/# to discover all measurements across all assets, all lines, all areas, and all sites without knowing any specific names. This is structural discoverability, and it is the single most important property for agent autonomy.

Payload Schema Contracts

The topic structure is only half the problem. The payload arriving on asset/press-04/measurement/die-temperature must also be predictable. At minimum, an agent-legible payload contract includes:

{
"value": 187.4,
"unit": "celsius",
"timestamp": "2025-01-15T14:32:07.123Z",
"quality": "good",
"asset_ref": "acme/detroit/stamping/line-3/asset/press-04",
"measurement_type": "die-temperature"
}

Notice asset_ref is a resolvable UNS path, not an opaque ID. An agent receiving this payload can navigate to the referenced asset's subtree to discover related measurements, status information, or linked entities. HiveMQ platform can enforce these payload schemas at the broker level, rejecting non-conforming publishes before they pollute the namespace.

How do you ground agent reasoning in the hierarchy?

Grounding is the process of connecting an agent's abstract reasoning to concrete operational reality. When an agent receives the instruction "identify thermal anomalies on Line 3," it needs to:

1. Resolve "Line 3" to a specific subtree: acme/detroit/stamping/line-3/
2. Discover all thermal measurements within that subtree: wildcard subscribe to acme/detroit/stamping/line-3/asset/+/measurement/*temperature
3. Retrieve baseline context for each measurement: what is the normal range for die temperature on a stamping press vs. hydraulic oil temperature?
4. Scope its conclusions appropriately: an anomaly on press-04 is a Line 3 issue; an anomaly on all presses simultaneously might be an area-level HVAC issue.

Steps 1 and 2 are pure hierarchy navigation. If the hierarchy is agent-legible (typed levels, consistent granularity, wildcard-friendly structure), these steps are deterministic. If the hierarchy is ambiguous, the agent needs hardcoded mappings or an external service to resolve them, which is where brittleness enters.

Steps 3 and 4 require the ontology and Semantic Graph. The ontology defines that a stamping-press asset type has an expected die-temperature range of 150-220°C and that presses on the same line share an HVAC zone. The Semantic Graph (in HiveMQ Data Intelligence) contains the specific instances and relationships: press-04 is a stamping-press, it is on line-3, line-3's HVAC zone is zone-7A.

This is the critical integration point. The MQTT topic hierarchy provides the real-time data navigation layer. The Semantic Graph provides the contextual reasoning layer. Agents consume both: they subscribe to topics for live data and query the Semantic Graph for context, relationships, and constraints. Without the hierarchy, agents cannot find data efficiently. Without the Semantic Graph, agents cannot interpret what they find.

What are the most common design mistakes that break agent legibility?

Having reviewed dozens of UNS implementations, these are the patterns that consistently cause problems when agents enter the picture:

Overloading topic segments with multiple meanings

A topic like acme/detroit/stamping/press-04-temperature encodes both the asset and the measurement in a single segment. No wildcard pattern can separate assets from measurements. An agent cannot discover all assets or all measurement types independently.

Fix: One concept per topic level. Always.

Inconsistent depth across branches

If line-3/press-04/temperature coexists with line-3/conveyor-07/section-2/speed, the tree has different depths for different asset types. Agents cannot build uniform traversal logic.

Fix: Normalize depth. If some assets have sub-components, model them explicitly: asset/conveyor-07/component/section-2/measurement/speed. The traversal contract remains asset/ASSET/component/COMPONENT/measurement/METRIC everywhere, with component being optional but always at the same level when present.

Using human-friendly names as primary identifiers

press-04 is fine for a dashboard. It is fragile as a machine identifier because humans rename things. When Press 04 gets refurbished and becomes "Press 04A," every agent subscription and every stored reference breaks.

Fix: Use stable identifiers in the topic path (asset/P-STM-004/) and publish human-friendly names as metadata in the payload or in the Semantic Graph. Agents bind to stable IDs; dashboards resolve display names from metadata.

Ignoring cross-cutting relationships

A quality measurement might relate to both the asset that produced it and the material batch being processed. If the topic hierarchy can only express one parent (the asset), the batch relationship is lost unless it is encoded elsewhere.

Fix: This is exactly what the Semantic Graph is for. The topic hierarchy expresses the primary organizational relationship (ISA-95 physical hierarchy). Cross-cutting relationships (batch, schedule, maintenance, energy) live in the Semantic Graph and are queryable by agents.

How do you evolve an existing UNS without breaking agents?

If you already have a UNS in production, you are not going to redesign the topic hierarchy overnight. The practical path:

1. Audit your current hierarchy for type ambiguity. Identify topic levels where the entity type is implied rather than explicit. Prioritize the levels agents will query most: asset and measurement levels.
2. Introduce type markers incrementally. You can add asset/ and measurement/ levels to new topics while maintaining legacy topic paths. HiveMQ's bridging capabilities allow you to run parallel hierarchies during migration, with legacy topics bridged to new-format topics.
3. Deploy payload schema validation. Use HiveMQ to enforce payload contracts on new topics immediately. For legacy topics, start with monitoring mode (log non-conforming payloads without rejecting them) and migrate producers incrementally.
4. Build the Semantic Graph in parallel. HiveMQ Data Intelligence can discover and catalog your existing topics, then you overlay the ontology: entity types, relationships, constraints. This gives agents the contextual reasoning layer even before the topic hierarchy is fully restructured.
5. Test agent traversal on the new structure. Before migrating production agents, build test agents that subscribe to the new hierarchy and verify that wildcard discovery, payload parsing, and Semantic Graph queries all work as expected.

This incremental approach means you are never making a flag-day cutover. The hierarchy evolves, agents are validated against the new structure, and legacy paths are retired as producers migrate.

The UNS was designed as a single source of truth for operational data. Making it legible to AI agents is not a different goal; it is the same goal extended to a new class of consumer. The design principles are straightforward: type your levels, enforce your contracts, encode relationships in the Semantic Graph, and build for wildcard discovery. The organizations that get this right will have a namespace that serves both human operators and autonomous agents from the same infrastructure, with HiveMQ’s Connect layer as the backbone and HiveMQ Data Intelligence providing the intelligence layer on top.

Ready to explore how your UNS maps to an agent-legible hierarchy? Try HiveMQ Cloud free and start experimenting with topic structures, schema validation, and wildcard discovery patterns. For deeper guidance on Semantic Graph modeling, explore the HiveMQ documentation or join the HiveMQ Community Forum to discuss architecture patterns with other engineers building agent-ready namespaces.

Frequently Asked Questions