Governance That Agents Can Run: Why Enterprise AI Needs Semantic Intelligence

Open AGI Stack Semantic: Intelligence into the products. Governed meaning for enterprise AI. Make sense in your enterprise AI workloads.

October 19, 2026 · semantic.openagistack.com

TL;DR

• The problem. Enterprise AI stalls on meaning, not model quality. Governance already exists (owners, glossaries, quality rules, lineage, access policy), but it was written for people. An agent cannot call, check or cite a wiki page.
• The idea. Semantic intelligence makes governance executable: meaning is defined once, approved by the person who owns it, and served to every application and agent with its evidence attached.
• Nine governance buckets. Ownership, agreed definitions, metadata, data quality, lineage and provenance, the semantic layer, access rights and policy, data products, and AI agents. Each one has to change shape when the consumer is an agent rather than a person.
• Four runtime pillars. Meaning, relationships, rules and provenance, built on open standards: SKOS, OWL, SHACL, PROV-O and SPARQL.
• Four operating principles. AI drafts and humans approve. Ask, don’t guess. Rules run in code, not in prompts. Memory is never meaning.
• Early evidence. In a first smoke run (22 patient-care cases, one repetition per arm), an agent grounded at every step scored 84% on gate decisions, against 69% ungrounded and 66% grounded once. The intervals are wide and this is not a verdict; a five-repetition rerun is planned.
• Where it stands. Workspaces, packs, the concept editor, import and export, tenant isolation, grounded agent chat and a three-band resolver are built. The Context Broker, signed releases and release gates are planned. Long-term memory and assistant tasks are designs.
• How to start. One domain, 20 to 50 real questions, the ten costliest terms, and a grounded versus ungrounded comparison on the same questions.

Enterprise AI breaks when governance stops at the dashboard

Most enterprise AI projects stall on meaning, not on model quality. “Customer”, “active user” and “revenue” mean one thing in the CRM, another in the warehouse and a third in the policy PDF. A language model handed all three will answer fluently and inconsistently.

Data governance teams have worked on this for years: owners, glossaries, quality rules, catalogs, lineage, access policies. But most of that work was written for people. A definition lives on a wiki page, a policy in a PDF, an owner in a spreadsheet, and a human reads each one and uses judgment. An agent cannot do that. It needs ownership, definitions and rules in a form it can call, check and cite.

Semantic intelligence is where governance becomes executable. Business meaning is defined once, in a machine-readable form, approved by the people who own it, and served to every application and agent with its evidence attached. That is the job of Open AGI Stack Semantic: semantic intelligence for enterprise AI, a governed semantic layer plus the runtime that grounds agents.

This article walks through nine governance buckets you probably already have in some form, and shows what each one has to become when the consumer is an AI agent.

Each bucket is built on an open standard you can adopt today: RDF, OWL, SKOS, SHACL, SPARQL and PROV-O. Open AGI Stack Semantic combines them into four runtime pillars: meaning, relationships, rules and provenance. The nine buckets are what the business already governs. The four pillars are how that governance reaches an agent at the moment it acts.

1. Ownership: every piece of meaning needs a person who decides

Governance starts with decision rights. Who may define “active user”? Who approves a validation rule? Who can change what an agent is told? Without named owners, definitions drift toward whichever system is loudest.

The rule in Open AGI Stack Semantic is simple: AI drafts, humans approve. An LLM can propose a synonym or a definition, but it can never approve its own proposal or edit an authorization rule. Each pillar has its own human gate.

Decisions also need a way to ship. Meaning changes the way code does: nothing reaches runtime unless it is versioned, reviewed and tested.

• Everything happens inside a change set. There are no in-place edits, including the first import. A change set shows a semantic diff, a risk tier and the approvers it needs.
• Releases are immutable. The design calls for signed, content-addressed releases promoted from dev to prod by pointer, with rollback in under a minute.
• Evaluation gates releases. Golden questions run across more than one model, and a release with an unexplained change in behavior is blocked.
• The runtime never depends on the control plane. If governance is down, agents keep serving the last known-good release.

Status: change sets, the concept editor, import, export and forks are built. Signed releases, risk tiers and release gating are designed and on the roadmap.

2. Agreed definitions: one term, one meaning, and the words people actually use

A definition nobody can find is not agreed. A definition that ignores how people really talk is not used. Agreed definitions have two jobs: fix what a term means, and connect it to every way people say it.

Not every problem needs a full ontology. A controlled vocabulary fixes which terms are allowed, a taxonomy arranges them in a hierarchy, and a thesaurus adds synonyms and related terms. SKOS is the W3C standard for publishing these in RDF. It gives you concepts, broader and narrower links, preferred and alternative labels, and mapping properties such as exactMatch and closeMatch for linking one vocabulary to another. SKOS-XL extends it so a label can carry its own metadata.

For AI this is practical. When a user asks about “fourth-quarter sales”, the alternative labels let an agent resolve it to the same concept as “Q4 revenue”. Standards such as ISO 25964 guide how thesauri are built, and tools like Skosmos, VocBench and SKOS Play publish and check them.

Two habits keep this honest. Keep SKOS for the vocabulary people search and tag with, and OWL for the domain model, and never read a SKOS broader link as a class hierarchy. And start with the vocabulary: vocabulary first, ontology later is the principle that keeps the first project short.

3. Metadata: what turns a definition into something a machine can use

A definition on its own is not enough for an agent. It also needs the information around the definition: which labels to match, what the term is easily confused with, where the data lives, what unit it is reported in, who owns it and when it was last reviewed.

In Open AGI Stack Semantic, each concept carries:

• a definition, with its source
• preferred, alternative and hidden labels (the hidden ones catch typos and slang such as “chargbak”)
• a scope note for anything easily confused, such as total calcium and ionized calcium
• examples and data bindings to the columns or fields that hold the value
• an owner, a version and a review date

This metadata is what makes resolution work. Units act as clues: “6.5%” can only be an HbA1c result, and a bare number for a concept reported in two units triggers a question.

You do not have to invent the metadata vocabulary either. Reuse general vocabularies such as schema.org, Dublin Core, DCAT, PROV-O and FOAF, and find them through Linked Open Vocabularies. The OBO Foundry community shows what disciplined metadata looks like: opaque, persistent identifiers, one official label, a written definition with a source, a parent class and a life cycle, so a retired term is deprecated with a replacement rather than deleted.

4. Data quality: validate the facts, and validate the meaning

OWL infers what could be true; SHACL checks what must be true. A shape states that every Supplier needs exactly one name, a country code from an approved list, and a link to a contract. Data that breaks a shape is flagged before it reaches the graph or the model.

@prefix sh: <http://www.w3.org/ns/shacl#> .
@prefix ex: <https://example.com/> .

ex:SupplierShape a sh:NodeShape ;
  sh:targetClass ex:Supplier ;
  sh:property [ sh:path ex:name ;        sh:minCount 1 ; sh:maxCount 1 ] ;
  sh:property [ sh:path ex:countryCode ; sh:in ( "NL" "DE" "IN" ) ] ;
  sh:property [ sh:path ex:hasContract ; sh:minCount 1 ] .

ShEx is a compact alternative with the same goal. Open implementations include pySHACL, Apache Jena SHACL and TopQuadrant SHACL, and you can experiment in the SHACL playground.

For AI workloads, validation is the gate that stops bad or hallucinated facts from becoming trusted context. That holds for extraction too. LLMs can extract triples from raw text (OntoGPT is one tool), but extraction is only safe when it is constrained by an ontology, checked with SHACL and approved by a person.

Quality also has a semantic side. Open AGI Stack Semantic runs consistency checks on every change, validates data before anything loads from schemas, glossaries, documents and source systems, and tracks the term-misuse rate: how often an agent uses a term in the wrong sense.

Status: concept schemes, typed relationships and quality checks are built, not yet deployed.

5. Lineage and provenance: trace the answer, not just the table

Classic lineage follows data from source to report. Agents need that, and one more thing: lineage for the answer itself. An auditor wants to know which definition the agent used, which version of the rule applied, who approved both, and where each input value came from.

That is the provenance pillar. Every item in the graph carries its source, version, approver, confidence and freshness, and the same applies to every answer. The standard underneath is PROV-O. RDF 1.2 adds triple terms, which let you make statements about statements, such as who asserted a fact and how confident they were.

At runtime, provenance shows up in three ways:

• A receipt on every answer: the release, the concept and rule versions, who approved them, the source of each input and a replayable trace id.
• An explain call that tells an agent, or an auditor, why a piece of context was included.
• A task anchor set (described under AI agents below), whose copy goes into the receipt so an auditor can replay what each word meant at each step.

Provenance is what makes the other pillars trustworthy, so it wraps all of them. In the first evaluation, receipt completeness was 0% for an ungrounded agent and 91% for one grounded at every step.

Status: receipts are working in the evaluation harness. Signed release manifests are planned.

6. Semantic layer: relationships, rules of inference and a map for the model

Definitions say what things are. The semantic layer says how they connect. It is an ontology plus a knowledge graph, and it gives an LLM a map.

The core data model is RDF. Every fact is a triple of subject, predicate and object, and millions of triples form a graph. Because identifiers are global, two systems can merge their data without a schema migration. See the RDF 1.1 Primer and the JSON-LD playground.

@prefix ex: <https://example.com/> .

ex:Acme   ex:hasSupplier ex:Globex .
ex:Globex ex:locatedIn   ex:Rotterdam .

RDFS lets you declare classes, properties and hierarchies. OWL adds richer logic: disjoint classes, cardinality, transitive and inverse properties. A reasoner such as ELK, HermiT or Openllet reads these axioms and infers new facts.

ex:PremiumCustomer rdfs:subClassOf ex:Customer .
ex:Acme a ex:PremiumCustomer .

Here a reasoner concludes that Acme is also a Customer, though nobody stated it. OWL 2 comes in profiles (EL, QL, RL) that trade expressive power for speed, so large enterprise datasets usually use a lighter profile. Remember that OWL assumes an open world: a missing fact is unknown, not false. The usual workbench is Protégé, Owlready2 and ROBOT; the OWL 2 Primer is the gentlest introduction.

Why not vectors alone? Pure vector search matches strings that sound similar, not concepts that mean the same. That produces a predictable set of failures.

The pattern that holds up is: the graph narrows, vectors rank. GraphRAG (Microsoft GraphRAG, the Neo4j GraphRAG library, Graphiti) retrieves entities and relationships instead of loose text chunks. Open AGI Stack Semantic places the semantic layer between the user’s words and the content:

1. Normalize the query: case, Unicode, punctuation.
2. Resolve each mention to a concept, trying exact labels, then fuzzy matching, then embeddings.
3. Apply a confidence policy: proceed, proceed and say so, or ask the user.
4. Expand within bounds: whitelisted relations, one or two hops, a hard cap.
5. Retrieve inside the scope the concepts and facets define, then rank.
6. Package the context with the interpretation, the facts used and their provenance.

Two rules keep this honest: concepts, not strings, are the unit everything downstream uses, and every expansion is bounded and logged so you can explain why a piece of context was included.

SPARQL 1.1 is the W3C query language for the graph. Property paths let one line walk a whole hierarchy:

PREFIX skos: <http://www.w3.org/2004/02/skos/core#>
PREFIX ex:   <https://example.com/>

SELECT ?narrower WHERE {
  ex:PaymentReversal skos:narrower+ ?narrower .
}

Good starting points are the Wikidata SPARQL tutorial, YASGUI and Sparnatural. The next section explains why agents should not write it freehand.

Status: bounded expansion and semantic fallback are next. The Context Broker as an MCP and REST service is planned. Document retrieval scoped by concepts is planned, deliberately later.

7. Access rights and policy: rules that run in code, not in the prompt

Governance also decides who may see and do what. For agents there is a second question: what may the agent do on its own? A rule in a prompt is a suggestion; a rule in code is a gate. Open AGI Stack Semantic keeps its rules in code, in five types: validation, derivation, authorization, obligation and threshold rules, each with tests. Authorization uses Cedar, and validation uses SHACL.

Agents get typed, read-only calls, not free-form queries. A model that writes free-form SPARQL can time out a store, read data it should not see, or return a plausible but wrong pattern. Where SPARQL is exposed, the safe pattern is a named, parameterized template with a row limit, a timeout and a named-graph allowlist per tenant. Tools such as grlc turn saved queries into exactly that kind of API. Every call is traced.

Each action is checked before it runs. The check_action call tests a tool call against the rules. A denied call is cancelled and the reason goes back to the model.

Isolation is structural. Each tenant is its own organization with its own sign-in and its own workspaces. Each new workspace runs in its own cell, with its own API, data store and storage, so one workspace cannot read another’s data.

Agents never hold more authority than the user. The planned assistant runs tasks as the user and never as more than the user. Anything that changes something, such as drafting a change set, stays visible for review. Approving, releasing and publishing are never available to it.

Status: multi-tenant sign-in and per-workspace isolation are built. Policy and release gates are planned.

8. Data products: meaning, packaged, versioned and consumed

A governed definition becomes useful when others can consume it with confidence. That is what a data product is: something with an owner, a version, a contract and known consumers. Open AGI Stack Semantic treats meaning as a data product.

Packs are versioned, read-only ontology modules installed into a workspace. The catalog includes Enterprise Core and six industry starter packs (Healthcare, Hospital Systems, Airlines, Life Sciences, Pharma and BFSI), plus a Patient Care pack that layers laboratory vocabulary on a FHIR care model. A team installs the packs it needs, then specializes them in its own editable projects, or forks a pack to make one of its own. Upstream meaning can be extended but never silently contradicted.

You do not start from scratch. Adopt what expert communities already standardized and extend it only where your business needs something the standard lacks.

Imports are dated and deliberate: each ontology is imported at a specific version and upgraded on purpose. One more habit keeps a model small: write the competency questions the model must answer before you add anything, and let every class, property and axiom trace back to one of them.

Portability is part of the contract. Import and export round-trip. You can import an existing Turtle or RDF/XML ontology, edit it in the concept editor, and export it again. Constructs the model cannot place are kept as residual axioms and re-exported unchanged. Because the model rests on open standards, changing LLMs or vendors leaves your meaning where it is.

What the consumer receives is the context packet. The Context Broker returns meaning, relationships, rules and provenance in one plain-JSON envelope, and every item points to its provenance record. It works the same for any agent framework or a hand-written agent. Here is one question going through it.

A laboratory triage agent is asked: “Is the 2.05 mmol/L calcium on this serum sample low?” The word “calcium” is the trap, because total calcium and ionized calcium are different measurements with different reference ranges.

1. Meaning. Calcium resolves to Total calcium, not Ionized calcium. The unit and the specimen push confidence to 0.94, above the 0.85 threshold. Below it, the agent would ask instead of guessing.
2. Relationships. The task profile sends only the relevant neighborhood: total calcium is corrected by albumin, measured in serum, and has an adult serum reference range.
3. Rules. A derivation rule says to correct total calcium for albumin before comparing it to the range when albumin is low. A step that compares the raw value fails verification, and the verifier names the missing step.
4. Provenance. The answer carries a receipt: the release, the concept and rule versions, who approved them, the source of the albumin value and a replayable trace id.

{
  "release": "lab-medicine@2.3.0",
  "meaning": [{
    "term": "calcium", "concept": "lab:TotalCalcium",
    "confidence": 0.94,
    "alternatives": [{ "concept": "lab:IonizedCalcium", "confidence": 0.06 }],
    "prov": "p1"
  }],
  "relationships": [
    { "from": "lab:TotalCalcium", "edge": "corrected_by", "to": "lab:Albumin", "prov": "p2" }
  ],
  "rules": [{
    "id": "R-LAB-014", "type": "derivation", "severity": "must",
    "statement": "Correct total calcium for albumin before comparing to the range.",
    "prov": "p3"
  }],
  "provenance": {
    "p1": { "version": "1.4.0", "approved_by": "Clinical biochemistry lead", "trust": "high" }
  }
}

This is what “intelligence into the products” means in practice. The product does not hope the model knows what calcium means. It hands the model the governed meaning, the connected context and the rule that applies, and keeps the evidence.

9. AI agents: ask, don’t guess, and stay anchored at every step

The agent is the consumer all eight earlier buckets exist for. Two behaviors matter most: what it does when it is unsure, and what it does over many steps.

Ask, don’t guess

A wrong confident answer is worse than a clarifying question, so the resolver never corrects a term silently at low confidence. It tries layers in order and stops when it is sure.

The confidence policy then decides what the agent does.

Details make this work in practice. All-caps abbreviations match case-sensitively, so “AR” is not “ar”. A fuzzy match never lands on a word that is another concept’s exact label, which is why “cart” never becomes “card”. An abbreviation shared by two concepts is attached to both and settled by context.

The first three bands are built and tested. On an offline set of 285 queries for the patient-care pack, covering typos, slang, abbreviations, ambiguous cases and look-alike negatives, the resolver produced no wrong silent resolutions. Semantic and shortlist layers are still on the roadmap.

Re-anchor at every step

Most context layers hand an agent its facts once, at the start. In a multi-step task, one wrong hop, such as the wrong sense of a term or the wrong unit, then carries through to a confident final answer. Open AGI Stack Semantic re-anchors the agent at each step of its loop, in code rather than in the prompt.

1. Interpret. Resolve the domain terms in the request. If a term is ambiguous or below the threshold, stop and ask.
2. Act. Check each tool call against the rules before it runs. A denied call is cancelled and the reason goes back to the model.
3. Refine. Check each tool result and intermediate claim. A claim that uses a different sense than the one fixed earlier is rejected as sense drift.
4. Optimize. Bind an objective such as “best” or “most urgent” to a governed metric, or ask.

A small task anchor set holds the sense each term has in the current task. It lives outside the model, so the model cannot rewrite it, and a copy goes into the receipt.

The same agent, model and questions run in three modes, graded by code against known answers:

• A0, ungrounded: the agent gets the same knowledge as plain text through keyword search.
• A1, grounded once: resolution and context at the start of the task only.
• A2, grounded at every step: all four steps above, plus the anchor set.

The first live evaluation, on 22 patient-care cases with 32 steps and one repetition per arm, was a smoke run, so its intervals are wide and it is not a verdict.

Two patterns stand out. A2 was the only arm that held a term’s sense across a multi-step task, while A1 grounds each message alone and so asks again on every follow-up. And because a clarification ends a step before any model call, the grounded arms used about a third of the tokens. The run also exposed grounding gaps and grader bugs, which were fixed and released, and a rerun with five repetitions is planned so the arms can be compared with narrow intervals.

Strands Agents is the first connected framework. Nine more code-first frameworks on AWS, including CrewAI, LangGraph and the OpenAI Agents SDK, are listed and waiting for a grounding adapter each, because the runtime keeps grounding separate from any one framework.

Memory is never meaning

A language model is stateless, so an agent that works over days needs memory. Cognitive science separates many kinds, and a vector store alone covers only a few. Open AGI Stack Semantic makes semantic intelligence the home of three of these: relational, meta and collective memory. Relationships live in the graph, confidence and source live in provenance, and shared institutional knowledge lives in the governed vocabulary that every agent uses.

For what a user tells an agent, the design adds long-term memory with the open-source mem0 library, self-hosted in your own AWS account, with vectors in S3 Vectors so an idle stage has no fixed cost. One rule governs it: memory is never meaning. Remembered items reach the model in a separate block, labelled with their date and source, and they are never shown as definitions. Where memory and the governed vocabulary disagree, the vocabulary wins and the disagreement is recorded.

That rule has a concrete effect on resolution. If a user once chose ionized calcium when asked what “Ca” meant, a later chat may lift that term from ask to interpreting, and say so, but never to silent. The remembered choice is ignored if its concept has since been deprecated. Vocabulary that users keep supplying is not stored as memory at all. It goes to the stewardship queue, where a person decides whether it belongs in the governed vocabulary.

Status: grounded agent chat with Strands, three grounding modes and token limits are built. Long-term memory and assistant tasks are designs and early plans, not shipped features.

The loop closes: measure what each definition earns

Governance programs often struggle to show their value. Semantic intelligence can, because agents leave a trail.

Every unknown term, ambiguous term, user correction and rephrased question is a signal that the vocabulary has a gap. The design ranks these by frequency and business cost and drafts a fix, such as a hidden label or a scope note, into a change set for a steward to approve. After approval the same traffic shows whether the gap closed. That makes each definition measurable: you can see what it earned.

Where it stands today

Open AGI Stack Semantic is an ontology-based knowledge layer. It starts as a controlled vocabulary and grows step by step into taxonomies, schemas and a knowledge graph. It lives in infrastructure you control and does not depend on any one LLM, platform or vendor. Behind the four pillars sit five cooperating parts: the Ontology Engine (versioned objects, layered from an enterprise core to domain ontologies to task overlays), the Control Plane (authoring, review, versioning, evaluation gates and access), the Data Pipeline (feeds from schemas, glossaries, documents and source systems), the Knowledge Graph (ontology and facts, with provenance on every edge) and the Context Broker (delivers the right slice to each agent and sends runtime gaps back to the Control Plane).

The roadmap is explicit about what is built and what is not.

The order is deliberate. Concept-scoped document retrieval depends on schemes, typed edges, the confidence policy and the gap loop being right first, so those come before it.

Start small: one domain, one set of questions, one measurable gain

You do not need a finished ontology to begin, and you do not need to rebuild your governance program. Start with what you already have: the owners, the glossary, the quality rules.

1. Pick one high-value domain and write 20 to 50 real questions your agents must answer. Every later modeling decision should trace to one of them.
2. Name the owner who approves definitions for that domain.
3. Install the closest pack and import any glossary, SKOS file or ontology you already have.
4. Define the ten costliest terms: a definition, synonyms, hidden labels for the typos and slang people really use, and a scope note for anything easily confused.
5. Connect an agent and compare it grounded and ungrounded on the same questions.
6. Measure the term-misuse rate, the share of answers you can trace, and one business KPI. Then close the next gaps and expand.

A sensible bar for a first pilot is a large drop in term misuse on the gaps you closed and most answers traceable to governed terms. Agree the exact targets with the domain owner before you start, and measure them rather than assuming them.

Further reading

• Knowledge Graphs, the book and Validating RDF Data
• Ontology Development 101 and the Protégé pizza tutorial
• SKOS Primer, OWL 2 Primer and SHACL
• Tim Berners-Lee’s Linked Data design note and the W3C Semantic Web overview
• Microsoft Ontology Playground for trying a model hands-on
• GraphRAG for graph-based retrieval

Open AGI Stack Semantic: Intelligence into the products. Governed meaning for enterprise AI. Make sense in your enterprise AI workloads. Learn more at semantic.openagistack.com.

Sources

The semantic web, ontology and knowledge graph concepts follow the W3C standards and the community resources linked above. Product capabilities and status are taken from the Open AGI Stack design and roadmap documents as of October 19, 2026.