Does connecting to a database and generating SQL guarantee that an Agent will answer business questions correctly?
When asked the same question, “What was last quarter’s revenue?”, different tools yield different answers: a BI tool might include taxes and shipping costs; a Notebook might fail to deduct discounts and returns; finance may recognize revenue based on shipment dates, while the Agent is still guessing how tables relate.
The problem lies behind the two characters for “revenue.” This article is organized based on Du Junping’s presentation at DACon 2026, titled “Open Semantics, Ontology, and Metadata: The Three Pillars of Agent Context.”
Why: The Need for a Semantic Layer
An Agent needs to know three things: how revenue is calculated, which date determines the time period, and which tables should be joined.
When it further participates in decision-making and execution, it must also know whether the current user has permission and what conditions the operation must satisfy.
Organizing this business knowledge into a shareable, maintainable context reduces the need to guess from scratch every time. This is the starting point of the semantic layer: not providing the model with more data, but giving it a stable framework for interpretation.
What: What Each of the Three Pillars Solves
Unified Metadata
Enable the Agent to locate real assets: where the data resides, its structure, and how to access it.
The key point is “no need to move all data to one place.” Metadata provides the map and the passport, not a relocation of everything on the map into a single room.
Open Semantic Layer
Unify metrics, dimensions, time definitions, and join logic so that BI tools, applications, and Agents use verified business definitions.
This is the core layer for resolving “inconsistent revenue definitions.” It constrains not the data format, but the calculation meaning: what constitutes the numerator and denominator, which field determines the time period, and which joins are valid.
Ontology
Express business entities, relationships, and constraints. For example, “personal data” includes email and phone numbers; these concepts are then linked to actual fields to check permissions and data masking policies.
This layer’s role is most evident in permission and compliance scenarios: when the question shifts from “How much revenue?” to “Can this person’s information be shown to this role?”, what is needed is not a metric definition, but the relationship between concepts.
Together, these three form a relatively complete Agent Context. The context paths invoked for revenue analysis and querying personal data are different—this is crucial: context is not a static document, but a path composed according to tasks.
Comparison of Two Paths
| Dimension | Revenue Analysis | Personal Data Protection |
|---|---|---|
| Starting Point | Business term interpretation | Business domain |
| Primary Basis | Metric and dimension definitions | Ontological relationships |
| Endpoint | Metrics → Assets → Query execution | Concepts → Fields → Permissions and masking |
| Key Constraints | Consistent definitions, time granularity | Minimum necessary, auditable |
The same underlying foundation supports two completely different paths. This is the distinction between “sharing” and “unifying”: sharing a foundation does not mean all questions follow the same chain.
How: How to Start Building
The path proposed in the presentation is pragmatic:
- Select a high-value problem first, such as revenue analysis.
- Business and engineering teams jointly confirm definitions.
- Bind to real assets.
- Validate using reference questions and different roles.
- Once usability is confirmed, publish as a shared object.
- Revise based on usage feedback.
Scenarios help validate value, while the shared foundation allows this knowledge to be reused by the next application.
Step 4 is most easily simplified to “ask a few questions to test.” A stricter approach is to design a set of reference questions and run them with different roles: for the same question, analysts, business owners, and restricted roles should see different answers and field scopes, and these differences must be intentionally designed.
An Often Overlooked Point: Context Expires
When fields change, permissions shift, or revenue rules are adjusted, re-validation is required.
This leads to a common misconception: treating the semantic layer as a one-time construction project. In reality, it is closer to an asset requiring continuous maintenance, needing versioning and regression testing just like code and documentation.
The presentation also mentioned an interesting handling method: content learned by the Agent through usage can first be retained as a candidate source and updated into formal definitions only after review.
This design separates “learning” from “taking effect.” A self-learning semantic layer without a review process will quickly accumulate a batch of unconfirmed definitions, ultimately becoming more dangerous than having no semantic layer at all.
Start with a Real Question: Clarify Four Things
Based on the shared content, I have organized the following four questions as an evaluation checklist. This is an editorial suggestion, not a conclusion provided in the original speech:
- Who owns the definition? If a metric lacks a clear owner, it will inevitably develop two versions sooner or later.
- Can concepts be mapped to assets? No matter how accurate the definition is, it cannot be executed if it does not map to actual fields.
- Does permission remain valid for different roles? The same concept should have different visibility scopes under different roles.
- Can changes be traced and re-verified? Changes that cannot be traced effectively render historical data incomparable.
These four questions cover responsibility, implementation, permissions, and versioning, corresponding precisely to the three pillars plus the governance running through them.
My Assessment
The difficulty in building a semantic layer lies not in technology, but in ownership. Unified metadata, an open semantic layer, and Ontology can all be constructed using engineering means, but without clear definition owners and change processes, they will evolve into isolated silos.
Therefore, rather than comparing tools first, it is better to confirm: who has the authority to define this metric, who needs to be notified during changes, and who will re-verify after changes. Once these answers are clear, technology selection becomes meaningful.
Source: Du Junping, “Open Semantics, Ontology, and Metadata: The Three Pillars of Agent Context,” DACon 2026.