Wasabi: A Modern Data Stack Architecture for Governed Agentic Analytics

Our opinionated take on how the modern data stack architecture should look like — and Wasabi, the open-source reference implementation that proves it.

Context

We at NeuralChainAI have been thinking, building, and arguing about the architecture of the modern data stack for years. Today we’re publishing our opinion — not as a survey of what’s out there, but as a thesis. This is how we believe a modern data platform should be architected, why we believe each layer is essential, and how those layers compose into systems that can ship real data products end-to-end.

The most demanding of those data products today is the Agentic AI analyst — a system where users ask business questions in natural language and an agent returns trustworthy, auditable, governed answers. We use the AI analyst as the lens for this post because it stresses every layer of the architecture. If your platform can power a production-grade AI analyst, it can power almost anything else: embedded analytics in your product, governed data sharing with partners, automated decisioning systems, regulated data products in healthcare or financial services, and traditional BI alongside all of it.

The post lays out our architecture, walks through how each layer contributes, and introduces Wasabi — our open-source reference implementation that turns the architecture into running code you can clone and run locally in 15 minutes.

A note on our approach: we are opinionated about the architecture, but deliberately not opinionated about the specific tools that fill each layer. Different teams have different existing investments, regulatory constraints, and skill profiles. Wasabi is built to be pluggable — every layer ships with an OSS default and a commercial alternative, and the same architecture composes whether you’re a Postgres-and-DataHub shop or a Snowflake-Atlan-Immuta enterprise. The opinion is the shape. The implementation flexes to your reality.

The Architecture

We propose the data stack to have 10 distinct layers each of which have a certain responsibility and serves a well defined purpose in the stack. Each job is a layer. Each layer has well-understood tool choices. The architecture is the composition of those layers — and that composition, more than any individual tool decision, is what determines whether your platform can support the data products you actually want to build.

We’ve found the clearest way to explain the architecture is to walk through it from the perspective of a single business question flowing through the system. Take a representative one: “What was EU enterprise revenue last quarter, broken down by product?”

Here is what we believe needs to happen, in order, to answer that question safely and credibly inside any modern data platform.

Why we wrote this

We at NeuralChainAI have spent years building and refining our view of the modern data stack. Today we’re sharing that view. This is not a survey of what’s out there. Instead, it’s a thesis.

In short, this post lays out how we believe a modern data platform should be built. Moreover, we explain why each layer matters. Finally, we show how the layers fit together to ship real data products end-to-end.

The most demanding data product today is the AI analyst. With an AI analyst, users ask business questions in plain English. Then an agent returns trusted, audited answers. We use the AI analyst as the lens for this post because it stresses every layer. However, the same stack supports much more than agents. For example, it powers embedded analytics, governed data sharing, automated decisions, regulated data products, and traditional BI.

This post walks through our stack layer by layer. After that, we introduce Wasabi — our open-source project that turns the stack into running code. You can clone it and run it on your laptop in 15 minutes.

What we are and aren’t opinionated about

We have strong opinions about the shape of the stack. By contrast, we don’t push a single set of tools. Different teams have different tools, rules, and skills. So Wasabi is pluggable at every layer. Each layer ships with one open-source default and one paid alternative. The same shape works whether you run a small Postgres setup or a full Snowflake-Atlan-Immuta stack. The shape is the opinion. The tools flex to your reality.

What we believe about the modern data stack

A modern data platform must do ten jobs in order. Each job is a layer. Each layer has good tool choices. However, the real value lies in how the layers fit together. That fit matters more than any single tool pick.

To explain the stack clearly, we’ll trace one business question through it. Take a simple example: “What was EU enterprise revenue last quarter, by product?” Here is what we believe must happen, in order, to answer that safely.

1. The platform takes the question through a stable interface

In our view, the interface should use the Model Context Protocol (MCP) for AI agents. MCP gives us a stable contract between agents and the rest of the stack. First, the interface checks who the user is. Then it carries that identity through every later step. For non-agent users — BI tools, embedded apps, custom code — the same entry point works. Only the protocol changes.

2. The platform reads business metadata

Business metadata — not just table schemas — should sit between users and data. Such metadata covers what metrics exist, how “revenue” is defined, which dimensions slice it, and which time grains apply.

This metadata lives in a semantic layer and a catalog. For the semantic layer, you can pick Cube, dbt Semantic Layer (MetricFlow), Snowflake Semantic Views, or Databricks Metric Views. All four are good picks, depending on your stack. For the catalog, options include DataHub, OpenMetadata, Atlan, Alation, or Collibra. Again, the right pick depends on what you value — engineer control, modern stack fit, or enterprise governance. We will happily wire Wasabi with any of them.

3. The platform builds intent in business terms, not SQL

Queries should move through the stack as business intent — metric: revenue, filter: region=EU AND segment=enterprise, time: last quarter, breakdown: product. Then the semantic layer turns intent into SQL. In other words, agents and tools never write SQL by hand. As a result, every consumer uses the same business meaning. This is why the semantic layer is a load-bearing choice, not a nice-to-have.

4. The platform checks intent against access policy

In our view, governance should run at query time, not in a doc somewhere. So a policy engine checks every intent before it runs. Is this user allowed to see EU revenue? Should we apply row filters or column masks? The engine then returns one of three outcomes: approved, rewritten with filters, or denied.

Open Policy Agent works well as an OSS, code-first pick. Meanwhile, Immuta works well as a paid pick with built-in warehouse hooks. Cube and the warehouses also offer their own enforcement. The right pick depends on where your team wants the check to live.

5. The semantic layer turns approved intent into SQL

Whichever semantic engine you picked now turns the approved intent into SQL. The exact SQL shape differs across Cube, MetricFlow, and warehouse-native engines. However, their job is the same — turn business intent into warehouse code.

6. The warehouse runs the query

Snowflake, Databricks, BigQuery, Postgres — the consumer doesn’t care. That’s because the semantic layer hides the dialect. So warehouse choice should follow business and team needs. The shape above absorbs the rest.

7. The platform writes lineage for every query

Lineage should be a first-class output of every transform and every query. Each query the platform runs writes an OpenLineage event. Every event captures what was asked, what ran, which columns got touched, and which user fired it. After that, events flow to a lineage store — Marquez, DataHub, Atlan, or whatever your catalog supports. As a result, data products become audit-ready and easy to explain. That’s the line between a system you trust and one you don’t.

8. Quality and freshness signals stick to results

Trust signals should travel with answers. So the semantic layer or an observability tool — Elementary, Monte Carlo, Soda, or warehouse-native checks — reports on the source tables. Are there any open quality issues? When did the last refresh run? Are tests passing? Then the agent or BI tool shows these notes alongside the answer. Importantly, a number with no freshness or quality context is a risk, not a fact.

9. The platform tags cost per query

Cost discipline should be built in from day one. Each query carries tags for the session, the user, the tenant, and the source product. As a result, per-session budgets let teams scale data product use without scaling the bill in step. Meanwhile, total cost reports show which use cases pay back.

10. The platform returns the answer with provenance

Answers should arrive with full provenance. Not “EU enterprise revenue last quarter was $12.4M.” Instead: “$12.4M, from the revenue_daily model last refreshed 47 minutes ago, currently passing all quality tests, scoped to your role’s permitted regions, queried 18 minutes ago, costing about $0.03.” Provenance turns answers into audit-ready facts.

Sometimes the data product needs to drive action. For example, it might push a decision into a CRM, fire a Slack note, or trigger a campaign. In that case, a reverse-ETL layer handles the activation. Hightouch, Census, or a governance-aware OSS pattern can fill that role. In every case, the activation respects the same rules that gated the read. So the loop closes from insight to action without breaking governance.

That’s the stack. Ten layers, ten jobs, in order. We believe this is what the modern data stack must look like to ship real data products in 2026.

Why this stack, and not something simpler

A fair question follows: “This looks like a lot of layers. Couldn’t we get away with fewer?”

We’ve thought about this hard. Our answer is no. Each layer does work that the others can’t pick up. Drop any layer, and a known failure mode shows up in production.

What happens when teams skip layers

Skip the semantic layer, and your business meanings drift across users. Then the agent, the BI tool, and the embedded app all give different answers to the same question. Trust erodes fast.

Skip the policy layer, and your governance falls over the moment new tools start running queries. Suddenly, the data your engineers spent years protecting leaks through the new front door.

Skip the lineage layer, and your data products become impossible to audit. As a result, when senior leaders ask where a number came from, the team has no answer. That’s how programs die.

Skip the observability and quality layer, and your data products quietly rot. Meanwhile, by the time a wrong number lands in a board deck, the damage is done.

Skip the cost attribution layer, and one of two things happens. Either nobody trusts the bill enough to use the agent. Or heavy use creates a bill that ends the project.

Skip the reverse-ETL layer, and your data products become read-only. As a result, they can describe the world but never change it.

Each failure mode shows up in the first few months of production. We’ve seen them. Our peers in the industry have seen them too. So this stack is what the data community has learned must be in place to stop them.

The supporting evidence

The data backs up our view. A March 2026 Alteryx and Gartner report found that 28% of US organizations have “zero confidence” in the data quality feeding their LLMs and autonomous agents — yet 89% of US firms have increased their AI spending this quarter. Meanwhile, Gartner’s March 2026 D&A Summit research projects that by 2028, 60% of agentic analytics projects relying solely on the Model Context Protocol will fail due to the absence of a consistent semantic layer. The tools are racing ahead of the systems meant to support them. Therefore, we believe the smart move is to invest in the stack now. That way, your team is ready while the rest of the market scrambles. Cube Medium

What this stack enables beyond the AI analyst

We picked the AI analyst as our lens because it stresses every layer. However, the same stack supports many more data products. Among the ones we work on with clients:

Embedded analytics in customer-facing products. The semantic layer becomes the bridge between your app and your data. Customers query through governed pre-aggregations. Meanwhile, the stack handles tenant isolation, access rules, and per-customer cost tracking.

Governed data sharing with partners. External data products run on the same semantic and policy layers. As a bonus, lineage and audit trails meet data sharing rules out of the box.

Regulated data products in healthcare and finance. The PII and compliance layers extend the stack for HIPAA, PCI, and similar rules. As a useful side effect, the same lineage and audit trails become regulator-ready evidence.

Self-serve BI. Superset, Lightdash, Metabase, Tableau, or Power BI all sit on top of the semantic layer. So the stack treats BI tools like any other consumer — same governance, same lineage, same metrics.

Operational decision systems. The reverse-ETL layer becomes a one-way valve from data to operations. Importantly, the policy layer makes sure decisions only flow where they should.

The point is simple. The stack is the investment. Specific data products are what you ship from it. Build the stack once, and all of these unlock.

Introducing Wasabi: our reference implementation

Wasabi is NeuralChainAI’s open-source modern data stack, instantiated in working code. It shows the full stack in a docker-compose project. You can clone it, run it on your laptop in 15 minutes, and use it as the blueprint for your own platform.

We built Wasabi to be pluggable at every layer. The shape is our opinion. The tools at each layer are not. Wasabi ships with one OSS default per layer. Then later phases add paid alternatives — Cube and dbt Semantic Layer, Open Policy Agent and Immuta, DataHub and Atlan, Elementary and Monte Carlo, Dagster and Airflow. Whichever stack fits your team, we can wire the same shape using your tools.

What ships in Phase 1

The walking skeleton ships first. Phase 1 includes:

Postgres with sample data, transformed by dbt Core
Cube as the semantic layer, with dbt Semantic Layer / MetricFlow joining in Phase 2 as a parallel option
Open Policy Agent for query-time governance
Dagster for orchestration
OpenLineage events flowing to Marquez
A production-grade MCP server that exposes the stack to Claude, Cursor, or any MCP client
Agent telemetry that captures latency, cost, policy decisions, and SQL for every query

This is the smallest end-to-end build that holds together. Working code exercises every layer. From here, every phase adds depth.

How the stack grows over time

Wasabi grows in chapters. Each phase adds depth to one or more layers. Importantly, every phase ships a working repo update plus a long-form post on the choices behind it.

Phase 2 — Governance depth: PII discovery with Microsoft Presidio, native masking on Snowflake, Immuta as paid policy alternative to OPA, dbt Semantic Layer joins Cube, audit evidence
Phase 3 — Catalog and metadata: Paid catalog through Atlan, glossary terms feeding agent context, lineage that the agent can read for “where did this number come from” questions
Phase 4 — Observability and quality: Monte Carlo as the paid alternative to Elementary, quality signals shown inline in answers
Phase 5 — Semantic and orchestration alternatives: Snowflake Semantic Views, Databricks Metric Views, SQLMesh, Airflow added as swappable picks
Phase 6 — Activation: Hightouch alongside a governance-aware OSS reverse-ETL pattern, BI handoff to Superset and Lightdash
Phase 7 — Vertical specialization: A HIPAA-anchored overlay for healthcare data products

Together, the phases tell the full story of how to grow a modern data platform into one that ships AI analysts, governed data sharing, embedded analytics, and regulated data products end-to-end.

What Wasabi is not

Some things this project is not.

Not a product. No SaaS. No hosted version. No paid tier. The reference stays open and free.

Not a competing semantic layer, catalog, or policy engine. Every part is an existing tool plugged into a stack that fits together. Our work is the fit, not the parts.

Not vendor-prescriptive. We chose specific tools for Phase 1 because we had to ship working code. However, those choices are not the argument. The shape is. So we expect to wire the same shape with whatever tools fit each client’s reality. Wasabi is built to support that.

Not a substitute for knowing your own platform. Wasabi shares our opinion on shape. By contrast, fitting it to your setup takes real work — calibrated to your data, your rules, your users, and your budget.

Frequently asked questions

What is governed agentic analytics?

Governed agentic analytics is the practice of building AI agents on top of company data so every query is correct, allowed, traced, and tracked for cost. We at NeuralChainAI believe teams should treat it as a data architecture choice across many layers — semantic, governance, observability, lineage, cost — rather than a one-vendor purchase.

How is a semantic layer different from a context layer for AI agents?

A semantic layer defines business metrics and dimensions — what “revenue” means in code. By contrast, a context layer is broader. It includes the semantic layer plus catalog metadata, lineage, quality signals, ownership, and unstructured business context for the agent at query time. The semantic layer serves both humans and agents. Meanwhile, the context layer is tuned for agent use.

Why does MCP alone not solve agentic analytics?

MCP is a transport protocol. So it standardizes how agents find and call tools. However, it does not make sure the data those tools return is governed, correct, or traced. We see MCP as needed plumbing but not enough on its own. The full stack flows through a governed semantic and policy layer to produce answers your team can stand behind.

Cube vs dbt Semantic Layer for AI agents — which should I pick?

It depends on your stack. Cube delivers sub-second latency and supports 25+ data sources including streaming engines and NoSQL databases, with native AI/MCP integrations. Meanwhile, dbt Labs released MetricFlow under Apache 2.0 in late 2025, making it a fully open-source semantic layer that integrates natively with dbt’s transformation workflow. We typically suggest Cube for embedded analytics, multi-source apps, or OLAP-grade speed. By contrast, dbt Semantic Layer fits teams already deep in dbt who want metric definitions next to transforms. Wasabi will support both as parallel picks starting in Phase 2. Invoice Fly Cube

What’s the difference between OPA and Immuta for AI agent governance?

Open Policy Agent is an open-source, code-first policy engine that works across many domains — app authorization, infra policy, and data access. By contrast, Immuta is a paid, data-specific policy platform with attribute-based access control, native Snowflake and Databricks Unity Catalog hooks, and dynamic enforcement at query time. Both fit the stack’s policy layer. So the right pick depends on whether you want max flexibility (OPA) or turnkey warehouse hooks (Immuta).

Which catalog should I use for agentic analytics — DataHub, Atlan, Alation, or OpenMetadata?

Each has a different sweet spot. DataHub and OpenMetadata are open-source, code-first, and best for engineer-heavy teams that want full control. Atlan, by contrast, is a paid catalog built for the modern data stack, with strong AI positioning and great dbt fit. Meanwhile, Alation is a more enterprise-grade paid option with deeper stewardship workflows, often used in regulated Fortune 500 settings. Wasabi ships with DataHub as the OSS default and Atlan as the paid reference. However, Alation, Collibra, and OpenMetadata can all slot into the stack based on what you already run.

Can I use Wasabi with my existing dbt project?

Yes. Wasabi consumes an existing dbt project as the transform layer. So you drop in your dbt models, point Cube (or dbt Semantic Layer in later phases) at them, and the rest of the stack wires up around them.

Does Wasabi work with Snowflake and Databricks?

Phase 1 ships with Postgres for local dev. Snowflake support arrives in Phase 2 alongside native masking demos. Meanwhile, Databricks Unity Catalog support arrives in Phase 5 alongside Databricks Metric Views as a semantic layer pick.

What you can do next

If you are a data platform leader mapping your roadmap, Wasabi is our blueprint. Walk through the ten layers. Then map each one against what you have today and what you’d need to build. The output is your end-to-end data strategy — for AI analysts, embedded analytics, governed sharing, or whichever data products you care about.

If you are an engineer building data products on the modern data stack, the patterns in Wasabi transfer directly. The MCP server is real. The policy enforcement is real. The lineage events are real. So use the patterns; don’t reinvent them.

If you are a vendor at one of the layers — semantic, catalog, governance, observability, orchestration — your tool can plug into Wasabi as a swappable pick. We’re building this in public partly because the stack helps every vendor whose tool fits in honestly. Reach out to NeuralChainAI to discuss.

If you are a team that wants help designing your data architecture — for AI analyst use, embedded analytics, governed sharing, or any other modern data product — that’s what NeuralChainAI does. We help teams turn the Wasabi shape into a roadmap that fits their tools — Snowflake or Databricks, Cube or MetricFlow, Atlan or DataHub, Immuta or OPA. Then we run the build alongside their team.

Reach out

If you are a data platform leader thinking about your data architecture, or an engineering lead turning that strategy into systems, we’d be glad to talk. We’ll walk through your stack and where Wasabi can shape the path forward. No pitch, no commitment — just a chat about what you’re building.

Reach out to NeuralChainAI with a short note about your stack and what you’re trying to build.

The Wasabi walking skeleton ships in the coming weeks. Meanwhile, subscribe to the NeuralChainAI blog so you hear the moment the repo goes live. Then follow NeuralChainAI on LinkedIn for build-in-public updates as each phase ships.

We at NeuralChainAI believe the modern data stack should be built on purpose, end-to-end, with every layer earning its place. Wasabi is our argument for what that looks like — and the open-source proof that we’re willing to back our argument with running code.

Wasabi is an open-source project by NeuralChainAI. Repository: github.com/neuralchainai/wasabi. For help designing your data architecture, contact NeuralChainAI.