Beyond RAG, MCP, and Skills: Why Enterprise Agents Need an Ontology-First Approach

TL;DR

A process can run but the business definitions may still be wrong. Customer mapping, revenue definition, comparison period, and ownership must trace to explicit sources. SQL executing without error and a well-written report do not replace reconciliation.

Keep each definition in one place. Reuse existing metrics, domain models, and business APIs. RAG, MCP, and Skills continue their roles; repeatedly used definitions are gradually promoted to shared capabilities.

Finding a record does not equal a conclusion. A complaint may be a clue for revenue decline; not finding one may stem from permission or sync gaps. Causes need evidence; gaps must remain in the result.

Re-verify before write, reconcile after write. The owner at analysis time may have changed; a timeout does not mean creation failed. Execution depends on current conditions, idempotency, and business receipts; formal definition changes require owner confirmation.

Shared Definitions

First, look at what Zhang's system already has. A revenue-analysis Skill with a clear definition and reliable query tools could handle this task. Earlier discussions separated "how work is done" (Skills) from "how external capabilities are connected" (MCP). Here it's the same: RAG retrieves policies, contracts, and communication records; MCP connects tools and resources from finance, CRM, etc.; Skills organize the steps and materials for analysis and follow-up.

When reused in other processes, where the definition lives becomes critical. If tomorrow Finance builds an agent, and the day after Customer Service builds another, everyone needs "customer". Sales Skill writes customer mapping once, Finance's prompt writes it again, Service's tool description keeps another copy. When the customer relationship changes, all copies must be updated; missing one means the same company could be counted in different scopes.

Organizing follow-up methods and report styles can differ per Skill; but customer identifiers, revenue definitions, and where to look up owners deserve a common source . If there's only a small, stable task with few objects, a clear interface plus documentation can suffice for now.

Ontology (often translated as "ontology") describes concepts, attributes, relationships, and constraints in a domain. What Zhang needs is to clarify the meaning of customer, revenue, owner, and their relationships, and connect them to real data. Whether it can further link to business actions varies by product.

RAG : Find policies, contracts, customer records to supplement analysis evidence

MCP : Connect query-revenue, query-owner, create-task capabilities

Skills : Organize analysis and follow-up work methods

Ontology : Specify which customer, which revenue, what relationships and rules

RAG can retrieve ontology definitions, MCP can provide tools to query the ontology, and Skills can reference these definitions. When different agents reference the same customer definition, which customers they can view or modify is still determined by their respective identities and permissions.

Get the Numbers Right

Zhang gets a decline list; the first step is to ask Finance: are these numbers correct? Reconciling often requires re-confirming "the same customer". A CRM customer may map to multiple finance payers, or be just a subsidiary under a group. Viewing revenue by group vs. by signing entity can produce different decline lists . Tweaking the report prompt won't fix the list.

Therefore, step one needs stable customer identifiers and their mapping to each source system. Similar names can be matching clues, not direct merges. In a previous article we discussed signing entity vs. receiving entity: even if both ends are companies, you cannot mix the two relationships. Mapping payer to sales account also requires business evidence.

Revenue must be pinned down. Suppose a quarter has 1.2M signed, 1M invoiced, 800K recognized — all three numbers can be correct. Which one Zhang wants, which date defines the quarter, how returns are deducted, whether decline is vs. last quarter or same quarter last year — all affect the result.

Today is Nov 8; the quarter isn't over. Comparing a partial month to a full previous quarter shows decline naturally. Whether to compare same-progress periods must be agreed upfront. In the query, data granularity matters: one order linking to multiple invoices, then summed, can double-count the same amount. SQL runs fine, but the accounting is wrong.

Ownership must carry time. Explaining last quarter's performance may need the owner at that time; creating a follow-up task today needs the current owner. If a handover took effect in October but was recorded in November, "who owned it in October as seen now" vs. "who the system thought owned it then" can differ. The gap between business effective time and system record time is what bitemporal modeling handles. Do it when traceability is needed, not all at once.

This aligns with the earlier discussion in "How Agents Understand Business": after identifying user intent, you must operate on concrete objects using current state, identity, and applicable rules. Here "current" sometimes requires clarifying which time point.

Another extreme: since customer definitions differ, unify them company-wide. Sales accounts, finance payers, service objects may serve different jobs. Keep them separate, then explain how they relate and when they can be merged — often more appropriate. This is the use of "bounded contexts" in domain modeling. Both recognized revenue and signed amount have uses; dropping one for a unified name loses business meaning.

Some conventions aren't in tables at all. Laurens Nys on X noted contract priority, subsidiary-brand relationships, who decides when an account stalls — often only in employees' heads. Databases can't reveal them; you must confirm with business people. A sales manager saying "already handed over" is just a note; formal ownership still needs CRM rules and records.

If a knowledge graph exists, keep using it. Graphs usually hold concrete entities and relationships; ontology defines their meaning; GraphRAG uses graph structure to aid retrieval and answer organization. Documents extract "Customer A" and "Payer B"; you still must confirm their relationship — co-occurrence in a graph doesn't justify merging statistics.

Reuse First

If you now create an "Agent-specific revenue definition", the maintenance problem returns. Veterans of business systems will recognize: domain models, metric platforms, CRM — aren't they already managing these?

When building an agent, I first look for Finance's approved revenue definitions, the metric platform's calculation logic, and CRM's handover records. What already has clear owners and revision history gets reused. Writing another Agent-specific interpretation just adds another sync point.

Microsoft Fabric IQ's Ontology preview generates ontology from Power BI semantic models, reusing existing tables, columns, relationships, and metrics. DAX measure expressions stay in the source model; ontology retains provenance and business context. Company-approved calculation logic doesn't need re-explanation at the Agent layer.

Missing parts can be drafted with model help. NVIDIA Auto Ontology generates terms, SQL expressions, and table relationships from DB schema, samples, and query history; humans then revise, certify, and use for QA. Definitions and embeddings live in Postgres/pgvector; vector retrieval still works. Its MCP currently targets read-only QA and semantic-layer checks; creating follow-up tasks still needs a separate write interface. (GitHub repository:

https://github.com/NVIDIA/auto-ontology/tree/c447003f72a822301e927196a4ecb5b597c308d5

)

Generating a full definition set can feel like "done". But whether two customers should merge, what business scope a revenue formula applies to — often can't be guessed from schema alone. The 2026-02 OntoEKG study reported class/instance confusion, reversed hierarchies, and scope ambiguity in its specific method.

So NVIDIA's "generate then confirm" sequence is worth keeping. The model saves some organizing work; customer mapping and business definitions still need human sign-off.

Query and Attribution

Definitions confirmed, there's a subtle issue: docs may be right, but the actual query might not use them.

Which customer scope, which revenue, which comparison period Zhang uses — if the company has explicit defaults, reference them; if not, and they affect results, ask. Once confirmed, pass these choices to the actual calculation service.

Assume business confirms the following query convention (metric names and versions illustrative):

Customer scope: Group customer, using confirmed payer mapping
Revenue metric: Finance recognized revenue, recognized_revenue@v3
Comparison period: Current quarter to yesterday, vs. same progress last quarter
Result granularity: One row per group customer
Return evidence: Customer ID, two-period amounts, mapping version, data-as-of time

The Agent selects this convention; the query service calls existing metrics and mappings to aggregate. MCP can plug the service in; existing reliable APIs work too. Amount calculation, object mapping, and data permissions are enforced by the service.

If only the document writes recognized_revenue@v3 but the model still assembles the formula at calculation time, that version number does not constrain the query. Missing metrics, mapping conflicts, or source data gaps must be returned by the service so the workflow can decide to re-query, ask, or pause.

After finding "Customer A revenue down 20%", I keep both period amounts, metric version, mapping version, comparison period, and data-as-of time in the result. Otherwise when Finance asks tomorrow, you'd have to re-trace which mapping and data slice produced that 20%. The next step retrieving customer records also needs to know exactly who the analysis subject is.

You don't necessarily need to move raw data into a graph database. AWS's reference architecture uses Ontop to rewrite SPARQL over the ontology into SQL via mappings, executing on the relational DB. This virtual knowledge graph lets data stay in source systems, but mappings must be maintained, query performance depends on sources, and cross-source consistency issues remain. For a few stable metrics, existing semantic layer plus tool interfaces may suffice; add graph capabilities only when complex relationship queries or formal reasoning are truly needed.

Numbers reconciled, Zhang still wants causes. Skills can continue: retrieve contracts, tickets, communication records; verify gaps; organize possible causes; produce a follow-up list.

Here we can separate three things. "Customer can be owned by a sales manager" is a definition; "Customer A currently belongs to Manager Li" is a fact; which customers Zhang can see, which period is analyzed, which records were retrieved — these form the task context. Definitions are relatively stable; facts update with business; context is selected per task — no need to stuff everything into one static description.

In "Context System Architecture" we distinguished factual evidence from task working set. Analyzing Customer A means pulling metrics, mappings, owners, and evidence related to A by permission — not loading the whole company corpus into the window. EvoOntology research offers an implementation: start session with brief description; when details needed, use MCP's browse and resolve tools to look up and read.

Suppose a complaint for Customer A is found; the report easily becomes "service issue caused revenue decline". But that complaint may have occurred after the decline, or involve only a small order. Finding a related record is one step away from explaining the cause.

Conversely, no complaint found could mean none exists, or the ticket system isn't connected, or the current user lacks permission, or data hasn't synced. The result must state which sources were checked and where gaps remain. A complaint can be a clue; co-occurrence with revenue decline doesn't establish causality.

Shared definitions help us clarify "whose which revenue dropped"; "why" must be backed by subsequent evidence. When unclear, keeping unverified items in the report is more useful than fabricating a complete story.

This query-and-analysis run state, model and tool calls, budget and timeouts can be managed by Harness — the Agent's runtime management framework. Cross-run task progress and human takeover connect to a task system. "Agent, Harness, Loop" distinguished these layers: one run may stop while the overall job continues.

Troubleshooting needs more than the final report. Actual tool inputs/outputs, definition versions, data sources, and available snapshot IDs must be retained. Just logging query time may not reconstruct the data; re-running the model may not yield the same answer.

Controlled Execution

Zhang's request has a second half. A clean analysis list doesn't mean you can directly create tasks from it: between query and write, business state may have changed.

Palantir's Action Types organize parameters, object changes, and validation logic into reusable actions, exposed via Ontology MCP for Agents. Our systems can reuse existing business APIs.

Back to Zhang's task, define an action convention like the query convention. Below is a design sketch, not a product's ready-made interface:

Action: Create follow-up task for specified customer
Input: Customer ID, Owner ID, Analysis Record ID, Idempotency Key
Preconditions: Customer valid, Owner matches, Permissions and approvals passed
Return: Operation ID, Execution Status; on success return Task ID
Completion Check: Read back Customer, Owner, and Task Status by Task ID

Regardless of entry point, the service must check permissions based on current user, customer, owner, and state; if approval needed, wait for it.

Skill writing "check permissions first" cannot replace the service doing that check this time.

Example: Morning list generation had Customer owned by Manager Wang; by afternoon approval, it's moved to Manager Li. Copying morning's owner creates the task for the wrong person; just swapping to Li may not suffice. If the original approval explicitly targeted a task for Wang, re-assigning after handover must follow approval rules.

Checking once at analysis time does not substitute re-confirmation at execution time. Actions can carry analysis, approval, and object versions; execution verifies them. Related states in the same transaction scope can use conditional writes to reject stale requests; cross-system gaps may appear right after checking the owner. Which conditions can be guaranteed together, and whether the remaining time window is acceptable, must be arranged per system. Sergey Vasiliev's article on fact correction discusses this in more detail.

Ontology constraints and service validation have distinct roles. OWL declaring Customer-Owner relationship supports knowledge representation and reasoning; it uses open-world assumption — absence of record doesn't mean non-existence — and cannot directly replace a database "owner field required" check. RDF stacks can use SHACL to validate data graphs; ordinary services use type checks, DB constraints, and business validation. After data passes, whether the current user can execute the action is still decided by the execution service.

Another premature-finish trap: interface returns "accepted", Agent tells Zhang "done".

"Output Result ≠ Task Complete" covered this difference. CRM receiving a request only means the request arrived. Getting a task ID, then reading back Customer, Owner, and Status per the interface contract confirms the task was created correctly. If the interface only returns "accepted", wait for the actual creation result.

Task created completes Zhang's "create task". Whether the sales manager actually follows up depends on subsequent business records — don't reuse a vague "done".

Worse than "accepted" is timeout: request sent, no response. Treating as failure and retrying may duplicate the task. Need idempotency key and ability to query result by operation record.

Explicit failure and unknown result must be handled separately.

If multiple steps across Finance, CRM, Ticket systems are involved, arrange retries or compensations per system capability. A single platform's transaction doesn't cover all external systems. The permissions, approvals, and execution mechanisms already built in business systems remain useful here.

Definition Evolution

After the task runs, maintenance issues surface. Customers transfer, metrics adjust, new questions reveal gaps. If all changes are left to the model to "learn", different types of modifications get mixed.

Example: Agent can't find a revenue metric — maybe the tool description is hard to find, or the definition is truly missing. Fixing the description may solve it; misclassifying as a metric problem and changing a correct business definition causes wider impact.

Rakesh Gohel on X introducing EvoOntology focused on the semantic layer evolving with work. The paper analyzes run traces, attributes issues to content, object model, or tool interface, then proposes localized changes. This locate-then-adjust approach is more valuable than regenerating the whole definition set each time.

Candidate changes must be compared against the original: freeze model, validation tasks, and interaction budget; keep only if improvement threshold met. Paper v2 treats construction and evolution as an adaptation process, freezing the ontology before final test . This gives a reference for maintenance methods, but doesn't mean production Agents can freely change company official definitions anytime.

In Zhang's company I'd handle different changes separately. Follow-up completed, owner formally changed — update facts per source system confirmation. Agent's hypothesized causes for revenue decline — keep as evidence-backed pending judgments. Finance adjusts revenue definition — responsible owner confirms new definition and effective scope , then assess impact.

Improving tool discoverability and changing the meaning of recognized revenue have different impact radii. A phrasing that makes the model answer easier doesn't prove it matches business reality.

Following the Loop distinction: within one task, missing material can be fetched; across tasks, a definition gap triggers a candidate change, validation, and release. The latter affects future users, so who can change and how to accept must be defined separately.

If CRM corrects customer mapping, yesterday's report and today's pending follow-up tasks may be affected. The versions, evidence, and task links retained earlier become useful: identify which results need re-check. Old reports explain the judgment at that time; whether they can still drive execution today must be re-confirmed.

Incremental Rollout

For Zhang's first round, I'd gather Finance, Sales, and CRM colleagues to confirm customer mapping, revenue entry, comparison period, owner, and creation conditions. This one task gets a reconciliation baseline.

Acceptance testing should target error-prone cases: one customer mapping to multiple payers, last quarter revenue zero, owner just changed, data segment missing. When last quarter is zero, QoQ decline formula can't apply directly; when owner just changed, old list can't be used directly for task creation. Where expected results are unclear, agree upfront what to ask and at which step to pause.

Then run read-only analysis, verify customer scope, amounts, and cause evidence. After verification passes, add create-follow-up-task, reusing existing permissions, approvals, idempotency, and result queries.

AWS guidance suggests starting with one domain and representative questions; Harsh Dalal's Agent-First Ontology Design advocates finding model gaps from actual Agent failures. Both can work together: first confirm definitions the current work can't do without; after running, supplement only what truly affects results.

Ontology First here is a design sequence , not a prerequisite to finish the whole company model before starting.

Comparing before/after: fix model, data, tasks, and tool budget; check if customer list and amounts are correct, causes have evidence, tasks go to the right person; then look at call counts, latency, and manual corrections. If you only score the final report, you'll miss the earlier accounting and state issues.

Shared models have query and maintenance costs. With only one stable flow, business API plus Skill may be simpler; when the second and third flows start re-explaining customer relationships and revenue definitions, shared maintenance benefits become visible. Zach Wilson proposed letting analytics engineers who maintain dbt models continue maintaining the Agent context generated from them — this reuse of existing roles is worth referencing. Here: Finance owns metrics, Data team owns mappings and quality, CRM team owns handovers and task actions.

This connects the year's discussions: Skills keep reusable work methods, Context System provides facts per task, Harness manages one run and tool calls; cross-run tasks go to the task system. Shared business model lets these capabilities reference the same business meanings, each with a clear modification point.

When issues arise, you can trace to the source: relationship undefined — add definition; data not synced — fix pipeline; insufficient permission — handle permission. Stuffing everything back into the prompt only leaves an ever-harder-to-change description.

Next time Zhang asks after dinner, a different Agent can still reuse the same customer mapping and revenue definition; when creating the task, it still executes per the current owner and permissions. That, to me, is what Ontology First is worth doing.

References

AWS Prescriptive Guidance: Semantic Layer for Agentic AI using Ontology, Symbolic Reasoning, and Virtual Knowledge Graph; Architecture, Best practices, Prerequisites and limitations. Public architecture and implementation guidance used, not deployed or tested (https://docs.aws.amazon.com/prescriptive-guidance/latest/semantic-layer-agentic-ai-ontology-reasoning-virtual-knowledge-graph/semantic-layer-agentic-ai-ontology-reasoning-virtual-knowledge-graph.html)

Abdulsobur Oyewale, Tommaso Soru: LLM-Driven Ontology Construction for Enterprise Knowledge Graphs, 2026-02-01, arXiv:2602.01276v1. Conclusions limited to paper's method and data (https://arxiv.org/abs/2602.01276)

Meiduo Chong, Shaolei Zhang, Ju Fan, Xiaoyong Du: EvoOntology: A Self-Evolving Ontology Layer for Data Agents, 2026-09-14 first release, 2026-11-02 v2 update. Uses on-demand access, local evolution, and paired validation; not extrapolated to production business definitions changing autonomously (https://arxiv.org/html/2609.15779v2)

Microsoft Fabric IQ: Ontology overview, preview feature, referenced page updated 2026-10-16 (https://learn.microsoft.com/en-us/fabric/iq/ontology/overview)

NVIDIA Auto Ontology: README, MCP docs, based on 2026-11-06 commit c447003f72a822301e927196a4ecb5b597c308d5. Its MCP targets read-only QA and semantic-layer checks (https://github.com/NVIDIA/auto-ontology/tree/c447003f72a822301e927196a4ecb5b597c308d5)

Palantir: Ontology overview, Action types, Developer toolchain (https://www.palantir.com/docs/foundry/ontology/overview; https://www.palantir.com/docs/foundry/action-types/overview; https://www.palantir.com/docs/foundry/dev-toolchain/overview)

W3C: OWL 2 Web Ontology Language Primer, 2012-12-11; Shapes Constraint Language (SHACL), 2017-07-20 (https://www.w3.org/TR/owl2-primer/; https://www.w3.org/TR/shacl/)

Ananth Packkildurai: An ontology for AI agents is a system, 2026-08-14; Harsh Dalal: Agent-First Ontology Design: Build the Ontology After the Agent, 2026-10-01. Referenced as modeling method discussions (https://www.dataengineeringweekly.com/p/an-ontology-for-ai-agents-is-a-system; https://www.bluedataconsulting.co/blog/agent-first-ontology-design-build-the-ontology-after-the-agent/)

Sergey Vasiliev: Knowledge graph, memory graph and context graph — Part II: Designing the boundaries between the three roles, 2026-10-28. Borrowed discussion on fact correction, re-verification dependency, and pre-execution checks; revenue analysis example designed by this article (https://sergeyvasiliev.substack.com/p/knowledge-graph-memory-graph-and-b78)

X discussions: Laurens Nys, 2026-11-05, tacit business knowledge (https://x.com/laurensnys/status/2118296300055589226); Rakesh Gohel, 2026-11-03, EvoOntology continuous maintenance (https://x.com/rakeshgohel01/status/2117633068949283180); Zach Wilson, 2026-11-02, semantic model and Agent context maintainers (https://x.com/Zachly/status/2117353457472373137)