Turn business meaning into governed execution—so the model has less to reconstruct at runtime.

An analytics agent can write valid SQL and still answer the wrong business question.

The database executes it correctly. The mistake is in what “revenue,” “enterprise customer,” or “last quarter” was taken to mean.

The failure becomes visible in the agent, but it may have started in the business definitions and data model underneath it.

Let the Workflow Define the Agent

Suppose the capability is to let employees ask for approved financial metrics in natural language.

The workflow still contains different kinds of decisions: understand the request, identify the metric, apply its calculation, query the data, and explain the result.

Some require interpretation. Others already have an agreed answer.

If finance has defined the metric and the data team has established its relationships, why ask the agent to reconstruct them?

Agent autonomy should follow that division of work. Model judgment adds value where the workflow still contains ambiguity.

A well-defined step should not become an open-ended model decision merely because the interface now uses natural language.

Connect Data to Business Meaning

A semantic layer is a reusable layer of business meaning between physical data and the applications that use it.

It exposes established concepts such as Recurring Revenue, Enterprise Customer, and Fiscal Quarter, together with the rules needed to query them.

Dashboards, applications, and AI agents can use those definitions rather than reinterpret raw tables independently.

Physical data → Semantic layer → BI tools, applications, and AI agents

Semantic layers predate LLMs. Analysts have long needed consistent definitions, but could also fill gaps using knowledge scattered across reports, saved SQL, documentation, and experience.

An AI interface exposes that hidden dependency: if the meaning is unavailable, the model has to infer it.

Narrow What the Model Must Reconstruct

A semantic layer makes established business decisions reusable.

Instead of reconstructing definitions from raw schemas and documentation, the model can map a request to approved concepts.

This helps define a valid analytical space: which metrics, dimensions, filters, relationships, aggregation rules, and time logic can be combined meaningfully.

Business-friendly column names alone do not provide that structure.

Good data modeling still matters. If the underlying data structure is unclear, adding business definitions on top will not make the result reliable.

Map, Validate, and Govern Meaning

Most of the work in building a semantic layer happens before anyone writes YAML or SQL.

Business owners first need to agree on meaning and scope. Data teams then map those definitions to physical data and validate the calculations against trusted results.

Definitions also need ownership, versioning, and checks when the business or source data changes.

Different reporting purposes may legitimately require different definitions. Their scope should be explicit so the system can select the appropriate one—or ask for clarification when the request is ambiguous.

Each settled rule leaves less business logic to reconstruct at runtime.

Flexible Interpretation, Structured Execution

Consider:

“What was recurring revenue for enterprise customers in APAC last quarter?”

Without a structured semantic path, the model may need to interpret the request and reconstruct the underlying business logic before generating SQL.

A more structured path separates those responsibilities.

1. The LLM maps the request to approved semantic concepts

Instead of rebuilding business logic from raw tables, the model identifies the existing concepts that best match the user’s intent:

  • Metric: Recurring Revenue
  • Segment: Enterprise
  • Region: APAC
  • Time: Last Fiscal Quarter

The model handles the remaining ambiguity by choosing among definitions the enterprise has already established.

2. The semantic layer supplies the business meaning

Those concepts already carry the approved calculation, relationships, aggregation rules, and time logic.

Those rules are already available at runtime.

3. The query system applies the definitions

The query path uses those semantic definitions to construct or compile the query and execute it against the underlying data.

Prompt context still depends on the model applying a rule correctly. When the query system applies the definition itself, more responsibility moves into software.

4. The LLM explains the structured result

The division of responsibility becomes:

  • LLM: map intent to approved concepts
  • Semantic layer: define business meaning
  • Query system: apply the rules
  • Database: execute
  • LLM: explain

Model judgment belongs in the ambiguity that remains. Established business decisions can stay in the system.

RAG: Relevance Is Designed Before It Is Retrieved

A RAG pipeline already reflects design choices before the first query arrives.

When the system is designed, the team has already decided what context matters for the task—such as product, version, region, effective date, source type, and document hierarchy.

Those decisions shape what gets indexed, which metadata is preserved, how content is chunked, and which signals retrieval can use later.

The system defines part of the relevance space before the user asks a question.

Those choices also shape how content is represented for retrieval.

A chunk may be difficult to find on its own because it has lost the title, section, or surrounding context that gives it meaning. The retrieval representation can include additional context while the returned evidence stays faithful to the source.

For example:

  • chunk_to_embed: context-enriched text optimized for retrieval
  • chunk_to_retrieve: source-faithful content returned as evidence

The first can include titles, metadata, summaries, or likely questions to improve discovery. The second preserves the content the model should actually treat as source evidence.

Enrich for discovery. Preserve fidelity for evidence.

At query time, known context can narrow the search space further:

  1. Question + known context
  2. Filter by product, version, region, access, or effective period
  3. Retrieve and rerank within that space
  4. Produce a smaller set of applicable evidence
  5. LLM synthesizes and answers

A passage can be semantically similar to the query and still be the wrong evidence.

Retrieval ranks relevance inside a space the system has already helped define.

Each part has a distinct role:

  • The system defines what context matters.
  • Retrieval ranks evidence within that context.
  • The LLM reasons over what remains.

Semantic layers narrow the business meaning the model must reconstruct. RAG narrows the evidence space it must reason over.

In both cases, established enterprise decisions become part of the system design.

Better Enterprise AI Can Start With Less Room to Guess

A well-defined business process should not become an open-ended reasoning problem simply because an LLM has been added to it.

Start with the capability and workflow.

Make the decisions the business already understands explicit in the system.

Then let the LLM handle the ambiguity that remains—interpreting intent, connecting it to structured enterprise capabilities, and explaining the outcome.

Structure should carry the decisions the enterprise has already made, so the model can focus on what is genuinely uncertain.

References