Your Agent Says 4.1% Churn, Your Dashboard Says 6.8%: The Semantic Layer Under Agentforce

Your VP of Sales asks the agent in Slack what Q2 churn came in at. The agent answers 4.1 percent, with a tidy one-line explanation. She opens the dashboard she has read every Monday morning for two years. It says 6.8 percent. Nobody typed anything wrong, no integration failed overnight, and both numbers are defensible.

The agent counted logo churn across accounts with no renewal opportunity closed in a rolling ninety days. The dashboard counts revenue churn against a fiscal quarter, and it excludes accounts under a hundred seats because someone made that call in 2023 and wrote it into a [formula field](/terms/formula-field). One English word, two definitions, two systems that were each doing exactly what they were told.

That gap is the semantic layer problem, and it has quietly become the thing that decides whether an Agentforce rollout survives its first executive review. This post covers where metric definitions actually live in Data 360, the layering rule that most orgs break in their first week, how the unstructured side reaches the same governed model, and where the new open standard for all of this landed in July.

The model is not the part that is broken

The instinct when an agent returns a wrong number is to blame the model. Better grounding, a tighter prompt, maybe a different LLM. That instinct is wrong roughly nine times out of ten, and chasing it burns weeks.

Salesforce calls the actual problem the data meaning disconnect: companies unify the infrastructure, then leave the definitions fragmented across every tool that touches them. A term like customer churn carries several conflicting definitions inside one company. So does active user, so does pipeline, and so does anything involving a week, because half your systems start the week on Monday and the other half start it on Sunday.

Business intelligence tolerated this for twenty years because a human sat in the loop. An analyst sees two dashboards disagree, feels the itch, asks in a channel, and someone explains the hundred-seat exclusion. The mismatch gets resolved socially, and nobody writes it down.

An agent does none of that. It picks a definition, answers with the same flat confidence it uses for everything else, and then, if you have wired actions, acts on it. Accenture's projection that AI agents become the primary users of enterprise software by 2030 is the part that turns this from an annoyance into an architecture problem. The tolerance for ambiguity that made BI workable is precisely what agents lack.

The four layers that decide the answer

Data 360 is built on Apache Iceberg, which decouples where the bytes sit from what the bytes mean. That separation is the whole design, and it produces a stack with four distinct jobs.

Raw data lands in Data Lake Objects. A DLO is deliberately context-free. It is the shape the source system happened to have, column names and all, with no opinion about what any of it means.

Architects then map DLOs to Data Model Objects. This is where business logic gets attached: which field is the customer identifier, how Account relates to Subscription, what counts as an active record. Salesforce ships the canonical Customer 360 Data Model with prevalidated entities so you are not inventing an engagement model from scratch, and it extends for whatever your org actually does.

Calculated insights sit alongside DMOs and hold the derived numbers, the ones that involve aggregation rather than a single field lookup. Lifetime value and annual recurring revenue belong here, defined once, rather than being recomputed in four dashboards and one notebook.

Data Graphs sit on top as pre-assembled, subsecond snapshots. They exist because an agent asking a question in a chat window cannot wait for a multi-object join to resolve.

Then comes the rule, and it is stated flatly in Salesforce's own guidance: expose Data Graphs and DMOs to the AI layer, never raw DLOs.

Why the DLO shortcut is so tempting and so bad

Here is how orgs break that rule, and it is never through carelessness. It is through speed.

You need an agent to answer questions about subscriptions. The DMO mapping is half done and the person who owns it is on leave. But the DLO is right there, freshly ingested, with all the columns. You point a retriever at it, the demo works, and the sprint closes on time.

What you shipped is an agent reading column names with no join logic and no metric definitions behind them. Ask it about churn and it will find something churn-shaped, compute it from whatever is adjacent, and answer. The failure mode is not an error message. It is a plausible number.

You will notice this the first time two people ask the same question with slightly different phrasing and get answers that differ by a factor you cannot explain. By then the agent has been in production for six weeks and somebody has already put one of its numbers in a board deck.

The Atlas Reasoning Engine is good at deciding what to retrieve. It has no way to know that the subscription table it just read defines an active subscription differently than your finance system does. That knowledge only exists if someone encoded it in the DMO layer, which is the layer the shortcut skipped.

A Semantic Model is a real object, not a metaphor

For a long time "semantic layer" in the Salesforce world meant a slide. That changed with Tableau Semantics, which is a shipped, configurable thing with an actual container object behind it.

A Semantic Model brings together Data 360 objects, their relationships, calculations, and metadata into one business-language definition for a specific use case. It is where you write down, once, that churn means revenue churn on a fiscal quarter excluding sub-hundred-seat accounts, and that the exclusion exists because of a 2023 decision.

Availability is the part to check before you plan anything around it. Tableau Semantics is GA to Tableau Next customers as part of the Tableau+ SKU, and to Data 360 customers. It is deeply integrated into Data 360 and is not available without it. If you run Tableau as a standalone BI purchase and have no Data 360 footprint, this is a licensing conversation before it is an architecture one.

What earns the effort is that the same layer serves both audiences. An analyst asking Tableau Next for a Q3 engagement breakdown in plain language, and an agent evaluating that same calculated insight before firing a renewal workflow, are reading identical governed logic. That is the first time in the platform's history those two paths shared a definition rather than agreeing by coincidence. Our agentic analytics guide covers the analyst side of that in more depth.

Unstructured data goes through the same door

Most of what your agent needs to be smart about is not in a table. It is in call transcripts, contracts, support email threads, and a folder of PDFs someone maintains.

Data 360 pulls those into Unstructured Data Lake Objects from sources including S3, SharePoint, and Google Drive. The engine extracts metadata, chunks the content, and creates vector embeddings, then maps the result into Unstructured Data Model Objects. The naming is clunky, and the point is that unstructured content lands in the same DMO framework as everything else rather than in a separate vector store nobody governs.

That unified graph is what makes multimodal retrieval-augmented generation work properly. An agent about to trigger a renewal can vector-search the support history, surface a transcript where the customer flagged a billing dispute, and weigh that against the structured ARR figure before it decides whether to proceed or escalate. Both halves of that judgment come from governed context.

There are two ways to wire the retrieval side, and the gap between them is mostly about how much control you want.

The fast path is the Agentforce Data Library. Add one in Agentforce Builder or Setup and it provisions the whole chain for you: data streams, objects and mapping, vector data store, search index, retriever, prompt template, and the agent action. For a knowledge-article use case this is genuinely a good default, and arguing against it wastes a week you could spend on the metric definitions that actually disagree.

The manual path takes longer and gives you the parts the library abstracts away: broader source variety, control over ingestion and processing, and retrieval mechanisms past basic search, including hybrid search. When you configure a custom retriever you select the DMO linked to the search index, which is the moment the semantic layer and the retrieval layer are bound together.

One habit worth building either way: test a new retriever through a prompt template first, before you assign it to an agent. A retriever returning subtly wrong chunks looks identical to a retriever working correctly, right up until an agent quotes it to a customer. The Einstein Trust Layer will mask and log what passes through, and it will not tell you the retrieved passage was the wrong one.

Apache Ossie and the portability question

Everything above is Salesforce-shaped. If you define ARR once inside Data 360, you have solved the problem for the tools that read Data 360 and done nothing for the warehouse team who defined it differently in dbt eighteen months ago.

That is the gap the Open Semantic Interchange was built for. Snowflake announced it in September 2025 with Salesforce, dbt Labs, BlackRock, and RelationalAI among the founding group, on a simple premise: semantic definitions should be portable between vendors the way table formats became portable with Iceberg.

The first specification landed on GitHub on January 27, 2026 under Apache 2.0. It defines a vendor-neutral, extensible model for semantic layer constructs including data sets, metrics, dimensions, relationships, and contexts. dbt Labs open-sourced MetricFlow as a reference implementation, which gave the spec something real to be tested against rather than leaving it a document.

The working group crossed roughly thirty organizations through the first half of 2026, including Databricks, Qlik, Collibra, AtScale, and JPMorgan Chase. A Financial Services Semantic Working Group held its first formal meeting on June 4, 2026, which matters more than it sounds: industry-specific extensions are where a generic spec either proves useful or quietly stalls.

Then the governance move. On July 10, 2026, the project announced acceptance into the Apache Incubator under a new name, Apache Ossie, with development moving to github.com/apache/ossie. A vendor-led consortium became a foundation project with the neutrality that implies.

Salesforce's stated direction here is Bring Your Own Semantic, which would let you import an external semantic layer into Data 360 directly rather than redefining it. That is the feature to ask your account team about, because it is the difference between the semantic layer being a Data 360 feature and it being an interoperability standard your org can actually plan around.

One honesty note, because the marketing has gotten ahead of the artifact. The specification the project's own site lists is v0.1, released in January. Several vendor posts describe it as finalized. A 0.1 is a starting point, and treating it as a settled standard you can architect a five-year data strategy on is optimistic. The direction is right and the governance move is real. The spec is young.

The build order that works

You do not fix this by chartering a semantic modeling project. Those die. You fix it by picking the metrics that are already causing arguments.

Inventory the disagreements first. Ask five people in different functions to define your top ten metrics in one sentence each. Do not coach them. The ones that come back with three different answers are your backlog, in priority order, and you now have written evidence for the funding conversation.

Pick five, not fifty. The metrics that appear in board decks and in agent questions. Everything else waits.

Finish the DLO to DMO mapping for the objects those five touch. This is the unglamorous part and it is the part that determines whether any of the rest works. Version the mappings the way you version code, because a semantic contract that changes silently is worse than no contract.

Define the five in a Semantic Model, with the exclusions written down. The hundred-seat rule goes in the definition, not in a formula field and a colleague's memory.

Expose a Data Graph, not the underlying objects. Then check what your existing agents are actually reading. In most orgs that have been building since last year, at least one retriever is pointed somewhere it should not be.

Wire the retriever, test it through a prompt template, then assign it. Ask each of the five questions three different ways and confirm the number does not move.

Frequently asked questions

Do I need Tableau Semantics to fix this? No. The DMO and calculated insight layer already gives you define-once behavior for structured metrics, and it ships with Data 360. Tableau Semantics adds the business-language modeling surface, natural language querying, and the shared definition with Tableau Next. Fix the DMO layer first regardless.

Will a better model reduce the wrong answers? Only at the margins. A stronger model reads your data more capably, which means it computes a confident number from an undefined metric slightly faster. Definition problems do not respond to model upgrades.

Does zero-copy federation break the semantic layer? The opposite. DMOs mapping external tables carry business logic and lineage forward without moving the data, which is how the semantic governance reaches platforms Data 360 does not own. We covered the mechanics in the zero-copy guide.

Is Apache Ossie something I should act on today? Ask two questions and then wait. Ask your BI vendor whether they plan to export to the spec, and ask Salesforce where Bring Your Own Semantic sits on the roadmap. Do not restructure anything around a 0.1 spec.

Your next step

Open your busiest agent's retriever configuration and check what it is bound to. If the answer is a DLO, you have found the twenty-minute fix that removes the most risk on this list. Then post one message asking three colleagues to define your three most-quoted metrics in a sentence each, and keep the replies, because an inconsistent thread is the cheapest funding case you will ever assemble for this work. If the mapping underneath is still half-finished, the Data 360 implementation guide covers that first.

About the Author

Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.