Ontology Agent
The always-on background agent that keeps your ontology correct, linked, and current.
The Ontology Agent is an automatic, always-on part of the platform. It is not a tool you call or configure — there is no Ontology Agent API, no setup, and nothing to turn on. It runs ambiently in the background, keeping your ontology correct, connected, and current while you work.
You interact with the ontology primitives directly — creating and changing Thing Type Definitions, Metric Definitions, Templates, Things, and the links between them over the Platform API or in the Console. Everything the agent does happens behind that surface, abstracted away: you get a maintained, coherent model without operating the system that maintains it.
What it handles in the background
As you work with the primitives directly, the agent continuously:
- Gardens the ontology — reconciles duplicates, normalizes definitions, and keeps versioning tidy as your primitives evolve, so the model stays coherent instead of accumulating cruft.
- Keeps it correct — validates and reconciles primitives against your connected sources so the model stays aligned with reality.
- Maintains the links — keeps your ontology as one connected graph rather than a set of disconnected records.
- Produces the representations — continuously computes the embeddings of every Thing that downstream capabilities consume, with nothing for you to build or invoke.
Generation and drift
The agent can build primitives for you and keep them current — automatically. When you connect documents and data sources (uploaded specifications, fileshares, databases), it instantiates the primitives they imply:
| Primitive | Models | Example (OEM hardware manufacturer) |
|---|---|---|
| Thing Type Definitions | The entities in your domain | Product models, assemblies, and parts |
| Metric Definitions | Measured or derived quantities | Tolerances, mean time between failures, test thresholds |
| Templates | Reusable structures for instantiating these consistently | A mapping from a supplier's data sheet to a part type |
As those sources change — a specification is revised, a field is added, a part is superseded — the agent detects the drift and reconciles the affected primitives on its own. Because generation and reconciliation are the same ambient agent, your ontology behaves as a living model that stays current by itself, not a one-time build that falls out of date.
You stay in control of your data: because you own the primitives directly, you can inspect, override, or change anything the agent produces at any time through the same API and Console you already use. Where a change is genuinely ambiguous, the agent surfaces it for a quick confirmation and learns from your answer — but the default posture is automatic, with nothing to operate.
Linked data
The agent doesn't just maintain primitives in isolation — it maintains the links between them, so your ontology is one connected graph rather than a set of disconnected records. A Thing links to its Thing Type Definition, to its Place, and to the documents and events that concern it; a manual links to the type it describes; a fault record links to the Thing and the Metric it documents.
This matters because relatedness becomes a structural fact recorded in the graph, not a guess. When the platform needs the material related to a Thing — its reference documentation, its event history — it follows explicit links rather than hoping a similarity score surfaces the right thing. That keeps relationships precise, inspectable, and reproducible.
Links are established two ways, working together:
- Automatically, when the incoming data already identifies its subject — telemetry and records that arrive carrying a Thing identifier are linked deterministically.
- Through guided confirmation, where the agent surfaces the ambiguous cases for a quick human confirmation. Those confirmations become trusted ground truth: the agent learns from them to propose new links, and the graph grows richer and more accurate with use.
Related docs
- Agentic overview explains how the agent fits the build–maintain–surface lifecycle.
- Data model defines the primitives the agent generates.