--- title: "How Do AI Agents Use an Ontology? One Request Traced Step by Step" url: "https://atlan.com/know/ai-agent/ontology/how-agents-use-ontology/" description: "Trace how AI agents use an ontology at runtime to resolve terms, plan queries, apply policy context, coordinate handoffs, and explain each answer." author: "Karthik Pasupathy" author_role: "Contributing Writer, AI Context & Agents" published: "2026-10-27" updated: "2026-10-27" --- > Atlan is hosting Context Conference, bringing together the leaders and builders at the frontier of giving AI the context it needs to understand their business. It runs online on October 28, 2026, from 11:00 AM to 2:00 PM ET. Atlan co-founder Prukalpa Sankar opens and closes the day. Leaders from AstraZeneca, BNY and Verizon share why they invest in context and what they get from it. Registrants get early access to The AI Context Gap, a new study from MIT Technology Review Insights. Register: https://atlan.com/context-conference/ ## How do AI agents use an ontology? AI agents use an ontology as a structured model of business concepts, relationships, and rules. During a task, agents consult it to translate natural-language instructions into exact entities, definitions, constraints, and query context. They then use this context to query data, validate results, ask for missing information, or coordinate with other agents. Rather than loading the whole model at once, an agent consults it several times during a single request and retrieves only the slice it needs. At runtime, AI agents use an ontology to: - **Resolve business meaning:** Map terms to exact entities, hierarchies, metric definitions, time periods, and definition versions. - **Reason and plan:** Follow explicit relationships and rules to identify valid paths between concepts, data, and systems. - **Build grounded queries:** Use source mappings, joins, filters, and data grain to construct the appropriate SQL, API, or graph query. - **Check constraints:** Compare planned queries or actions with defined relationships, business rules, and permitted operations before execution. - **Clarify and coordinate:** Detect unresolved or ambiguous terms, ask targeted questions, and pass stable identifiers and definition versions to other agents. ## Key takeaways - Agents consult an ontology several times during a request instead of loading the full model at once. - Term, metric, and relationship lookups help stop technically valid queries from returning the wrong business answer. - MCP resources and tools, retrieval, graph traversal, and prompt context expose ontology context when agents need it. - Versioned definitions and decision traces help you find the lookup an agent skipped, which is where it started guessing. --- An AI agent does not read an ontology once like a glossary. It consults it throughout a task to resolve terms, retrieve definitions, follow relationships, select authoritative sources, check constraints, preserve meaning across handoffs, and attach provenance to the answer. Atlan, the Context Layer for AI, holds that ontology alongside the definitions, lineage, policies, ownership, and source mappings that make the context returned by each lookup consistent and usable. This gives different agents the same governed interpretation of terms such as "customer," "EMEA," or "net revenue retention." Atlan supplies the context, while the warehouse or semantic layer executes the query and an operational system executes any approved action. The term [ontology in AI](https://atlan.com/know/what-is-ontology-in-ai/) refers to a machine-readable model of business concepts, relationships, and constraints. The [parts of an ontology](https://atlan.com/know/ontology-101-explainer/) define that model, while an [ontology-first architecture](https://atlan.com/know/ontology-first-ai-architecture/) and the distinction between a [context graph and an ontology](https://atlan.com/know/context-graph-vs-ontology/) explain how it fits into the wider data and AI environment. Here, the question is narrower: what does an agent ask the ontology at runtime, what comes back, and where does the task start guessing when a lookup is missing? --- ## How does one request move through the ontology? Consider a regional finance manager asking an analytics agent: "What was net revenue retention for enterprise customers in EMEA last quarter?" The request sounds precise, but nearly every important word needs a governed interpretation before the agent can answer. The agent does not make one ontology call. It retrieves small pieces of context as the request moves from the question to the final answer. ![Sequence diagram with five lanes: finance manager, AI agent, context layer, data platform and forecasting agent. The manager asks for NRR for enterprise customers in EMEA last quarter. The agent asks the context layer to resolve the terms and gets entity IDs, region hierarchy v4 and fiscal Q2, then gets the NRR v3 definition, owner, filters, approved join path and an aggregate-only policy. It runs a governed metric query on the data platform, hands entity IDs and definition versions to the forecasting agent, and answers with NRR v3, fiscal Q2 and region hierarchy v4. A bottom band shows the path without an ontology: prompt, query, plausible guess.](/images/how-agents-use-ontology/1-diagram.webp){width=1220 height=760} ### Step 0: Orient to the right domain The agent first determines that this is a finance question involving customers, subscriptions, and revenue. It receives a small finance index rather than the entire enterprise ontology, following the approach Civili et al. (2024) describe of [progressively revealing only the ontology needed for the question](https://arxiv.org/abs/2410.09244). This helps [reduce context noise](https://atlan.com/know/ai-agent/ai-agent-context/how-to-reduce-context-noise-ai-agents/) before [agent planning](https://atlan.com/know/ai-agent/ai-agent-planning/) begins. Without this step, the agent either receives too much irrelevant context or starts with too little information. ### Step 1: Resolve the entities and time period "Enterprise customer" could refer to a finance tier or a CRM segment. "EMEA" could follow one of several regional hierarchies, and "last quarter" could be fiscal or calendar. The ontology returns stable IDs, the currently approved regional hierarchy, recorded as version 4, and fiscal Q2. In this example, "enterprise" resolves to the finance tier because Finance certified that definition, and the CRM segment is recorded as a lower-precedence synonym. If more than one interpretation remains valid, the agent can ask the manager to clarify. Without this lookup, it might choose the closest customer-type column, use an outdated regional hierarchy, or assume a calendar quarter. ### Step 2: Retrieve the certified metric definition Next, the agent asks which definition of net revenue retention applies. It receives the currently approved definition, recorded as NRR version 3, along with its owner, cohort basis, treatment of expansion, contraction, and churn, foreign-exchange rule, and the exclusion of new customers. The version tells the agent which approved revision it used, making the result easier to reproduce if the definition changes later. That lookup also establishes which system contributes what. The [ontology identifies the business concept](https://atlan.com/know/ontology-vs-semantic-layer/), while the semantic layer may provide reusable calculation logic for it within broader [systems of semantics](https://atlan.com/know/ai-agent/data-for-ai/systems-of-semantics/). Without the certified definition, the agent could calculate a reasonable version of NRR that does not match the number used by Finance, or silently choose among several competing definitions. ### Step 3: Plan the query without guessing the joins The agent then asks how the relevant business concepts connect. The ontology and its connected source mappings return an approved path from account to subscription to ARR snapshot. They also specify the level of detail in each dataset, such as one row per account or one row per monthly snapshot, the required filters, and whether a one-to-many join could multiply rows and overstate revenue. If the semantic layer already exposes a certified NRR metric, the agent should call that metric instead of planning the joins itself; the approved relationship path matters for questions the certified metric does not cover. Either way, the agent uses this context to plan the query, but the company's data warehouse or semantic layer executes it. Without an approved relationship path, the agent may produce valid SQL that duplicates revenue, drops accounts, or joins records stored at incompatible levels of detail. The ontology contributes meaning and approved relationships, not the entire [enterprise text-to-SQL](https://atlan.com/know/ai-agent/data-for-ai/text-to-sql-for-enterprise/) workflow. A [talk-to-data agent](https://atlan.com/know/ai-agent/talk-to-data-agent-blueprint/) still plans and executes through its data tools. The [Spider 2.0 paper](https://arxiv.org/abs/2411.07763) (revised March 2025) reported that an o1-preview code-agent framework solved 21.3% of enterprise tasks, compared with 91.2% on Spider 1.0. The [Spider 2.0 project site](https://spider2-sql.github.io/), checked on 27 October 2026, now puts o1-preview at 17.1%, while purpose-built agent systems on its Spider 2.0-Snow leaderboard score above 90%. A separate [2025 enterprise text-to-SQL study](https://arxiv.org/abs/2507.14372) built context from database metadata, query logs, wikis, and code; expert reviewers rated 53% of responses as correct or close to correct on its internal benchmark. ### Step 4: Select the authoritative source The same metric may appear in a certified ARR table, a semantic-layer metric, and an operational application. The agent asks which source is approved for this calculation. The ontology returns the authoritative source and its owner, while [data lineage for AI](https://atlan.com/know/ai-agent/data-for-ai/data-lineage-for-ai/) shows where the number came from and what depends on it. Without this lookup, the agent may use whichever source its tools find first, even if that source is incomplete or intended for a different purpose. ### Step 5: Check policy and access context Before requesting the data, the agent asks whether this finance manager can see account-level revenue or only regional totals, and which fields are classified. The ontology and connected context return the relevant policy information, such as "aggregates only" or "mask account names." The query itself runs under the manager's own identity, and the system serving the underlying data enforces row and column permissions. The policy context lets the agent plan an aggregate query up front instead of failing and retrying, and the context layer can also restrict which context the agent receives. [Access control for AI agents](https://atlan.com/know/ai-agent-access-control/), [role-based access in the context layer](https://atlan.com/know/ai-agent/context-layer/context-layer-role-based-access-control/), and [agent identity](https://atlan.com/know/ai-agent/ai-agent-identity/) keep these decisions tied to the actual caller. Without these checks, the agent could request restricted details or refuse information the manager is permitted to access. ### Step 6: Constrain a follow-up action Suppose the manager follows up with: "Flag the at-risk accounts and open renewal tasks." The agent now needs more than analytical context. The ontology identifies the permitted operations, required inputs, preconditions, and approval path. The operational system still authorizes and commits the change through its own API, as the guide to [an operational ontology's actions](https://atlan.com/know/ai-agent/ontology/what-is-an-operational-ontology/) explains. Without those constraints, the agent could select an overly broad tool or take an action with a broader scope than the manager intended. OWASP's 2026 Top 10 for LLM Applications lists [Excessive Agency as LLM03:2026](https://genai.owasp.org/resource/owasp-genai-llm-top-10-2026/) and identifies excessive functionality, permissions, and autonomy as its root causes. [How agents choose tools](https://atlan.com/know/ai-agent/ai-agent-tool-use/) and broader [agent risks and guardrails](https://atlan.com/know/ai-agent-risks-guardrails/) help teams keep that action surface bounded. ### Step 7: Preserve meaning during a handoff The analytics agent may pass the result to a forecasting agent. Instead of sending only the words "enterprise," "EMEA," and "last quarter," it sends the entity IDs, NRR version, current region hierarchy version, and the fiscal period used in the analysis. That only works if the forecasting agent resolves those IDs against the same context service, and it still needs its own permission to read the underlying data. The [A2A specification](https://a2a-protocol.org/latest/specification/) describes Agent Cards for discovering agent identities and capabilities. The ontology carries the business meaning exchanged between those agents. Without stable references, the forecasting agent may reinterpret the same words and produce a forecast based on different definitions. That distinction keeps [context for multi-agent systems](https://atlan.com/know/context-engineering/context-engineering-for-multi-agents/) consistent. It also separates [context management across agents](https://atlan.com/know/ai-agent/ai-agent-context/context-management-multi-agent-systems/) from protocol discovery and clarifies the roles of [MCP versus A2A](https://atlan.com/know/mcp/mcp-vs-a2a-protocol/). ### Step 8: Return the answer with provenance The final answer includes the number and the context used to produce it: NRR definition version 3, fiscal Q2, the currently approved regional hierarchy (version 4), and the authoritative source. The agent also logs the definitions, relationships, source, and query path it used. [Decision traces](https://atlan.com/know/what-are-decision-traces-for-ai-agents/) make the answer inspectable, while [versioned context](https://atlan.com/know/ai-agent/context-versioning-for-ai-agents/) enables reproducing or rolling back a faulty definition. Recomputing the number itself also needs the exact query and an as-of time or snapshot for the source data. Without these records, the team may receive a number but have no reliable way to explain why it changed. --- ## How is the ontology exposed to the agent? The previous walkthrough showed what the agent asks at each step. Those requests can reach the ontology through several access patterns. For example, the host might attach a small finance index, while the agent invokes tools to resolve terms and traverses connected relationships to plan the query. MCP resources give the host context it can place in front of the model. MCP tools give the model callable operations it can invoke when it needs a specific result. Orientation, discovery, exact lookup, and relationship traversal need different kinds of context, so one request can use several access patterns. Each access pattern supports a different part of the request: | Access pattern | How it works | Where does it fit in the request | | :---- | :---- | :---- | | MCP resources | The server exposes addressable context, while the host application decides what to read and include for the model | Can supply the finance index or core glossary used for orientation in Step 0 without loading the complete ontology; the [MCP resources specification](https://modelcontextprotocol.io/specification/2026-07-28/server/resources) leaves that choice to the host application | | MCP tools | The server exposes callable operations with defined inputs and outputs, which the model can invoke when needed | Resolves terms, retrieves definitions, traverses relationships, or checks policy context in Steps 1 to 5, consistent with the [MCP tools specification](https://modelcontextprotocol.io/specification/2026-07-28/server/tools) | | Retrieval | Semantic search finds possible matches among certified terms and definitions | Helps the agent discover candidates when it does not yet know the exact entity; an exact lookup then confirms the identifier and version | | Graph traversal | The agent follows connected entities and relationships across the relevant part of the graph | Finds join paths, lineage, and multi-step relationships in Step 3, or checks the downstream impact of an action in Step 6 | | Prompt context | A small amount of stable context is placed directly in the model's input | Supplies core instructions or definitions needed for most requests; changing or domain-specific context stays behind runtime calls | These patterns are not always separate technical systems. A graph traversal might be exposed through an MCP tool or API. Retrieval might find several possible definitions, after which a tool confirms the certified entity and version. Retrieval finds candidates; a resolver applies the ontology's precedence rules, such as certified definitions over synonyms, and returns an ambiguity when no single meaning wins. The important design choice is to expose only the context required for the current request. Civili et al. (2024) describe [progressively revealing just enough of an ontology](https://arxiv.org/abs/2410.09244) to answer a question. This keeps the model from filling its context window with unrelated domains and relationships. For tasks that must follow formal constraints, another approach is to turn parts of the ontology into executable tools. Zhou et al. (2026) demonstrate a proof-of-principle method for [compiling ontological constraints into tool interfaces](https://arxiv.org/abs/2602.03439). The agent must then operate through calls that reflect those constraints, rather than relying solely on validation after generation. This is an evaluated mechanism, not evidence that every ontology should be converted into tools. With Atlan, teams can combine [the Atlan MCP server](https://atlan.com/know/what-is-atlan-mcp/) with [business context delivered through MCP](https://atlan.com/know/mcp-delivers-business-context/), [semantic definitions served to agents](https://atlan.com/know/ai-agent/semantic-layer/mcp-semantic-layer-for-ai-agents/), and [context-graph queries](https://atlan.com/know/ai-agent/how-to-query-context-graph-with-ai-agent/). What these interfaces expose depends on how teams [design the ontology for AI](https://atlan.com/know/ai-agent/ontology/ontology-design-for-ai/), [extend it across the data estate](https://atlan.com/know/ai-agent/ontology/extending-ontology-beyond-snowflake/), and distinguish the [ontology from the knowledge graph](https://atlan.com/know/ai-agent/knowledge-graph/ontology-vs-knowledge-graph/) that stores connected instances. Even with the right interface, the request can still fail if the agent receives the wrong entity, an outdated definition, or context from a different version. Those failures tend to appear at a few predictable points. --- ## Where does ontology use break first? Entity and metric resolution come first, so a mistake there costs the most. If "enterprise customer" maps to the wrong segment or NRR maps to the wrong formula, every later source, join, and calculation can be technically valid while still answering the wrong business question. Context can also change while a request is in progress. An agent might resolve NRR version 3 at the start, then pick up a source mapping written for a later revision. [Keeping the ontology current](https://atlan.com/know/what-is-active-ontology/), detecting [context drift](https://atlan.com/know/context-drift-ai-agents/), and pinning the request's definitions, hierarchies, and source mappings to one context version prevent a single answer from mixing revisions. Access policy is the exception. Never pin it: the enforcing system evaluates permissions live on every read and write, so a revocation issued mid-request still applies. Handoffs create the third fault line. If the analytics agent sends only "EMEA" and "last quarter," the forecasting agent may interpret those terms using its own vocabulary. Passing stable entity IDs and definition versions preserves the original meaning. Measuring [agent accuracy](https://atlan.com/know/ai-agent/ai-agent-accuracy/) should therefore examine the context selected at each step and identify the first lookup at which the request diverged from the certified meaning. --- ## How does Atlan serve ontology context to AI agents at runtime? Atlan creates a shared path from scattered enterprise knowledge to the governed context an AI agent needs at runtime. This context includes more than metric definitions. As Cui and Li (2026) explain, it must also cover [canonical entities and identity resolution](https://a16z.com/your-data-agents-need-context/). [Context Agents](https://atlan.com/context-agents/) help bootstrap and maintain that context. Orion maps business concepts and relationships into an ontology, Sage surfaces conflicting metric definitions, and Nexus links business terms to the relevant data assets. Once owners review them, these suggestions become part of the [Enterprise Data Graph](https://atlan.com/know/enterprise-data-graph/), which connects definitions with columns, lineage, owners, classifications, and policy context. Teams can then use [Context Engineering Studio](https://atlan.com/context-engineering-studio/) to assemble, test, review, approve, version, and deploy this context for a particular domain or use case. Instead of resolving "NRR" differently in every workflow, agents can retrieve an approved definition and its version from a shared context repository. The [Context Lakehouse](https://atlan.com/context-lakehouse/) stores and serves this context across runtimes. The [Atlan MCP server](https://atlan.com/mcp/) gives AI agents callable access to definitions, lineage, and access context during a task. The Context Lakehouse also supports A2A, SQL, and APIs, so different agents and applications can work from the same source of context. In this episode, Jessica Talisman discusses what actually changed when ontology work moved from standalone models into the context layer for AI. Atlan's research report, [Metadata: The Critical Foundation for AI Agents & Natural Language to SQL Use Cases](https://atlan.com/resources/metadata-research-report/), ran the same 174 queries three times each, 522 evaluations in all, and found that rich semantic metadata improved the accuracy of AI-generated SQL by 38%. It is Atlan's own benchmark on [one 13-table dataset](https://atlan.com/know/enhanced-metadata-improves-query-accuracy/), so treat it as a direction to test on your own estate. Atlan supplies the resolution, definitions, relationships, policy context, lineage, and provenance behind the request. The data warehouse or semantic layer still executes the query, while operational systems execute approved actions through their own APIs. --- ## Real stories from real customers: Shared context for AI agents "Atlan captures Workday's shared language to be leveraged by AI via its MCP server. As part of Atlan's AI labs, we're co-building the semantic layer that AI needs." - Joe DosSantos, VP, Enterprise Data and Analytics, Workday "Atlan is our context operating system to cover every type of context in every system including our operational systems." - Sridher Arumugham, Chief Data Analytics Officer, DigiKey --- ## FAQs about how AI agents use an ontology ### 1. How does an AI agent use an ontology, step by step? The agent may start with a small domain index before resolving entities and time periods, retrieving metric definitions, planning relationships, selecting an authoritative source, and checking policy context. It then queries or acts through the appropriate external system while preserving identifiers and versions during handoffs. The final answer carries the definition versions, sources, and provenance used. ### 2. Does the agent load the whole ontology into its prompt? Usually, no. Large enterprise ontologies waste context space and add irrelevant concepts, making selection harder. A better design attaches a small stable index, then retrieves or calls the exact ontology slice needed for the current request. ### 3. How does an ontology improve text-to-SQL accuracy? It tells the agent what the requested business terms mean, which sources are authoritative, and how the relevant tables relate. This context can reduce wrong-column, wrong-metric, and duplicate-row errors before SQL generation. The data platform still checks permissions and executes the query. ### 4. How does an agent resolve ambiguous terms such as "customer" or "EMEA"? It sends the phrase, user context, and task context to a resolution interface. The resolver checks the ontology and returns a stable entity ID, an approved definition, a hierarchy, an owner, and a version. If several meanings remain valid, the agent should ask for clarification instead of choosing silently. ### 5. How do agents access an ontology through MCP, APIs, graph queries, or retrieval? Agents can combine MCP resources, MCP tools, retrieval, graph queries, APIs, and a small amount of prompt context. The host can attach stable reference material, while the model invokes exact resolution or traversal operations when needed. The right method depends on whether the agent needs initial orientation, possible matches, an exact identity, connected relationships, or policy context. ### 6. How does an ontology limit what an agent can see or do? The ontology gives the agent classifications, policy context, allowed-action definitions, and required preconditions. It can tell the agent that account-level revenue is restricted or that an action requires approval, but it does not enforce those controls by itself. The downstream systems remain the final enforcement points: the data platform controls access to the underlying data, while the operational system authorizes and executes approved actions. ### 7. How do multiple agents share one vocabulary during a handoff? The sending agent passes stable entity IDs, metric versions, hierarchy versions, and relevant policy context with the task. The receiving agent uses those references rather than reinterpreting the original strings. Shared identifiers maintain semantic consistency during handoffs, even when agents use different models or tools, as long as both agents resolve them against the same context service. ### 8. How do you debug which definition an agent used? Record the entity IDs, definition versions, source, join path, policy result, and tool calls selected for the answer. Compare that trace with the certified versions that were valid when the request ran. Then check the generated query against those lookups: a term with no resolution call, or a column outside the approved mappings, marks where the agent stopped asking and started guessing. --- ## Sources 1. [Using off-the-shelf LLMs to query enterprise data by progressively revealing ontologies](https://arxiv.org/abs/2410.09244) 2. [Spider 2.0: Evaluating Language Models on Real-World Enterprise Text-to-SQL Workflows](https://arxiv.org/abs/2411.07763) 3. [Spider 2.0 project site and leaderboard](https://spider2-sql.github.io/) 4. [Text-to-SQL for Enterprise Data Analytics](https://arxiv.org/abs/2507.14372) 5. [Ontology-to-tools compilation for executable semantic constraint enforcement in LLM agents](https://arxiv.org/abs/2602.03439) 6. [Model Context Protocol: Resources (2026-07-28)](https://modelcontextprotocol.io/specification/2026-07-28/server/resources) 7. [Model Context Protocol: Tools (2026-07-28)](https://modelcontextprotocol.io/specification/2026-07-28/server/tools) 8. [OWASP GenAI LLM Top 10 2026 (LLM03:2026 Excessive Agency)](https://genai.owasp.org/resource/owasp-genai-llm-top-10-2026/) 9. [A2A Protocol specification](https://a2a-protocol.org/latest/specification/) 10. [Your Data Agents Need Context](https://a16z.com/your-data-agents-need-context/)