Beyond the Semantic Layer: Engineering the Agentic Data Stack

Four years ago, back in 2022, I wrote an article titled “Demystifying the Metrics Store and Semantic Layer”. At the time, the Modern Data Stack was peaking. We successfully solved the physical storage and scaling problem with cloud data warehouses like Snowflake, BigQuery, and Databricks. Yet, there was a massive, glaring blank space in the market: the “last-mile” gap between physical data schemas and actual business understanding.

Technical metadata (like table names and column joins) was useless to business users. To bridge this, we saw the rise of the Metrics Store (also known as Headless BI) and the Semantic Layer. The core philosophy was simple: define your metrics once, and reuse them consistently anywhere — whether in BI tools, spreadsheets, or SaaS integrations.

Fast forward to today. The data landscape has undergone a tectonic shift. But this shift isn’t because we have larger warehouses or faster query engines. It’s because the end-user of our data stack has changed. The primary consumer of your data is no longer a human analyst staring at a dashboard. The new user is an agent.

In this post, I want to explore the three core philosophies that govern this new era, detail the five-layer agentic data stack that is emerging, and explain how the combination of semantic layers and ontologies is more important than ever.

The Core Philosophies of an Agentic Data Stack

Building a data environment ready for autonomous agents requires a fundamental shift in our engineering mindset. Based on architectures pioneered by modern data startups, we can synthesize three core philosophies that define this new paradigm:

Pillar 1: Sovereign, Version-Controlled Assets (Git-Backed Logic)

Your business logic, metric definitions, and organizational workflows shouldn’t rent space inside a vendor’s proprietary cloud database. They are your core IP — they must be sovereign assets.

In the agentic data stack, definitions are stored as plain-text declarative files (like YAML) in a Git repository hosted on your own cloud account.

• Git-Backed Governance: Meaning is tracked under strict version control. Changes to definitions go through the exact same code-review pipelines data engineers use — with branches, pull requests, automated integration testing, and peer reviews.
• Zero Lock-In: Because the semantic model lives as standard text files in your repository, it is completely readable and maintainable without any SaaS tool’s proprietary UI. You own the context; you can switch execution engines whenever you choose.

Pillar 2: Unified, File-Based Semantic Context

Traditional analytics separated the “semantic layer” (defining metric math like revenue = bookings - returns) from the "ontology and metadata" (explaining how concepts relate and who is allowed to see them).

To an AI agent, this separation is a death sentence. The agent needs both math and relationship context to reason effectively.

Everything is a File: In a sovereign stack, everything exists in a single, unified workspace directory tree:

• /models — Maps the semantic tables, fields, and logical query blocks.
• /context — Holds business glossaries, fiscal calendars, segment caveats, and notes.
• /permissions — Declares role-based access controls and row-level filtering policies.
• /apps & /agents — Stores the declarative manifests of the very tools and rules running on top of this model.

Language-Agnostic Assets: Plain text is the native tongue of LLMs. File structures are easily navigated, read, diffed, and written to by LLMs and developer IDEs alike.

Pillar 3: Active Context Evolution (Self-Improving Engine)

In a traditional BI setup, semantic layers are static. They are designed as “write-once” schemas that slowly rot until a data engineer manually cleans them.

An agentic stack operates as a closed-loop feedback system.

• Learning on the Job: When an AI agent performs an analysis, it often encounters small semantic gaps or is corrected by a human user (e.g., “No, excludes promotional accounts for this region”).
• Proposing Context Patches: Instead of throwing that learning away, the agent packages the correction and automatically writes a proposed patch (a Git commit or Pull Request) back to the YAML semantic files.
• Compounding Context: Once a data steward approves and merges the PR, the ontology is permanently updated. The next analytical task inherits this updated knowledge, systematically raising system accuracy while cutting LLM token usage.

The Standards of Yesteryear: Palantir’s Ontology and the Rise of Apache Ossie (OSI)

To understand how we implement these philosophies, we have to look at the open standards that paved the way.

The Semantic Layer: Apache Ossie (formerly OSI)

In the mid-2020s, the data community reached an inflection point. Every BI tool, catalog, and querying engine held its own private, hard-coded definition of “Active Customer” or “Revenue.” This proprietary fragmentation created a nightmare of metric drift.

To solve this, a massive, industry-wide coalition of over 50 organizations — including bitter rivals like Snowflake and Databricks — coalesced around the Open Semantic Interchange (OSI) initiative, which recently entered the Apache Software Foundation as Apache Ossie (incubating).

The absolute beauty of Apache Ossie is that it is 100% vendor-neutral. Meaning belongs to the commons. By donating the spec to the ASF, the community solved the “vendor trust dilemma.” No single player controls the venue or roadmap; the spec is governed by a community where merit is earned by contribution, not company size. This completely eliminates the “lock-in tax” that enterprises have paid to SaaS vendors for decades.

Technically, Apache Ossie is designed for extreme interoperability — it acts as the “USB-C for semantics”. By defining metrics, dimensions, datasets, and relationships in a standardized, open-standard YAML or JSON specification, any compliant tool can seamlessly import, export, and read definitions without loss of meaning. Instead of building a quadratic, custom N∗MN∗M integration web between every single tool in your stack, Ossie collapses this into a clean, linear N+MN+M model.

The Ontology Layer: Pioneer Palantir

While the traditional semantic layer focused on the math (such as how to compile a metric like “MRR” down to a query), it was structurally flat. It struggled to capture the broader, interconnected tribal relationships of an enterprise. This is where the concept of an Ontology — originally popularized and pioneered by platforms like Palantir Foundry — comes in.

An ontology acts as the “digital twin” of an organization. It defines categories, properties, and the precise link types (relations) between real-world concepts. It maps out the semantic reality: A* Flight* is operated by an Airline, departs from an Airport, and experiences a Delay.

For years, engineers dismissed Palantir’s ontology as an expensive, proprietary walled garden. But as we entered the era of AI, we realized a harsh truth: flat metric definitions without relational ontology are completely unreadable to an AI agent.

The Convergence: OSI’s Ontological Roadmap

Here is the exciting news: the line between semantic layers and ontologies is officially blurring.

While Apache Ossie started at the analytical metrics and BI layer, the working group has formally recognized that AI agents require a richer model of the world. In response, Apache Ossie is actively planning and introducing the ontology concept directly into its open-standard specification, mapping connections and semantic metadata in a dedicated ontology/ working group in its public GitHub repository. This means data teams will soon have a single, vendor-neutral standard to define both metric mathematics and relational entity ontologies side by side.

Servicing the Machine: Why Neutral Semantics & Ontology Just Unified

In the old human-centric world, semantic layers were often treated as “nice-to-haves” or BI configurations. If a dashboard broke because of a bad join, a human analyst would manually debug SQL.

But to an autonomous AI Agent, raw metadata, un-indexed tables, and undocumented schemas are complete gibberish. If you point an LLM directly to a raw database with 300-column tables, three things happen (and none of them are good):

1. Hallucinations Explode: The agent starts guessing join keys and entity relationships, leading to confident but completely fabricated query logic.
2. SQL Complexity Backfires: Simple tasks like user funnel analysis or session deduplication require 1,000+ line SQL queries that the agent struggles to generate reliably from scratch.
3. Token Costs Bleed You Dry: Shoveling raw schemas into an LLM’s prompt on every single turn is incredibly expensive and highly inefficient.

By unifying the Semantic Layer & Ontology into a single, cohesive logical tier, we give AI agents a shared, governed brain of the business. Instead of writing “blind” SQL against a raw database, the agent queries the unified, Git-backed ontology.

OLD WAY (Human BI):
Raw Warehouse Schema  ──> Analytical SQL (Written by Analyst)  ──> Static BI Dashboard
NEW WAY (Agentic):
Enterprise Data  ──> Sovereign Semantic & Ontology (YAML/Git)  ──> Contextual MCP Gateway  ──> AI Agent (Reasoning)

Grounding an agent in structured, vendor-neutral semantic context doesn’t just improve trust; it delivers dramatic efficiency gains. Industry benchmarks show that leveraging a unified context graph can reduce LLM token consumption by up to 75% while simultaneously boosting query accuracy by over 35%.

The 5-Layer Agentic Data Stack

So, what does this new, vendor-neutral architecture actually look like under the hood?

Get Joanna He’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

This 5-layer data stack is synthesized and summarized based on the pioneering architectures and implementations of emerging semantic-first startups in the space — most notably TextQL, Datus, Omni Analytics, and Jedify. Together, these startups have laid the groundwork for a highly modular, decoupled, and interoperable agentic data infrastructure:

Layer 1: The Data Estate & Connectors

This is your foundational storage layer: cloud data warehouses (Snowflake, BigQuery, Databricks), transactional databases (Postgres, ClickHouse), and enterprise operational systems (SAP, Oracle, Salesforce, Stripe).

• Unified Connectors: Rather than forcing a massive, risky upfront data migration or centralization effort, modern connectors passively read metadata, schemas, join keys, and historical query logs directly from your existing systems.
• Log-Mining Analytics: Connectors actively parse query histories to learn how your human engineers and dashboards have historically queried these tables, feeding this context back as structural hints.

Layer 2: Sandbox & Safety Layer

AI agents cannot operate without execution. They must write SQL, compile Python scripts, run statistical models, and render charts. The Sandbox Layer is an isolated, air-gapped container runtime that safely executes this agent-generated code.

• Query Pre-Review & Authorization: Before any SQL or script is run against Layer 1, this layer pre-audits the query for cost safeguards, syntax structure, and authorization.
• Compliance Guardrails: Ensures absolute protection against outbound network leaks of sensitive customer datasets. It blocks unauthorized terminal commands and enforces strict compliance boundaries (PII, HIPAA, and PHI data restrictions) using fine-grained, policy-based data masking.

Layer 3: Semantic Layer & Ontology (The Unified Brain)

This is the heart of the stack, and it is entirely Sovereign, Git-backed, and File-based. All definitions live as standard declarative code in your company’s repository.

This layer includes:

• The Contextual Layer: Houses standard YAML definitions mapping physical columns to real-world entities (e.g., mapping stripe.invoices.amount to a logical MRR property) and establishing their relations.
• The Active Learning Loop: Evaluates agent queries, captures user-provided corrections, and automatically commits updated definitions (via Git pull request patches) back to the repo, allowing the system’s brain to thicken with use.
• Agent-Friendly Interfaces: Exposes the logical graph through universal integration pathways:
• Model Context Protocol (MCP) Server: The open-standard API gateway that lets any LLM agent client connect directly to read available schemas, permissions, and metrics.
• Command Line Interfaces (CLIs) & REST APIs: Enable data engineers to compile, validate, and debug models locally, and integrate semantic querying natively into CI/CD pipelines.

Example: Sovereign YAML Metric & Relationship Definition

# models/customer_subscription.yml
entity: Customer
description: A verified corporate account with an active contract.
properties:
  customer_id:
    type: string
    physical_column: stripe.customers.id
  subscription_status:
    type: string
    physical_column: stripe.invoices.status

relationships:
  - entity: BillingAccount
    type: one_to_many
    join_on: customer_id

metrics:
  monthly_recurring_revenue:
    name: MRR
    description: Cumulative active subscription revenue calculated on a monthly basis.
    formula: "SUM(stripe.invoices.amount) FILTER (WHERE stripe.invoices.status = 'active')"
    owner: finance-team
    access_policy:
      roles_allowed: [finance_analyst, executive]
      row_level_security: "region = USER.region"

Layer 4: Data Agent & Reasoning Harness

This is the cognitive orchestrator — the software engine or LLM harness that plans and executes analytical work.

• The MCP Client Coordinator: The agent functions as an active MCP client. Before writing a single query, it consults Layer 3’s MCP server to obtain verified metric definitions, security filters, and logical entity paths.
• Plan, Test, and Verify Loops: The agent plans its analysis, generates code, tests it inside the Layer 2 Sandbox, and verifies the output. If a code execution error or analytical mismatch occurs, the agent runs a self-correction loop without bothering the user.
• PR Generator: When the agent uncovers systemic schema mismatches or missing documentation, it acts as a citizen engineer, writing YAML updates and submitting them as PRs to the Semantic Layer.

Layer 5: Data Applications & Shared Marketplace

The final layer completely replaces static BI dashboard interfaces with highly interactive, governed data software environments.

• No-Code “Vibe Coding”: To build a custom tool (such as a campaign funnel visualizer), a business user simply describes what they want to the reasoning agent. The agent instantly constructs the application — utilizing prompt-driven styling and layout paradigms modeled — guaranteeing that every visual widget links directly to the verified metrics defined in the Layer 3 YAML specs.
• Scenario & What-If Simulations: These apps embed custom user input columns directly alongside live metrics, letting teams model future campaigns or run financial projections instantly.
• Interactive Writebacks: Users write back comments, forecasts, or transactional updates (like overriding a budget line) securely back to the source systems through governed database-write configurations.
• Governed Marketplace: Prompts, verified insights, and specialized applications are published to a central marketplace. Because these assets are tied directly to the sovereign Semantic Layer, they automatically inherit fine-grained access policies, ensuring that no two data applications can ever display conflicting numbers.

The Path Forward

In 2022, we dreamed of a metrics store that would provide a “single source of truth” for dashboards. In 2026, that dream has been superseded by a far grander reality.

We are no longer just organizing tables for human convenience. We are compiling our institutional knowledge, definitions, relations, and safety guidelines into a sovereign, executable code asset. By marrying the semantic layer with the ontology, we are giving our autonomous systems the cognitive map they need to run our businesses safely, cheaply, and with absolute precision.

For data engineers, the mandate is clear: Stop building dashboards. Start engineering the context.

What does your company’s semantic repo look like? Are you still writing raw SQL strings inside your agent prompts, or have you migrated to a version-controlled, vendor-neutral ontology? Let’s chat in the comments.

References & Pioneering Implementations

• Joanna He, Demystifying the Metrics Store and Semantic Layer (Medium, 2022).
• Joanna He, Understanding the Metrics Store: Why, What and How Enterprises Adopt Metrics Stores (Kyligence, 2022).
• TextQL, Sovereign Ontologies, Code-First Semantic Modeling, and the Ana Agent Harness (2026).
• Omni Analytics, Introducing Omni Apps: AI App-Builder and Semantic Grounding Interfaces (2026).
• Jedify, Semantic Fusion™: Grounding Enterprise AI Agents in a Unified Context Graph (2026).
• Datus, Open-Source Agentic Data Engineering, Subagent Delivery, and Context Engines (2026).
• Apache Ossie (Incubating), Open Semantic Interchange Specification & Ontological Integration Working Group (ASF, 2026).
• MotherDuck & Partner Communities, Context, Semantics, and Ontology: A Primer for the Agentic Era (2026).