Two Types of Ontologies Your AI Agents Need to Be Trustworthy

Key Takeaways

• AI agents need both reliable facts and reliable context to be trustworthy; simply having data isn’t enough for understanding.
• Descriptive ontologies define business meaning and rules, acting as a “business dictionary” for AI agents to understand user intent.
• Structural ontologies map business concepts to actual data locations, serving as a “data atlas” that helps AI agents find the relevant information.

Your AI agent has access to every database, data lake, and semantic layer in your enterprise. It should be unstoppable. Yet when a customer asks, “Am I entitled to premium support?” the agent hesitates, hallucinates, or worse, confidently delivers the wrong answer.

The problem isn’t lack of data. It’s lack of understanding. Your agent knows there’s an “Amount” field in the opportunity table, but does it understand what constitutes a qualified opportunity according to your sales methodology? It can retrieve a support case severity level, but does it know the business rules that govern response time commitments?

This is the gap between having information and understanding what it means. And it’s exactly why enterprises building reliable AI agents need two distinct but interconnected types of ontologies. That’s where descriptive and structural ontologies come in.

Here’s what we’ll cover:

Why throwing data at AI doesn’t work
Descriptive ontologies teach machines what things mean
Structural ontologies teach machines where things live
How descriptive and structural ontologies work together
Real-world examples from Salesforce
Trust, governance, and explainability: making answers auditable

Why throwing data at AI doesn’t work

AI agents need both reliable facts and reliable context. But most enterprises face a fundamental problem: The way systems store data has diverged from how the business thinks about it.

Consider a simple question: “What’s our qualified pipeline for Q4?” Your data warehouse has opportunity records with stages, amounts, and close dates. But “qualified” means something specific to your sales methodology. The criteria might involve deal size, decision-maker engagement, budget confirmation, and competitive positioning. These business concepts don’t map neatly to database columns.

This gap creates three major challenges for AI agents:

1. Ambiguous intent. When users ask questions, they’re thinking in business terms. Agents need to translate that intent into concrete data queries. But, without understanding business meaning, they’re just guessing.
2. Inconsistent interpretation. Different teams might define the same concept differently. “Active customer” could mean someone who purchased in the last 90 days, or someone with an active contract, or someone who logged in recently. Without shared definitions, agents give inconsistent answers.
3. Brittle integrations. When data models inevitably change, agents can break. Unless there’s an explicit layer mapping business concepts to data structures, every schema change requires updating dozens of prompts and workflows.

The solution isn’t more data or better prompts. It’s creating two complementary translation layers that help machines understand both business meaning and data reality. This leads us to descriptive and structural ontologies.

Descriptive ontologies teach machines what things mean

Descriptive ontologies capture business meaning and intent. They define the concepts, policies, relationships, and causal logic that drive how your organization actually works, not how your database schemas happen to be structured.

What they contain:

• Business concepts and their definitions (e.g., customer entitlement, service level agreement, qualified opportunity)
• Roles and responsibilities (who can do what)
• Policies and business rules (when, why, and how things should happen)
• Events and causal relationships (what triggers what)
• Outcomes and success criteria

Who owns them: ontologists, domain experts, compliance partners, and product owners, or the people close to the business who understand why things work the way they do.

When they change: when business meaning shifts, policies evolve, or new strategic priorities emerge.

Example use cases:

• Agent grounding and guardrails (ensuring agents respect business rules)
• Policy reasoning and compliance checks
• Customer journey modeling and next-best-action recommendations
• Enterprise search that understands user intent, not just keywords

Think of descriptive ontologies as the “business dictionary” your agents consult to understand what questions really mean and what rules govern possible answers.

Back to top

Structural ontologies teach machines where things live

Structural ontologies map to actual data: entities, attributes, relationships, constraints, and the physical or virtual locations where information lives.

What they contain:

• Data entities and their schemas (tables, objects, fields)
• Attributes and data types
• Relationships and foreign keys
• Constraints and validation rules
• Mappings to data warehouses, lakes, and semantic layers

Who owns them: Data architects, analytics engineers, knowledge engineers, and platform engineers, or the people close to systems who understand how data flows and where it’s stored.

When they change: When platforms evolve, data models are refactored, or new data products are introduced.

Example use cases:

• Semantic layer alignment across disparate data sources
• Metric definitions and consistent KPIs
• Query translation (from natural language to SQL/SOQL)
• Entity resolution and data lineage tracking

Think of structural ontologies as the “data atlas” your agents use to navigate from business concepts to actual database locations.

Back to top

How descriptive and structural ontologies work together

Here’s the critical insight: Descriptive defines meaning. Structural binds meaning to data. When an AI agent needs to answer a customer question, it follows this pattern:

1. Understand intent (descriptive layer). The agent consults the descriptive ontology to understand what the question means in business terms. For example, “premium support entitlement” translates to: specific contract type + active status + tier level + valid date range.
2. Locate data (structural layer). The agent uses the structural ontology to find where that data actually lives. Which Data Cloud objects, Salesforce tables, or external APIs contain contract type, status, tier, and dates? How are they related?
3. Retrieve facts (data layer). The agent executes queries through mapped data pathways to get concrete values.
4. Apply business rules (descriptive layer). The agent applies policies and rules from the descriptive layer to formulate a trustworthy answer. Does this customer meet all criteria? Are there exceptions or edge cases?

This architecture prevents the drift that happens when the way data is stored diverges from how the business thinks. Separate versioning, but joined by mappings, means each layer can evolve at its own pace without breaking the connection.

Back to top

Real-world examples from Salesforce

Let’s look at how this dual-ontology approach works in practice across different Salesforce clouds.

Agentforce

Descriptive ontologies model agent guardrails, outcomes, and decision logic: what agents should and shouldn’t do, and why. Structural ontologies map those concepts to Data Cloud objects, Einstein Trust Layer constraints, and grounding data sources. Together, they enable agents to make autonomous decisions that are both intelligent and compliant.

For example, a service agent needs to know: “Can I issue a refund to this customer?” The descriptive layer defines refund eligibility rules (purchase date, return window, product type, previous refunds). The structural layer maps to order history tables, product catalogs, and payment records. The agent can then both retrieve the facts and apply the policy correctly.

Agentforce Service 

Descriptive ontologies model entitlement rules, escalation policies, and severity definitions. This is the business logic that governs customer support. Structural ontologies map these to case tables, service level agreement (SLA) timers, entitlement records, and milestone tracking.

When a customer asks, “When will my case be resolved?” the agent understands both the policy commitment (based on contract tier and severity) and where to find actual case status (which milestones have been hit, current queue assignments, agent availability).

Agentforce Sales

Descriptive ontologies model opportunity stages, qualification criteria, and forecasting methodology, or the shared language your sales team uses. Structural ontologies map those concepts to opportunity objects, custom fields, forecast categories, and pipeline reports.

This ensures agents and analytics tools interpret “qualified pipeline” the same way your VP of sales does. No more confusion about whether pipeline reports include early-stage deals or only opportunities that meet budget, authority, need, and timeline (BANT) criteria.

Back to top

Trust, governance, and explainability: making answers auditable

Enterprises don’t just need correct answers. They need answers they can defend to customers, auditors, and regulators. Dual ontologies make that possible by turning every response into an auditable artifact. Here are six ways this shows up:

1. Showing work by design

Descriptive ontologies record the meaning and the policies, while structural ontologies record where the facts live. Together, they let an agent return a result and the reasoning behind it, including the exact concepts and terms used (with allowed synonyms), the tables, objects, fields, and join paths used to find the facts (bindings), and the specific records that satisfied the policy or metric (citations).

2. Versioning without chaos

Meaning and schemas change, but they shouldn’t break trust. Independent versioning allows you to tag descriptive and structural layers separately, then map versions to each other. Release notes should describe policy updates and schema changes in plain language. And maintaining prior mappings allows for rollback, ensuring yesterday’s answers are reproducible today.

3. Setting guardrails that agents can’t ignore.

Policies aren’t suggestions; they’re executable constraints. Entitlement and SLA rules must be evaluated before actions, not after. Permission boundaries are checked against user roles and data classifications, and sensitive actions can require human approval with a clear policy reference. In Salesforce terms, this means entitlements, milestones, flow decisions, and the Einstein Trust Layer all work together.

4. Early drift detection

Agents can fail when meaning and data diverge. To prevent this, implement alerts for schema drift (when fields, relationships, or data types change under a mapped concept) and policy drift (when a definition changes and existing mappings are now incomplete). You should also track coverage to see: which high-value questions are fully defined and bound; which are only partially covered; and which are out of scope.

5. Respect privacy and data residency

Structural ontologies should carry access tags and residency constraints alongside fields and relationships. This includes marking data classes such as personally identifiable information (PII), protected health information (PHI), payment data, and regional residency, and then enforcing those markings at query time so agents only touch allowable sources. Finally, record the checks performed with the answer for audit.

6. The answer receipt your agent should return

Every high-stakes response should come with a compact, human-readable receipt detailing the answer’s provenance. This receipt should include the following:

• Result: The answer in plain language.
• Policies applied: The named rules or metric definitions evaluated.
• Sources: The objects, fields, and external systems used.
• Records: Links or IDs for the exact rows that satisfied the rules.
• Ontology versions: Descriptive version X, structural version Y, mapping Z.
• Time window: The effective dates considered.
• Approvals or exceptions: Who approved, why, and when.
• Confidence: A score plus the reason for any uncertainty.

A quick example:

If a customer asks, “Am I entitled to premium support today,” the agent could return the following auditable breakdown:

• Policies applied: Premium Support Eligibility v3.2, SLA Gold v1.9
• Sources: Service Contract, Entitlement, Account Tier in Data Cloud
• Records: Contract 004512 active through 2025-03-31, Entitlement E-7891
• Outcome: Yes, coverage through 2025-03-31, response target 2 hours
• Notes: Customer is in grace period after renewal, approval not required

Scorecard for trustworthy agents

To track real user trust, enterprises should monitor signals such as:

• Disagreement rate: percent of sampled answers where humans and agents differ when shown the same policies and data.
• Citation completeness: percent of answers that include records, policies, and versions.
• Prevented violations: number of actions blocked by policy checks.
• Repeatability: same question, same data, same answer rate.
• Change latency: time from policy or schema change to updated mappings in production.

Back to top

Why this matters now

The AI landscape is shifting rapidly, and the data-enabled ontological approach is becoming increasingly critical for several reasons.

• Context engineering is the new prompt engineering. Agents need rich, structured context, not just raw data dumps, to make reliable decisions. Descriptive ontologies provide exactly that kind of curated context.
• Design systems are evolving for AI. Just as design systems brought consistency to user interfaces, semantic design systems are emerging to bring consistency to how AI interprets and acts on information. Ontologies are the foundation of these systems.
• Knowledge graphs are the natural layer for AI reasoning. Resource description framework (RDF) and graph-based approaches enable machines to navigate relationships, infer new facts, and explain their reasoning. These are capabilities that flat tables and embeddings alone can’t deliver.
• Agents need both structure and semantics to be reliable. Retrieval-augmented generation (RAG) helps with factual grounding, but without semantic understanding of business meaning, agents will remain brittle and prone to misinterpretation.

Structural ontologies make data understandable to machines. Descriptive ontologies make the business understandable to machines. Your agents need both to deliver trustworthy answers with trustworthy meaning. On the path to making your agents “unstoppable,” it’s more important than ever that enterprises that get this right.

Back to top