Grounding agents on a semantic layer

Ask an agent grounded on your raw Salesforce objects a simple question — “what was revenue in the West region last quarter?” — and watch what it does. It finds a few objects with promising column names, guesses at a join, decides whether “revenue” means booked, invoiced, or recognized, silently drops the rows with a null close date, and returns a number. The number is wrong, but it’s stated with the same fluent confidence as everything else the agent says. Nobody in the room can tell the difference, which is the entire problem.

This failure mode isn’t a model failure and it isn’t a grounding-data failure in the usual sense — the data was right there. It’s a semantics failure. The agent had access to the tables but not to the meaning: which table is authoritative, how “revenue” is actually defined in your business, which filters are always applied, what a “region” even is. That meaning has historically lived in a BI tool’s data model, in a dbt project, in three analysts’ heads, and in a wiki nobody updated. An agent can’t read any of those.

The fix that’s moved from analytics-team plumbing to agent-team requirement over the past year is the semantic layer — and in the Salesforce stack, that layer is now a first-class part of Data 360, delivered through Tableau Semantics. This post is about what a semantic layer actually is, how it changes agent grounding, how it sits next to the RAG and data-graph grounding you may already be using, and — because this is the part vendors skip — where it stops helping.

Two kinds of grounding, and why teams conflate them

Most Agentforce grounding conversations are really about unstructured retrieval: point the agent at a knowledge base, build a search index, let it pull relevant passages into the prompt. That’s retrieval-augmented generation, and Data 360 does it well. When you configure a retriever in Data 360, you choose the data space that holds the search index, select the data model object (DMO) linked to that index, and pick the index itself; Data 360 automatically creates a retriever per index that acts as the bridge between the index and your prompt templates. Great for “what’s our baggage policy” — a question answered by finding the right document.

“What was revenue in the West last quarter” is a different kind of question entirely. There’s no passage to retrieve. The answer has to be computed from structured data, against a definition of “revenue” that must match the one Finance uses, or the agent is worse than useless — it’s authoritatively wrong. Unstructured RAG can’t do this. You need the agent to query governed, structured data through a definition it can’t reinterpret.

Retrieval finds the right document. A semantic layer computes the right number. An agent that treats every question as a retrieval problem will hallucinate every metric you own.

Keeping these two straight is the first architectural decision. A serious agent uses both: a search index and retriever for the document-shaped questions, and a semantic layer for the metric-shaped ones. Conflating them — trying to answer “what’s revenue” by retrieving a dashboard screenshot’s alt text — is how you end up with a demo that works and a production agent that lies about money.

What a semantic model actually is

Tableau Semantics is the AI-infused semantic layer built into Data 360. Strip the marketing and a semantic model is a structured, governed definition of your business vocabulary: it brings together Data 360 objects, the relationships between them, calculations, and metadata into one standardized, business-friendly representation of your key terms and metrics. Critically, semantic models are first-class Salesforce metadata — they live in the platform, they’re versioned and deployable like other metadata, not trapped in a BI tool’s proprietary store.

The building blocks worth knowing by name:

Metrics — a governed definition of a measure tracked over time. “Revenue” is defined once: which sources it comes from, the join relationships, the join types, and the formula that computes it. Every consumer — a Tableau Next dashboard, an analyst, an agent — gets the same number because they all read the same definition.
Dimensions — the axes you slice a metric by: region, product, time, segment. A metric plus its dimensions is what lets “revenue” become “revenue by region by quarter” without anyone rewriting SQL.
Relationships — the governed joins between objects, so the agent never has to guess how Orders relate to Accounts relate to Regions.
The Semantic Query Generator — the engine that turns a request against the model into an actual query. The agent doesn’t write SQL against your tables; it expresses intent against the semantic model, and the generator produces the correct, governed query underneath.

Here’s the shape of a metric definition. This is illustrative — the exact authoring surface is Tableau Semantics’ UI and the underlying metadata — but it captures what a governed metric encodes:

metric:
  name: net_revenue
  label: "Net Revenue"
  description: "Recognized revenue net of refunds and credits.
                Excludes intercompany and test accounts."
  source: sales_order__dlm
  aggregation: sum
  expression: "amount__c - refund_amount__c - credit_amount__c"
  filters:
    - "record_type__c != 'Intercompany'"
    - "is_test__c = false"
    - "status__c = 'Recognized'"
  time_dimension: close_date__c
  dimensions:
    - region
    - product_line
    - customer_segment

Every one of those filters is a decision an ungoverned agent would otherwise make wrong. The is_test__c = false line alone is the difference between a defensible number and one that quietly includes your QA team’s fake orders. When the agent answers “what was net revenue in the West last quarter,” it isn’t reasoning about column names — it’s requesting the net_revenue metric, sliced by region = West and a quarter of close_date__c, and the Semantic Query Generator does the rest against the one definition Finance signed off on.

How the semantic layer grounds an agent

The point of putting the definition in metadata is that the agent grounds on meaning, not tables. Salesforce’s framing is that this deep integration ensures employees and agents are grounded in data that’s not only harmonized — the identity resolution and unification work Data 360 already does — but contextualized in the language of your business. Harmonization gets you one clean customer record. Semantics gets you one clean definition of what “at-risk customer” or “lifetime value” means on top of it.

In practice, wiring this into an Agentforce agent means the agent’s actions can resolve business questions through the semantic model rather than through hand-built SOQL or a bespoke Apex query per metric. The value compounds with every metric you’d otherwise have implemented as one-off logic: instead of an getChurnRisk action and a getLTV action and a getPipelineCoverage action, each with its own definition drifting from the source of truth, you have metrics in the semantic model and an agent that queries them. Change the definition once, and every agent, dashboard, and analyst moves together.

This is also where the semantic layer earns its keep against the Atlas reasoning engine’s tendency to be confidently approximate. Atlas is very good at interpreting a fuzzy request — “how are we doing in the West” — into an intent. It is not the thing you want defining revenue on the fly. The clean division of labor is: let the reasoning engine map ambiguous language to a metric and its dimensions, and let the semantic layer hold the metric’s definition fixed. Probabilistic where the question is ambiguous, deterministic where the number has to be right. It’s the same instinct behind using Agent Script for the decisions that are policy rather than judgment — pin down what must never vary, leave the model free where variance is the point.

Data graphs: the real-time structured path

There’s a second structured-grounding mechanism in Data 360 that’s easy to confuse with the semantic layer, and the two solve different problems. A data graph is a pre-joined, flattened view of related data, materialized as a JSON string you can retrieve fast. You build one by selecting and connecting the DMOs whose relationships matter for an interaction — a customer profile with its recent orders, cases, and loyalty status — and Data 360 maintains that denormalized view so an agent can pull the whole context in one cheap read instead of traversing joins at question time.

{
  "unified_individual": {
    "id": "0PS...",
    "loyalty_tier": "Platinum",
    "lifetime_orders": 42,
    "recent_orders": [
      { "order_id": "8010...", "status": "Shipped", "amount": 219.00 },
      { "order_id": "8011...", "status": "Processing", "amount": 89.50 }
    ],
    "open_cases": 1
  }
}

Where this gets powerful is real time. If the DMO you need is a member of a real-time data graph, Data 360 keeps it in the real-time layer — under the Sub-Second Real-Time Profile, Salesforce documents roughly 95% of events completing end-to-end ingestion within about 500 milliseconds — so the agent grounds on state that’s current to the last few hundred milliseconds, not to the last batch run. For an agent handling a live conversation about an order placed ninety seconds ago, that’s the difference between competent and broken.

The mental model: a data graph answers “give me everything about this entity, now” — fast context retrieval for a specific record. A semantic metric answers “compute this measure across many records, correctly” — governed aggregation. A well-built agent uses data graphs to ground on the customer in front of it and the semantic layer to answer the analytical questions that come up. Neither substitutes for the other, and neither is the unstructured retriever you use for policy documents. Three grounding paths, three question shapes.

Portability: the OSI angle

The semantic-layer story got a lot bigger in early 2026, and it’s worth understanding even if you’re all-in on Salesforce. Snowflake convened an open-source effort called the Open Semantic Interchange (OSI) — a vendor-neutral, YAML-based standard for representing semantic constructs (datasets, metrics, dimensions, relationships, context) so they mean the same thing across tools. Salesforce is a founding member alongside dbt Labs, BlackRock, RelationalAI, and a long list of BI and data vendors, and the initiative published its first specification in early 2026.

Why an architect should care: without a standard, your “revenue” definition in Data 360, your “revenue” in dbt, and your “revenue” in a downstream BI tool are three separate implementations that drift. OSI’s bet is that a semantic definition should be portable metadata, authored once and honored everywhere — including by AI agents on any platform that reads the format. It’s early, and “founding member” is not “shipped interop,” so don’t architect around full portability yet. But it signals the direction: the semantic layer is becoming the contract between your governed definitions and every agent that consumes them, and that contract is trending toward open rather than locked in.

Where the semantic layer stops

The honest part. A semantic layer fixes the definition problem. It does not fix the problems underneath it, and selling it as a cure-all is how teams get burned.

Garbage definitions ground agents in garbage, faster. A semantic layer makes one definition of “revenue” authoritative and propagates it everywhere. If that definition is wrong, you’ve now scaled a wrong number across every agent and dashboard with governance’s blessing. The layer enforces consistency, not correctness — someone still has to get the definition right, and that someone is a human who understands the business.
It rides on unification quality. A metric sliced by “customer” is only as good as your identity resolution. If two real customers merged into one unified profile, or one split into two, the cleanest metric definition in the world still aggregates the wrong grain. Semantics sits on top of harmonization; it doesn’t repair it.
It’s not free. Everything structured in Data 360 meters. Semantic queries, data graph maintenance, and especially real-time data graphs draw credits, and an agent that fires a metric query on every turn multiplies that against your conversation volume. This is exactly the kind of per-interaction structured-grounding cost that shows up on the invoice three months after go-live — the same dynamic our credit optimization playbook exists to catch. Model it before you ground every agent turn on a live metric.
A confident wrong metric is more dangerous than an obvious gap. Because the number now carries governance’s authority, people stop questioning it. Keep the definitions visible, reviewed, and owned — the same discipline you’d apply to any code that computes money.

And the security note that applies to all agent grounding: the semantic layer is a query surface, and a query surface that an agent drives from natural language is a surface an attacker can try to drive too. Everything in our least-privilege guide for agents holds — scope which metrics and dimensions a given agent can reach, and don’t assume the semantic layer’s governance is an access-control boundary on its own.

What to actually do

If you’re grounding agents on structured Salesforce data today through hand-written SOQL, Apex actions, or one-off flows, the semantic layer is the consolidation you’ve been deferring. Start by inventorying the metrics your agents already answer badly or inconsistently — the ones where two agents give two numbers. Define those in Tableau Semantics first; they’re where the governed-definition payoff is largest and the current pain is sharpest. Keep unstructured RAG for the document questions, use data graphs for real-time entity context, and reserve the semantic layer for the metric-shaped questions it’s built for.

Then treat the definitions as production code. Review them, own them, version them, and cost the queries. The semantic layer is the difference between an agent that retrieves your business and one that computes it — and computing it correctly, every time, from one definition, is the only version worth putting in front of a customer or an executive. The agents that survive contact with production are the ones that stopped guessing at what your words mean. This is how they stop.

The observability side of that — knowing when an agent is quietly returning a bad answer — is its own discipline; we cover it in what Agentforce Command Center actually shows you.

Understanding the basics

What is a semantic layer in Salesforce Data 360?

A semantic layer is a governed definition of your business vocabulary — metrics, dimensions, relationships, and calculations — that sits between raw data and the tools that consume it. In Data 360 it’s delivered through Tableau Semantics, where semantic models are first-class Salesforce metadata. It lets analysts, dashboards, and AI agents all read the same definition of a term like “revenue,” so they return the same number instead of each computing their own.

How does a semantic layer stop AI agents from hallucinating metrics?

Without a semantic layer, an agent asked to compute a metric guesses at which tables to use, how to join them, which filters apply, and how the term is defined — and states the guess with full confidence. A semantic layer holds that definition fixed in governed metadata and generates the correct query through the Semantic Query Generator, so the agent expresses intent against a metric it can’t reinterpret rather than improvising SQL against raw objects.

What’s the difference between a data graph and a semantic metric in Data 360?

A data graph is a pre-joined, flattened view of one entity’s related data — profile, orders, cases — retrieved fast as JSON to ground an agent on the record in front of it, optionally in real time. A semantic metric is a governed definition of a measure computed across many records, like net revenue by region. Data graphs answer “everything about this entity now”; semantic metrics answer “this measure across many records, correctly.” Both differ from unstructured retrievers, which find document passages.

Grounding agents on structured data and not sure whether you need a retriever, a data graph, or a semantic model? Talk to us — untangling which grounding path fits which question is a normal first week for our team.

Grounding agents on a semantic layer: how Data 360 stops them inventing your metrics