Every agent in your enterprise must answer one question before it acts: what am I actually looking at? A language model can read a record from Teamcenter, SAP and your MES. On its own, it cannot know that the “part” in all three is the same physical thing, that this part sits in an assembly under an open engineering change, and that last week’s warranty claim points at exactly that assembly.
Your people know this from years of experience. Agents need it written down. That written-down understanding is an ontology, and once it is filled with live data it becomes a knowledge graph. Together they form the least glamorous and most decisive layer of the agentic enterprise: the one that lets people and agents work from the same reality.
This blog explains what ontologies and knowledge graphs are, how they work, where they sit in your architecture, what the predefined industrial ontologies in Siemens Intelligence Center X bring to manufacturers, and what it takes to build one yourself.
Short on time? Here’s a brief overview
- Agents fail on context, not on models. Gartner expects 60% of AI projects without AI-ready data to be abandoned. The difference between an agent that creates value and one that creates incidents is whether it understands what your data means.
- An ontology is the rulebook; a knowledge graph is the map drawn by that rulebook. The graph links every part, change and claim across your systems, so agents can follow the path from question to answer. Together they give people and agents the same definitions, the same rules and the same audit trail, the basis of a hybrid workforce you can trust.
- Keep the core clean and layer context on top. Your systems of record stay untouched at the base. The ontology and knowledge graph sit directly above them as a shared context layer, with orchestration and AI added on top where they make sense.
- Not every ontology layer is built for agents. Agents ask questions nobody anticipated, across many systems at once. Graph Studio in Siemens Intelligence Center X is a scalable graph platform designed to answer those at enterprise scale, without performance limits.
- Build on proven industry knowledge. You don’t have to model manufacturing from scratch. Predefined industrial ontologies and open standards already describe the digital thread, from engineering BOM to warranty claim. Your domain experts make them your own, matching records across systems and governing how the model evolves. Start with one cross-system workflow and let every next use case extend it.
Why agents stall without context
The model is rarely the bottleneck. The context it reasons against is.
Gartner predicts that through 2026, organisations will abandon 60% of AI projects that are not supported by AI-ready data, and 63% of organisations either lack the right data management practices for AI or are unsure whether they have them. For agents specifically, Gartner expects more than 40% of agentic AI projects to be cancelled by the end of 2027, citing escalating costs, unclear business value and inadequate risk controls.
The clearest evidence of what context does comes from a benchmark by data.world researchers. They asked GPT-4 business questions over an enterprise SQL database from the insurance domain. Queried directly, the model answered 16.7% of questions correctly. Queried over a knowledge graph built on an ontology of the same data, accuracy rose to 54.2%. On the hardest questions over the most complex schemas, direct SQL scored 0%, while the knowledge graph route reached 36–39%. A follow-up study used the ontology itself to check and repair the model’s queries and pushed accuracy to 72%.
Same model, same data. The only difference was whether the meaning of the data was made explicit. For an agent that does not just answer but acts, that difference decides whether it creates value or creates incidents.
Why 72% is a starting point, not a verdict
No enterprise should act on 72%, and no well-designed enterprise system asks it to. The benchmark measures a language model writing its own queries against open questions, without guardrails. In production, three things change the picture.
First, the ontology acts as a check, not just a guide. Queries that do not fit the model of the business are caught and repaired, or the system declines to answer. A known “I don’t know” is safe. A confident wrong answer is not.
Second, the required accuracy follows the consequence. Exploring a question can tolerate uncertainty. Approving a recall cannot. High-stakes decisions run on engineered rules and validated queries, with a human approval step, while open exploration stays a support tool.
Third, every answer is traceable. Which data was used, which query ran and who approved the action is logged, so an error is visible and correctable instead of hidden.
The takeaway from this research is not that AI using ontologies is 72% reliable. It is that grounding AI in context is the most effective way to make it more reliable, and to make it honest about where its knowledge ends.
The rulebook and the map
An ontology is the rulebook; a knowledge graph is the map drawn by that rulebook. The two terms are often used interchangeably, but they do different jobs.
The ontology is a formal vocabulary for your business. It defines the types of things that exist (a pump, a production line, an engineering change, a supplier), the properties they have, how they may relate to each other, and the rules that apply. A pump can be installed in a line. An engineering change affects one or more parts. A part cannot be released without an approved design. Without an ontology you have a picture of dots and lines. With one, the system knows what each dot is and can reason about it.
The knowledge graph is that vocabulary applied to your real data: Pump P-101, Line 3, change request ECR-2291, and the millions of connections between them, refreshed from your systems of record.
This split matters for the agentic enterprise. The ontology is where people encode what the business means. The graph is where agents and applications read and act on it. Get the ontology right and every new agent inherits that understanding for free.
How a knowledge graph works
A knowledge graph stores every fact as a triple: subject, relationship, object. Chain enough triples together and you get a map that people and agents can walk, rather than a warehouse they have to query with a dozen painful joins.
Triples. “Pump P-101 is installed in Line 3.” “Line 3 produces Product X.” “Product X contains Assembly 4471.” “Assembly 4471 has requirement max 80 °C.” Each thing is a node, each relationship an edge. In the W3C standards most enterprise graphs use, these are RDF triples, queried with SPARQL.
Traversal. A question like “which open warranty claims involve parts touched by last month’s engineering changes?” crosses PLM, ERP and service data. In a relational world that is a project. In a graph it is a path: claim → serial number → as-built configuration → part → change. Agents are good at following paths, as long as the paths exist and mean something.
Ontology vs Knowledge graph · one path from claim to change
The left column is written once, by people. The right column is filled continuously from your systems. An agent that understands the left can find the right for any claim, in any plant.
Inference. Because the ontology carries rules, the graph can derive facts nobody entered. If every assembly inherits the compliance requirements of its parts, a new regulation on one material instantly flags every product that contains it.
Entity resolution. The hardest, least visible part. “Pump_P101” in the maintenance system, “P-101” in the MES and “asset 4471-A” in ERP must be recognised as one object, across millions of records. Get this wrong and agents confidently reason about three pumps that are really one.
Materialised or virtual. A graph can copy data into a graph store or leave it where it is and map it on the fly. Bosch’s plant in Salzgitter used the virtual approach: an ontology for surface-mount electronics manufacturing, mapped onto existing databases. Machine failures recorded differently across machines were reconciled into a single ontology class, so engineers could finally compare like with like.
Grounding generative AI. The same structure makes retrieval for language models sharper. LinkedIn built a graph from historical customer-service tickets instead of treating them as loose text. In production, the system cut median per-issue resolution time by 28.6%. The lesson carries straight to a service or quality organisation in manufacturing: structure beats a bigger pile of documents.
Where it sits: the foundation layer
In the CLEVR Digital Renovation Principle, the core systems form Layer 1: ERP, PLM, CRM, MES and in-house applications, the systems of record that stay clean and stable. On top of that core, the ontology and knowledge graph form Layer 2: the semantic context layer that every layer above it reasons against. Orchestration and intelligence live in Layer 3. People meet agents in Layer 4. The graph does not replace any system of record; it makes them understandable to each other. Together, the layers put the CLEVR principle into practice: keep the core clean, layer a smart orchestration platform on top of it, and amplify with AI where it makes sense.
Four layers · a clean core at the base, semantic context on top of it
Every agent and app in the upper layers draws its meaning from the same foundation, under the same trust layer.
Siemens Intelligence Center X is built on the same logic, in four steps:
- Enterprise data from heterogeneous sources and data platforms.
- Context: an ontology layer spanning the enterprise that gives every data point its meaning, delivered by Graph Studio.
- Intelligence: AI and ML models in AI Studio that learn from semantically enriched data, refreshed in near real time.
- Action: applications, workflows and agents built and orchestrated on Mendix, all rooted in the same context.
An enterprise trust layer runs across all four, with guardrails, traceability and auditability for both people and agents. Graph Studio’s engine is designed to handle tens to hundreds of billions of RDF triples, in memory, on disk or virtualised, and exposes the graph to agents through MCP so they can explore and query across domains.
The wider market is converging on the same idea. Microsoft made Fabric IQ, its ontology-based context layer for agents, generally available at Build 2026, and is opening the ontology to agents from other vendors through MCP. Databricks and Google have moved their semantic layers in the same direction, and Palantir has built Foundry around its Ontology for years. The question is no longer whether you need a semantic layer for agents. It is which one understands your domain, and whether it connects to the platforms you already run. Intelligence Center X connects to Microsoft Fabric, Snowflake, Databricks and Palantir rather than competing with them, and it differentiates on two things: the depth of industrial meaning it brings on day one, and a graph architecture built for the questions nobody anticipated.
Different approaches to the ontology layer
Not every ontology layer is built the same way. Look under the hood and the market splits into four architectural approaches, each optimised for a different job.
The first three are strong at what they were designed for. A metadata layer makes dashboards and SQL analytics consistent. An object layer works well when the decisions are known in advance and the objects can be curated for them. A transactional graph database is fast when a question starts from a known node, such as one customer or one asset.
Agents do not work that way. A hybrid workforce asks questions nobody anticipated when the data model was designed: which suppliers, parts, plants and customers are exposed if this material is restricted, across every product line? Such a question has no single starting point and crosses many hops and domains at once. On a metadata or object layer, it means building new models or new pipelines first. On a transactional graph database, it means traversing outward one node at a time, which slows down as the graph and the question grow.
Of the four approaches, only a scalable graph platform is designed for that question. Graph Studio, the context layer of Intelligence Center X, runs on a massively parallel engine that distributes the graph across the cluster, so every core works on every query. Its ontology is generated from the source systems and linked automatically, rather than authored by hand per source. That is the difference between agents that answer the questions you planned for and an agentic enterprise in which people and agents can ask any question, without running into performance limits.
This does not make the other approaches obsolete. Intelligence Center X connects to the data platforms you already run, and adds the context layer that lets agents reason across all of them.
Predefined industrial ontologies: not starting from a blank page
A predefined industrial ontology is a ready-made model of what things mean in manufacturing, so you extend it rather than invent it. This is where Intelligence Center X sets itself apart from generic semantic layers.
Siemens ships Intelligence Center X with industrial ontologies that encode industry reasoning across the product lifecycle. Out of the box, they cover the core objects of the digital thread: design, part, engineering BOM, engineering change, bill of process, service BOM, warranty claim, inventory and IoT time series. These are connected live to systems of record (PLM, ERP, CRM and in-house applications) and to data platforms such as Microsoft Fabric, Snowflake, Databricks and Palantir. Siemens describes this as data in context that is “live, secure, configured, out of the box”.
Why this matters is easiest to see in the BOM. An engineering BOM describes what the product is. A manufacturing BOM describes how it is made. A service BOM describes how it is maintained. In most companies these live in different systems, owned by different teams, with different identifiers. An ontology that already knows how an EBOM item relates to its MBOM counterpart, which engineering change affects both, and which service parts follow from them gives agents the digital thread as a navigable structure. It also reflects decades of Siemens experience with Teamcenter, Opcenter and the wider Xcelerator portfolio, knowledge that is expensive to recreate from scratch.
Siemens is not alone in this field. Several open initiatives define manufacturing semantics, and a good ontology strategy knows where they fit:
These are complementary rather than competing. The IOF Core is designed so that domain ontologies stay consistent with each other (IOF). The Asset Administration Shell structures asset information in submodels whose templates the IDTA publishes (all-about-industries). A predefined platform ontology gets you to production fastest; mapping it to open standards keeps you interoperable with suppliers and customers.
One honest caveat: no predefined ontology knows your company. Your product families, naming conventions, plant-specific processes and in-house systems still have to be modelled. Predefined ontologies shift the work from inventing to extending, which is the difference between months and weeks.
What it takes to build an ontology
Ontology design is a craft, not a configuration screen. It succeeds when it starts from decisions and is built with the people who make them. In our experience, it follows seven steps:
- Start from the decisions, not the data. Write down the questions agents and people must be able to answer: “Which customers are affected if supplier X fails?” “Which products are touched by this change?” Knowledge engineers call these competency questions. They define the scope and become the test set.
- Reuse before you invent. Start from a predefined industrial ontology and open standards such as the IOF Core or the Asset Administration Shell. Only model what makes your company different.
- Model with domain experts in the room. Engineers, planners and service leads know what a “release” or a “variant” really means. The Bosch integration work found that domain expert involvement was essential for both the ontology and its mappings.
- Map your sources. Connect fields in Teamcenter, SAP, the MES and your in-house apps to ontology concepts. Decide per source whether data is copied into the graph or queried virtually.
- Resolve entities. Decide which records describe the same real-world object, and keep those decisions explainable.
- Validate against reality. Run the competency questions. Check the ontology for logical consistency with a reasoner. Let agents query it and look at where they take wrong paths.
- Govern and evolve. Version the ontology, assign owners per domain, and keep the graph in sync with its sources. A graph that falls behind its source systems is yesterday’s data, and an agent acting on it is acting on the past.
This used to be the reason knowledge graph projects took a year before delivering value. Automation is changing that. Siemens positions automated ontology creation from source systems as a way to remove months-long ontology development and uses MCP-connected agents to help create and maintain the knowledge graph itself. Research points the same way: at Bosch, automatically reshaping a domain ontology into a leaner graph schema made knowledge graph generation for welding data seven to eight times faster.
Automation speeds up steps 2 to 5. It does not replace steps 1, 3 and 7. Deciding what your business means, and who is accountable for that meaning, stays human work.
One ontology for a hybrid workforce
A hybrid workforce only works when people and agents share the same definitions, the same rules and the same boundaries. The ontology is where all three live.
Same definitions. When a planner and a planning agent both mean the same thing by “available stock” or “released part”, hand-offs stop producing errors. Without that, every agent quietly carries its own interpretation in its prompt, and you have rebuilt the silos you were trying to escape.
Same rules. Policies expressed against business concepts rather than database tables apply to everyone. Intelligence Center X adds policy-driven access control to the knowledge graph, based on attributes of both the user and the data, so the same rule governs what a human user and an agent may see. A supplier-quality agent sees what a supplier-quality engineer may see, and nothing more.
Same trail. Because every action references concepts in the graph, the trust layer can log not just what an agent did but what it was reasoning about. That is what makes decisions auditable, and autonomy defensible.
This also creates new work for people. In our Digital Renovation whitepaper series we described roles like the Agent Supervisor and the Eval Owner. Add one more: the Ontology Steward, the domain expert who owns what a concept means and approves changes to it. Researchers have called this profile the knowledge scientist. Whatever you call it, organisations that skip it end up with a graph nobody trusts.
Where to start: one thread, not the whole enterprise
You do not need an enterprise-wide ontology before your first agent goes live. You need one valuable thread through your systems, modelled well, and a foundation that grows with every next use case.
Pick a workflow that crosses systems and hurts today. Quality is a good candidate. Siemens illustrates a typical warranty-to-engineering loop in which complaint triage, investigation and root cause analysis take two to four weeks, and resolution around eight. That loop touches warranty claims, service BOMs, as-built configurations, parts and engineering changes: exactly the concepts the predefined industrial ontologies in Intelligence Center X already cover.
From there, the CLEVR approach is the one we apply to every agentic programme: think big, start small, scale fast. Think big by designing the ontology as the shared foundation for your whole hybrid workforce. Start small with one thread, extended from a predefined ontology rather than drawn from scratch. Scale fast by letting every new agent, app and workflow reuse what the first one taught the graph.
Agents will keep getting smarter. Whether they get smarter about your business depends on the layer underneath them.
Find out how CLEVR can drive impact for your business
FAQ
Can't find the answer to your question? Just get in touch
