Most teams meet the idea of an ontology as a way to let an AI agent read business data. An operational ontology goes one step further and lets the agent ask for a change, such as canceling an order, without handing it raw write access to a table. This guide covers how the read path and the write path differ, how an operational ontology compares with an active ontology, and which context each action needs. It then shows how to release one action to an agent at a time.
What is an operational ontology?
An operational ontology connects a semantic model of business objects and relationships to named, governed actions that run through live operational systems. When an action is approved, the operational system applies the requested change to the business object through its own tool or API. Write-back carries that change to the system of record and records whether it succeeded or failed.
Atlan, the Context Layer for AI, supplies the governed definitions, lineage, and context behind the permissions and decisions that the ontology and its actions depend on.
An ontology in AI models business concepts, their relationships, and constraints, and its core components give each governed action a consistent meaning.
Take a customer who asks an agent to cancel an order. The ontology defines order and shipment as business objects, links an order to its shipment, and attaches a cancellation action to the order. It also states the conditions the action must meet, such as refusing to cancel once the order has shipped.
The agent uses that model to find the right order, inspect its current link to the shipment, and request cancellation. The order system then checks the caller’s authority and the current business conditions before it applies the change through its approved API.
The meaning behind those checks often lives in several systems at once. A status of “complete” could mean payment cleared in a billing system or delivery finished in a fulfillment system. If the ontology treats the two as interchangeable, the agent can request the wrong action even when it calls the correct API.
According to McKinsey (2026), eight in ten companies cite data limitations as a roadblock to scaling agentic AI. For agents, those limitations show up as definitions, policies, and evidence that sit apart in different systems. Pulling them together is the case for an enterprise context layer for agents.
An operational ontology brings that context into the action workflow. Reading evidence and changing an operational record need different controls, which is why the model splits into a read path and a write path.
How does an operational ontology work? The read path and the write path
The read path gathers the evidence an agent needs to decide what to request. The write path sends that request through a controlled gate. Both use the same ontology, and only the write path can change the state held in an operational system. The order-cancellation example shows both.
The read path: assemble the evidence
For an order cancellation, the agent starts at the Order object and follows its links to the customer, the payment, and the shipment. It retrieves the current fulfillment state, the applicable cancellation policy, and when each value was last checked.
Within the caller’s permissions, the agent can traverse these connected objects without knowing which tables or applications hold the data. The ontology gives each value a consistent business meaning, so the agent can tell that a shipment belongs to the order it was asked to cancel.
Reading the ontology does not grant unrestricted access. Access control for AI agents decides which objects and properties the caller may inspect. Role-based access in the context layer scopes the context the agent receives, and the operational service separately decides whether the caller may perform the requested action.
The write path: request a business operation
The write path turns the agent’s request into a named business operation, such as cancelOrder, instead of a generic update to the underlying record. The action defines its target, its required inputs, its business conditions, and its possible outcomes.
Togo Yamanaka’s operational ontology walkthrough shows this pattern with named actions, rule-based refusals, and an audit record for every attempt. For a retailer that forbids cancellation after shipment, the action runs in four steps:
- Identify the request. Receive the order identifier, the cancellation reason, the authenticated caller, and a request identifier that separates a retry from a new request.
- Check authority and current conditions. Confirm the caller may request the action and fetch the authoritative fulfillment state. Refuse the request if the caller lacks permission or the order has already shipped.
- Execute the action. Call the order system’s approved cancellation tool or API. The operational system enforces the conditions when it commits the change.
- Confirm and record the outcome. Report a cancellation only after the system of record confirms it. Record whether the request succeeded, was refused, or failed, along with the evidence and the rule version used.
The second state check matters because the order can ship after the agent first reads it. The early read helps the agent decide what to ask for. The operational system protects the update by using the freshest state available when the action runs.
Execution failures need explicit outcomes too. If the order system times out, the action service cannot assume the cancellation failed, and it cannot safely repeat it without checking. It reconciles the request with the system of record, or relies on the operational system’s retry protections, before it reports a result.
A decision trace ties together the request, the evidence, the policy, the tool call, and the confirmed result. Agent guardrails make refusal or escalation the expected outcome when the caller lacks authority, the evidence is incomplete, or the source system cannot confirm the change. The enterprise AI agent guardrails checklist lists the controls to review.
Operational write-back and reverse ETL can look alike, since both can update data in a business application. Reverse ETL typically syncs modeled data into the application. Operational write-back performs a single named business action with preconditions, a result that can be a refusal, and an audit record.
What is the difference between an operational ontology and an active ontology?
Operational and active describe different properties of an ontology. Operational asks whether the model connects business objects and relationships to governed actions. Active asks whether its meaning stays current as lineage, schemas, and policies change. An operational ontology can be stale, and an active ontology can be read-only. Reading up on what an active ontology is helps teams judge freshness separately from execution.
| Operational ontology | Active ontology | |
|---|---|---|
| Question it answers | Can the model request governed actions? | Does the meaning stay current? |
| What it connects | Objects and links to named actions and write-back | Definitions, relationships, and policies to live lineage and schema changes |
| How it fails | Runs a valid action on outdated meaning | Stays accurate but cannot change anything |
| What it needs | Permissions, preconditions, explicit outcomes, an audit record | Owners and a process for updating each definition |
The order-cancellation example shows why the difference matters. The cancellation action keeps working after the business changes its eligibility policy. If the ontology still holds last quarter’s rule, the operational system can run a technically valid action on outdated meaning.
An operational ontology therefore needs active meaning beneath it. Its definitions, relationships, and policies need owners and a process that keeps them current as the business changes.
From Ontology to Context Layer: What Actually Changed With AI?
Source: Atlan on YouTube
Several related components feed that foundation:
- Semantic layer. A semantic layer makes business definitions and query logic reusable. Ontology vs. semantic layer explains that an ontology models business concepts and relationships while a semantic layer gives consistent ways to query data. Governed actions still need an execution path of their own, and MCP semantic layers for AI agents cover how agents reach those definitions.
- Knowledge graph. A knowledge graph represents connected facts about entities. As the comparison of ontology vs. knowledge graph explains, the ontology supplies the conceptual rules and the graph holds the connected facts. A governed business action is a separate design on top of both.
- Context graph. A context graph connects the evidence, decisions, and outcomes around an action. The comparison of context graph vs. ontology separates the circumstances of a decision from the business concepts used to read them.
Together these can work as systems of semantics. Giving each component a clear owner keeps business meaning current and stops the action service from becoming the only place where meaning is defined.
How does Atlan provide the context behind operational actions?
An operational action can pass every technical check and still produce the wrong result if it relies on an outdated definition, incomplete evidence, or the wrong source.
Each action therefore needs current definitions, approved policies, lineage, source authority, and ownership across every system in the decision. An enterprise context layer brings that information together and serves it to agents and applications when they request an operation. Each runtime then stops keeping its own reading of concepts such as “customer,” “shipped,” or “eligible for cancellation.”
Atlan covers the context behind an operational action with four connected capabilities:
- Context Agents use SQL patterns, query history, lineage, and usage signals to draft definitions and map relationships. Orion, the Ontologist agent, maps the ontology that connects domains and metrics. Stewards review and certify what the agents produce.
- Context Engineering Studio assembles context for a use case, tests it with generated questions and evaluations, and deploys it to the target platform once the team approves it.
- Enterprise Data Graph connects business terms to technical assets, owners, policies, and lineage. Lineage shows known downstream dependencies. The owner of the operational action still documents transactional effects that lineage does not show.
- Context Lakehouse stores approved context and serves it over MCP, SQL, and APIs, so agents in different environments read the same certified meaning. Agents can also write observations, quality signals, and usage patterns back to it through A2A.
In the order-cancellation example, Atlan holds the certified meaning of order status, the owners of the order and shipment assets, the cancellation policy, and the lineage into the tables behind them. An agent reads that context through Atlan MCP. Pairing a platform-native ontology with a context layer keeps the existing action model and extends the context available to it.
Atlan supplies the context for the cancellation decision, and the order system remains responsible for executing it. The order system checks the caller’s authority and the current business conditions, then processes the approved cancellation through its own tool or API.
What should teams do next to put an operational ontology into practice?
Start with an action whose rules and outcome are easy to verify. For order cancellation, limit the first release to a defined group of orders, one authoritative order system, and a clear escalation route.
That gives an ontology-first AI architecture a concrete job. Instead of modeling the whole business, teams designing an ontology for AI can begin with the objects, relationships, and rules that one decision needs. Teams that run more than one platform can read how to extend an ontology beyond a single warehouse.
Use the first release to set up a repeatable process:
- Discover the existing meaning. Find the relevant records, status mappings, policies, and source owners.
- Certify the context. Ask domain owners to approve definitions, resolve conflicts, and name the authoritative sources.
- Connect the operation. Expose the action through an approved, authorized service with current-state checks, explicit outcomes, and retry protection.
- Test refusals and failures. Cover shipped orders, unauthorized callers, missing data, conflicting statuses, duplicate requests, and source-system timeouts.
- Review before expanding. Examine wrong decisions, refusals, and unresolved updates. Feed confirmed corrections into context review before you add another action.
Research points the same way. Luong Tuan and Sanyal (2026) report that ontology-grounded scenario generation reached 48.3% regulatory coverage against 33.1% for a persona-based baseline. The authors also note that its advantage over plain and retrieval-augmented prompting did not survive statistical correction. The result supports testing a wider range of domain scenarios. It does not show that an ontology makes an action safe.
Zhu et al. (2026) report 98.74% tool-chain F1 for an ontology-governed simulation, against baselines that reached 24% to 36% F1 on the same measure. That figure applies to the evaluated tool chains, not to enterprise agents in general. It does argue for inspecting the sequence of operations behind a result before an agent gets access to a live action.
When you implement an enterprise context layer, define source authority and ownership from the first release. A context layer reference architecture clarifies who collects, approves, maintains, and serves the context as the operational ontology grows. The same discipline applies to AI agent governance and to context engineering for AI agents more broadly.
What does DigiKey say about context in operational systems?
Sridher Arumugham, Chief Data Analytics Officer at DigiKey, describes context that has to reach the systems where work happens.
How DigiKey uses Atlan as a context operating system
"Atlan is our context operating system to cover every type of context in every system including our operational systems. For the first time we have a single source of truth for context."
Sridher Arumugham, Chief Data Analytics Officer
DigiKey
Moving forward with an operational ontology
An operational ontology connects objects and links to named, governed actions, and it splits the work into a read path that gathers evidence and a write path that requests and records a change. It works only when the meaning underneath stays current, which is the job of an active ontology and a context layer.
Pick one action, certify the context behind it, test the refusals and failures, and release it to a bounded group of records. Add the next action only after you have reviewed what the first one got wrong.
FAQs about operational ontologies
1. What is an operational ontology, in one sentence?
An operational ontology connects business objects and their relationships to governed actions that run through operational systems. A person, application, or agent requests a named action, and the system of record checks permissions and current conditions before it applies the change and logs the result.
2. What are the parts of an operational ontology?
It has four parts: objects, links, actions, and write-back. Objects are business entities, links are the relationships between them, actions are the named operations people and agents may request, and write-back applies an approved change to the system of record and records whether it worked.
3. How is an operational ontology different from a regular ontology or a knowledge graph?
A regular ontology defines concepts and constraints, and a knowledge graph stores connected facts about entities. An operational ontology adds named actions on top, each with permissions, preconditions, and explicit outcomes, so a request can change an operational system under rules instead of only describing it.
4. How is an operational ontology different from an active ontology?
Operational means the ontology supports governed actions. Active means its definitions, relationships, and policies stay current as lineage, schemas, and business rules change. The two are independent: an operational ontology can be stale, and an active ontology can be read-only. Agents that change records need both.
5. How is operational write-back different from reverse ETL?
Reverse ETL typically syncs modeled warehouse data into business applications on a schedule. Operational write-back carries out one named business action with preconditions, a result that can be a refusal, and an audit record. The first moves data in bulk; the second changes one record under rules a person can inspect.
6. Why do AI agents need an operational ontology before they take actions?
Agents need consistent definitions, a list of permitted operations, and business rules before they request changes. The operational ontology organizes that meaning so the agent asks for the right action on the right record. The operational system still enforces authority and current conditions when the change commits.
7. Who builds an operational ontology, and how long does it take?
Domain experts, data teams, application engineers, security teams, and operational owners build it together. The timeline depends on the domain, the quality of source definitions, the APIs the operational systems already expose, and how many approvals each action needs. Starting with one bounded action keeps the first release short.
8. Can one operational ontology serve agents running on different platforms?
Yes, when its definitions and action interfaces are reachable from each platform. Atlan serves approved context through MCP, SQL, and APIs, so agents in different environments can read the same certified meaning. Each operational system still enforces its own authorization and execution rules when an action commits.
9. Where do the definitions and policy rules behind each action come from?
They come from business policies, operational systems, SQL, BI logic, lineage, and domain experts. Atlan Context Agents can propose definitions from those signals, but accountable owners resolve conflicts and approve them before an agent depends on them.
Sources
- Building an Operational Ontology: An E-Commerce Walkthrough, Togo Yamanaka, Data Engineering Weekly, 2026. https://www.dataengineeringweekly.com/p/building-an-operational-ontology
- From Business Events to Auditable Decisions: Ontology-Governed Graph Simulation for Enterprise AI, Zhu et al., arXiv preprint, 2026. https://arxiv.org/abs/2604.08603
- Toward Pre-Deployment Assurance for Enterprise AI Agents: Ontology-Grounded Simulation and Trust Certification, Luong Tuan and Sanyal, arXiv preprint, 2026. https://arxiv.org/abs/2606.04037
- Building the foundations for agentic AI at scale, McKinsey Technology, 2026. https://www.mckinsey.com/capabilities/mckinsey-technology/our-insights/building-the-foundations-for-agentic-ai-at-scale
- Context Agents, Atlan, 2026. https://atlan.com/context-agents/
- What is Context Engineering Studio, Atlan Documentation, 2026. https://docs.atlan.com/product/capabilities/governance/context-engineering-studio/concepts/what-is-context-engineering-studio
- Context Lakehouse, Atlan, 2026. https://atlan.com/context-lakehouse/
- Enterprise Data Graph, Atlan, 2026. https://atlan.com/know/enterprise-data-graph/
- DigiKey context readiness, Atlan Regovern Watch Center, 2026. https://atlan.com/regovern-watch-center/digikey-context-readiness/
- EP. 04: From Ontology to Context Layer: What Actually Changed With AI?, Atlan on YouTube, 2026. https://www.youtube.com/watch?v=MAYI7tDowBc
