Semantically Speaking: Structure Is Not Grounding
Why the hardest semantic work for agentic artificial intelligence has to happen before the context window
Last week I read a thoughtful piece arguing that structure is the precondition for agency and that formal ontologies provide something agentic systems can’t reliably reconstruct from disconnected data, catalogs, and loosely governed graphs. This piece was published on LinkedIn by Julius Hollmann. I agree with the direction of the argument, but I think the more consequential architectural point sits one level deeper.
The semantic work shouldn’t begin when the agent begins reasoning. By the time information reaches a probabilistic model’s context window, many of the most important questions about identity, category, relation, constraint, and logical consequence should’ve already been resolved outside the model. Formal ontology matters not because it gives the model another artifact to read, but because it can support an architecture in which less meaning has to be invented at runtime. The context window should be the last mile of a semantic architecture, not the place where the architecture is invented.
The market is arriving at the semantic problem
There is clear evidence that parts of the technology market are moving toward something more stable than retrieved text for agents. Microsoft currently describes Fabric IQ Ontology as a governed shared business model and a shared context layer for agents and workflows, while noting that the capability remains in preview. AWS has now published Prescriptive Guidance for an ontology-driven semantic layer that separates data access, symbolic reasoning, constraint validation, mappings, and agent orchestration, and Neo4j documents open graph types for Cypher 25 in Enterprise Edition that constrain the nodes, relationships, and properties included in a graph type. Taken together, I read those developments as evidence that ontology is being discussed not only as a data-integration technology or an academic knowledge-representation discipline, but also as part of selected architectures for enterprise agentic systems. This is a market synthesis from the cited examples, not a claim that the whole market has adopted a single position.
But that makes precision even more important. If everything from a business glossary to a graph schema to a set of behavioral rules is called an ontology, then the word begins to hide the distinctions we need most.
A schema is not an ontology
Hollmann contrasts labeled property graphs (LPG) with formal ontologies and argues that LPGs gain agility by sacrificing an enforceable semantic schema. That contrast captures a real historical problem, but in 2026 it is no longer technically sufficient.
Neo4j’s current documentation says that open graph types, available for Cypher 25 in Enterprise Edition, can specify a graph schema for a database by constraining the nodes, relationships, and properties included in the graph type. The feature was introduced in Neo4j 2026.02 and became generally available in 2026.06. It is therefore no longer technically accurate to dismiss every LPG implementation on the simple ground that property graphs cannot enforce schema-level structure.
That doesn’t make a Neo4j graph type a Web Ontology Language (OWL) ontology. In fact, the W3C’s OWL 2 Primer makes the distinction unusually clear. OWL is an ontology language with formally defined meaning, but it’s not a schema language for syntax conformance and it’s not a database framework. OWL works under semantic assumptions that are different from conventional database constraints, including the open-world assumption under which absence of an assertion doesn’t normally license the conclusion that the assertion is false.
So the important distinction isn’t: Property graph equals no schema. Ontology equals schema.
The important distinction is between constraining the structure of a representation and making explicit commitments about the kinds of entities and relations represented by that structure. A data constraint can require an employee record to contain an identifier. An ontology can represent what kind of entity the employee is, what role is being borne, what organization stands in the relevant relation to that bearer, and which formal consequences follow from those commitments. Those are different jobs.
The Employee/Resource problem is more revealing than it looks
Hollmann gives a useful example. One team may call something Employee, another may call it Resource, and without an ontology an agent may not know that the two labels refer to the same concept. But that is exactly where ontology engineering has to slow the system down. Why should we assume they are the same concept?
The same person may appear as an employee in a human-resources system and as a resource in a project-planning system, but co-reference at the level of database rows doesn’t establish equivalence between the categories. Employee may classify a person according to an employment role. Resource may represent an allocation role, a planning category, an information-system designation, or something else entirely.
Those distinctions matter. If we simply normalize the two labels because they frequently point to the same people, we have not solved semantic drift. We may have formalized it.
This is one of the most important differences between vocabulary normalization and ontology engineering. Ontology doesn’t begin by asking which words look synonymous. It asks what kinds of entities those words designate and under what conditions the relations among them actually hold.
A realist ontology methodology makes that distinction explicit. Smith and Ceusters’ work on ontological realism treats ontology development as an effort to represent entities in reality coherently rather than merely coordinate database terms, and ISO/IEC 21838-2 standardizes Basic Formal Ontology as a top-level ontology designed to support information interchange among heterogeneous systems and to provide categorical structure for lower-level ontologies.
The same issue appears in another of Hollmann’s examples when a supplier “becomes” a partner. What became what? The organization may have persisted throughout the change. What changed may have been the role it bore in relation to another organization, agreement, or process.
A graph can easily connect Supplier to Partner with an arrow. Formal ontology forces the harder question about the entities on either end of the relation and what, exactly, persists through the change.
That is why ontology is powerful. Not because it lets us draw more kinds of arrows, but because disciplined ontology can stop us from turning roles into their bearers, information artifacts into their referents, processes into their outputs, or convenient labels into the entities they only imperfectly describe.
Formality doesn’t establish truth
This becomes even more important when formal reasoning enters the picture. Hollmann writes that with a formal ontology, reasoning becomes deterministic and explainable. There is an important truth in that statement, but only after we separate formal consequence from the grounding of the premises.
The W3C’s OWL specifications give a formally defined semantics under which reasoners can test questions such as consistency, satisfiability, subsumption, and entailment. That is extraordinarily useful because the logical consequences of accepted axioms do not have to be reinvented linguistically every time a user asks a question.
It still doesn’t tell us whether the asserted premises correctly represent reality. If an ontology incorrectly treats a role as the bearer of the role, a document as the event described by the document, or a coordinate representation as the portion of space it represents, a reasoner doesn’t repair the category mistake merely by producing deterministic consequences from it.
Formal reasoning can tell us what follows from the commitments. It doesn’t, by itself, warrant the commitments. Formality isn’t grounding.
That distinction is where many discussions of ontology and AI become too casual. A formal system can be consistent and still encode a bad account of the domain. A probabilistic system can produce a plausible ontology candidate and still lack the authority or independent evidential basis required to make that candidate the ground for its own subsequent reasoning.
If the same probabilistic mechanism proposes the semantic commitments and then uses those commitments as the warrant for its later conclusions, nothing independent has entered the loop. The system has not escaped the grounding problem by giving its own earlier output a more formal serialization.
OWL reasoning isn’t SHACL validation
The same discipline is required around the word validation. OWL reasoning and SHACL validation are not interchangeable activities. They answer different questions.
The stable W3C SHACL Recommendation defines a language for validating RDF data graphs against specified conditions represented in shapes graphs. OWL reasoning, by contrast, operates under the semantics of the ontology language and derives consequences from asserted axioms.
A graph can conform to its SHACL shapes and still embody a bad ontological analysis. An OWL ontology can be logically consistent and still contain categories that do not accurately represent the domain. A serialization can parse successfully while being semantically indefensible. And none of those results constitutes human release approval.
Parsing, OWL profile conformance, logical consistency, entailment, SHACL conformance, and competency-question acceptance produce different forms of evidence, while human approval is a separate authorization decision. Collapsing those checks and decisions into a single claim that an ontology has been “validated” hides exactly the distinctions an operational semantic architecture needs to preserve.
This isn’t a minor terminological dispute. If an agent is going to act on the basis of a semantic layer, the organization needs to know what kind of assurance each check actually provides.
The problem becomes more serious when agents can act
This isn’t only a philosophical concern because agentic systems can convert semantic mistakes into operational mistakes. NIST’s Generative AI Profile identifies confabulation as a characteristic risk in which generative systems confidently produce false or erroneous content. NIST also recommends documenting the use of human domain knowledge, reviewing and verifying sources and citations, and verifying provenance and grounding for training, testing, fine-tuning, and retrieval-augmented generation data.
Those recommendations are important even for systems that only generate prose. The stakes increase when the model can select a tool, invoke an operation, alter a record, initiate a workflow, recommend an allocation, or trigger another system.
At that point, semantic ambiguity becomes part of the control surface. If Customer, Account, Employee, Resource, Supplier, and Partner remain context-dependent labels whose interpretation is reconstructed during every invocation, then the organization has effectively delegated part of its domain model to a probabilistic runtime.
More context doesn’t solve that problem. It merely gives the model more material from which to select an interpretation.
The strategic signal is upstream of context
This leads to the signal that deserves far more attention: the location of semantic responsibility is changing. When identity, category, relation, constraint, and formal consequence remain unresolved until prompt assembly, the context window carries responsibilities that belong to the institution; when those commitments are established upstream, the model encounters a bounded representation rather than an invitation to reconstruct the domain.
The important distinction isn’t a prescribed technology stack or a fixed build order. Authoritative domain evidence and accountable human decisions supply the source basis, formal ontological analysis makes categorical commitments explicit, deterministic reasoners expose consequences entailed by accepted premises, and SHACL or other mechanisms test separately specified constraints. Governed mappings, metric definitions, and reusable results can then reduce repeated semantic interpretation, while the probabilistic model remains responsible for language, genuine runtime ambiguity, communication, candidate generation, and permitted orchestration.
For an executive team, this changes the questions. Several are especially revealing. They include:
· Which meanings are being reconstructed every time an agent receives context?
· Which identity and category decisions already have enough evidence to become reusable institutional commitments?
· Which conclusions are formal consequences of accepted premises, and which still require runtime judgment?
· Which checks provide technical evidence, and which decisions remain matters of human authority?
The answers signal whether the context window is serving as a last-mile interface or as an ungoverned substitute for prior semantic work. They do not prescribe one implementation, because domains, data, risk tolerances, and runtime requirements differ.
Pre-reasoning is a responsibility boundary
I use the term pre-reasoning to name that allocation of responsibility, not a chain-of-thought technique and not an invitation to make an LLM think longer. It distinguishes semantic decisions that can become governed and reusable from interpretation that genuinely belongs at runtime.
An authoritative metric definition, a governed mapping, a relation entailed under accepted axioms, or a deterministically checkable condition each signals a class of work that need not be reconstructed linguistically for every request. The strategic value lies in preserving those decisions outside any one prompt, model, or agent framework while leaving changing data and genuinely contingent questions open to runtime interpretation.
AWS’s current Prescriptive Guidance offers one concrete signal. Its Knowledge Layer includes a governed Metric Store in which reusable calculations can be represented as pre-defined expressions described by AWS as “ontology-grounded” and resolved deterministically at query time, explicitly without requiring an LLM to synthesize the calculation. I do not adopt every ontology-engineering claim in that architecture, but I read this separation of deterministic calculation from probabilistic generation as evidence that the responsibility boundary is becoming commercially legible.
Do the deterministic work deterministically. The phrase is less an implementation instruction than a signal about where repeated semantic discretion is accumulating.
Reuse is where the ROI question begins
The ROI case is a mechanism to investigate, not a promised return. Its potential value appears where organizations repeatedly pay for semantic rework, fail to reuse prior decisions, absorb operational risk from ambiguous meanings, or place avoidable context and token burden on probabilistic systems.
The corresponding executive questions are not about whether ontology is valuable in the abstract. They concern where the same ambiguity is already creating cost or exposure. Several are especially revealing:
· Where do teams repeatedly reconcile what account, employee, or measurement means?
· Which mappings, metric definitions, and identity decisions are rebuilt across integrations or agent workflows?
· Which exceptions, incidents, or audit questions trace back to categories that changed meaning across systems?
· Which model calls and context payloads are carrying semantic material that could instead be represented once and reused?
A sufficiently capable model can often produce a plausible answer to each local ambiguity, but plausibility doesn’t create an institutional decision that another system can safely reuse. The strategic opportunity is to reduce repeated semantic discretion where evidence and governance justify doing so, without pretending that every inference can be precomputed or every runtime uncertainty removed.
A credible ROI claim would still require a bounded comparison against a baseline and would have to include the investment in domain adjudication, formal modeling, mappings, validation, governance, and maintenance. Until that evidence exists, semantic rework, decision reuse, operational ambiguity, and runtime burden are candidate value levers to measure rather than quantified or proven returns.
The consequential question is what ontology changes
The strategic test isn’t whether an ontology can be retrieved alongside other documents. It is whether governed semantic commitments change what information is selected, how it is interpreted, which identities persist across systems, what distinctions cannot be collapsed, which formal consequences are available, and what constraints matter before action.
If none of those conditions changes, ontology is accompanying the context rather than functioning as infrastructure. If they do change, the relevant signal isn’t that an agent has received more information, but that the organization has reduced the set of meanings the agent is free to invent.
Microsoft’s current Fabric IQ documentation is evidence that large platform vendors are now explicitly positioning ontology as a shared context and grounding layer for agents, although the feature is still in preview. AWS’s current semantic-layer guidance separately exposes ontology, mappings, symbolic reasoning, validation, and deterministic metric resolution. These implementations are not proof that the semantic problem has been solved, and vendor architecture should never substitute for ontology methodology, but taken together I read them as evidence of a direction of travel.
The next question is whether the industry will preserve the distinctions necessary to make that architecture trustworthy. Business vocabularies are useful, but so are graph schemas, data catalogs, property graphs, SHACL implementations, the use of OWL and hopefully even a formal top-level ontology. But they are not synonyms, and their functions should not be collapsed merely because they can all participate in a semantic layer.
Formal ontology isn’t a substitute for governance
None of this grants an ontology authority simply because it is formal. Formal ontologists can be wrong the same way that domain experts can disagree and sources can conflict. If you have been in any industry long enough you know that requirements can and will change. That all signals that a model can be logically consistent and still require revision. In an open-world assumption environment, this is necessary.
That’s why the ontology must remain governed, versioned, attributable, testable, and open to correction. The advantage isn’t infallibility but instead that commitments can be inspected, challenged, traced to sources, tested for formal consequences, and revised through an accountable process rather than silently reconstructed inside an opaque probabilistic invocation. The final authority to adopt, change, or release those commitments will always remain to be intimately human and organizational.
Structure is necessary. Grounded structure has to come first.
Hollmann is right that structure is a precondition for reliable agency. But not every structure provides semantic grounding, and formal syntax doesn’t transform an unjustified category into a justified one. The more consequential principle for agentic AI is therefore this:
The agent should inherit semantic decisions wherever those decisions can be established before runtime. It should not be asked to manufacture the semantic ground on which its own reasoning depends.
That changes the role of ontology. Ontology isn’tisn’t there merely to make an LLM smarter. It is there to reduce what the LLM has to invent.
It makes stable meaning portable across models, tools, applications, databases, and agent frameworks. It allows formal consequences to be calculated independently of linguistic probability, while separate validation mechanisms can test operational requirements and governance can determine what becomes authoritative.
The context window should be the last mile, not the place where enterprise reality is invented. Do the logic before you spend the tokens.
Sources
2. W3C, OWL 2 Web Ontology Language Primer (Second Edition).
3. W3C, OWL 2 Web Ontology Language Direct Semantics (Second Edition).
4. W3C, Shapes Constraint Language (SHACL), W3C Recommendation.
5. ISO/IEC 21838-2:2021, Information technology — Top-level ontologies (TLO) — Part 2: Basic Formal Ontology (BFO).
6. Barry Smith and Werner Ceusters, “Ontological realism: A methodology for coordinated evolution of scientific ontologies,” Applied Ontology 5(3–4), 2010, DOI: 10.3233/AO-2010-0079.
7. NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, NIST AI 600-1, 2024.
8. Neo4j, Graph types — Cypher Manual.
9. Microsoft, What Is Ontology (Preview)? — Microsoft Fabric.
10. AWS Prescriptive Guidance, Semantic Layer for Agentic AI using Ontology, Symbolic Reasoning, and Virtual Knowledge Graph.
11. AWS Prescriptive Guidance, Knowledge Layer.
About Interstellar Semantics
Interstellar Semantics builds formal semantic infrastructure grounded in Basic Formal Ontology, the Common Core Ontologies, open standards, and authoritative domain evidence. The objective is to establish stable meaning before probabilistic systems are asked to interpret data or take action, while keeping semantic commitments inspectable, governed, portable, and under the client’s control. You can find us at www.interstellarsemantics.com