DEV Community: Harshit Chouhan

MCP Is Not Enough: Why Enterprise AI Agents Need a Governed Semantic Layer

Harshit Chouhan — Wed, 02 Sep 2026 16:23:34 +0000

MCP solves the AI plumbing crisis flawlessly.

It also gives your agents a direct line to confidently wrong answers, and nothing in the protocol prevents that.

The protocol moves the request. It doesn't govern the truth.

MCP standardises how an agent reaches a tool. That problem is now genuinely solved — 10,000+ public MCP servers and roughly 97M SDK downloads a month settle the adoption question.

What MCP says nothing about:

Whether two agents on the same wire agree what revenue means
Whether the requester was entitled to ask
Whether the join the agent needed actually exists
How you reconstruct, months later, what ran and why

Connectivity without comprehension is a faster path to the same wrong number.

Two ways to build the server

	Expose the schema	Expose the semantics
Agent receives	Raw tables and columns	A resolved, typed intent surface
Meaning	Inferred by the model	Resolved against a semantic graph
Joins	Guessed	Proven, or the request fails
Permissions	Whatever the connection has	Compiled per person, per query
Build time	An afternoon	Longer — and the reason it ships
Audit	Connection logs	Question → SQL → policies → result

Same protocol. Completely different risk profile. Both look identical in a demo.

What the semantic layer adds behind MCP

The agent sends intent. The server resolves entities and metrics against a versioned graph, proves the join path, injects RBAC and ABAC predicates for the caller's identity, compiles dialect-perfect SQL, and returns a governed result with lineage.

Same question. Same answer. Every agent. Every time.

MCP is the wire. The semantic layer is the meaning. To build boardroom-ready AI you need both — and the wire is the easy half.

The full breakdown — the architecture behind an MCP server that enforces governance, with the request/response shape — is here:

👉 MCP Is Not Enough: Why Enterprise AI Agents Need a Governed Semantic Layer

Originally published at colrows.com/blogs/mcp-governed-semantic-layer

Self-Serve Analytics: Why Deterministic Governance is the Missing Link

Harshit Chouhan — Mon, 31 Aug 2026 15:12:47 +0000

Ten years of self-serve BI, and the analytics team is still the bottleneck.

We handed everyone a query tool and treated the semantics as somebody else's problem.

Self-serve relocated the queue, it didn't remove it

The promise was fewer tickets. What actually happened is the ticket changed shape. It used to say "please pull last quarter's revenue by region." Now it says "which of these four revenue fields is the real one?"

A business user doesn't need SQL. They need certainty that the number means what they think it means, and that they were allowed to pull it.

What the layer underneath has to provide

Requirement	Without it
One governed definition per concept, versioned	Four dashboards, four numbers, one long meeting
Access policy resolved per person at compile time	Duplicate datasets per audience, drifting apart
A refusal when the question is ambiguous	A plausible number nobody can defend
Lineage on every answer	"Where did this come from?" has no answer

The refusal row is counter-intuitive and it's the most important. A self-serve tool that always returns something is training your organisation to trust numbers it shouldn't.

What changes when you get it right

At Cipla, moving meaning into a governed layer produced:

8× increase in the number of people actually using data
>90% reduction in decision latency
80% drop in IT report requests
Campaign diagnosis that used to take days, resolved effectively instantly

None of that came from a better dashboard tool. It came from removing the interpretation step between a question and a trustworthy answer.

Give people a tool and you get more tickets. Give them governed meaning and you get self-serve.

The full breakdown — the architecture, the rollout sequence, and the governance model that makes self-serve safe — is here:

👉 Self-Serve Analytics: Why Deterministic Governance is the Missing Link

Originally published at colrows.com/blogs/self-serve-analytics-empowering-business-teams

The Semantic Control Plane: Deterministic Governance for AI

Harshit Chouhan — Wed, 26 Aug 2026 14:10:24 +0000

Most enterprise AI governance is broken by design.

Runtime filters, output classifiers, LLM-as-judge checks — they all share one fatal flaw. By the time they fire, the sensitive data has already left the warehouse.

You're not preventing a breach. You're documenting one.

Every runtime guardrail is a post-hoc annotation. The query ran. The rows moved. Something downstream then decided whether you were allowed to see them.

That is an audit finding waiting to be written, and no amount of classifier accuracy fixes the ordering problem.

Moving governance to compile time

The fix is architectural: attach policy to business concepts rather than to tables or endpoints, and evaluate it while the query is being built.

	Runtime governance	Compile-time governance
Policy attached to	Tables, endpoints, outputs	Entities, metrics, relationships
Fires	After execution	Before SQL is emitted
Unauthorised request	Returns filtered result	Fails to compile
Data movement	Already happened	Never happens
Audit artefact	A log line	The exact SQL plus the predicates applied

Attach a policy to NetRevenue and ChurnRisk and it travels with the concept — into every query, every tool, every agent, without being re-implemented per surface.

What a control plane has to do

Resolve intent against a typed, versioned semantic graph
Prove a join path exists — no path, no query
Inject RBAC, ABAC and row/column predicates per persona
Emit dialect-perfect SQL for the target engine
Record a point-in-time reproducible audit trail

Step 3 is the one people skip, and it's the one that makes the difference between an AI system you can ship into a regulated workflow and one that stays in pilot forever.

The agent never sees a table it wasn't entitled to — not because it behaved, but because the query was never compiled.

The full breakdown — the control plane architecture in detail, how policies compose across scopes, and what the audit output looks like — is here:

👉 The Semantic Control Plane: Deterministic Governance for AI

Originally published at colrows.com/blogs/semantic-control-plane

The Best Text-to-SQL Tools in 2026, Scored on Accuracy, Governance, and Reproducibility

Harshit Chouhan — Mon, 24 Aug 2026 16:04:15 +0000

Most text-to-SQL comparisons score features. Features are not the problem.

Score them on the only thing that matters — does the number come back right, and can you prove it?

The scoring criteria that separate the field

Criterion	Why it decides the outcome
Multi-table join accuracy	Single-table lookups tell you nothing
Behaviour under ambiguity	Ask, refuse, or silently guess?
Authorisation timing	Before execution, or filtered after?
Determinism	Same question twice, same answer?
Reproducibility	Can you rebuild a 6-month-old answer for an auditor?

Almost every tool in the category scores well on page one of a demo. The separation happens on the last three rows, and those are architectural — you cannot bolt determinism onto a probabilistic pipeline later.

The test that ends most evaluations

Ask the tool something that has no valid answer on your schema.

A tool that can't say "I don't know" will eventually tell your CFO something untrue with total confidence. That is worse than a tool that fails loudly, because nobody knows which answer was the bad one.

Run this evaluation on your own schema

Benchmark demos use clean schemas with sensible names. Yours has three tables called something like customer and only one of them is current.

A metric requiring a join across three tables, one with a near-duplicate
A time comparison where the fiscal calendar ≠ calendar year
A question two people are entitled to different answers to
The same question, asked an hour apart
Something unanswerable

Score every vendor on the same five. It takes an afternoon and the differences stop being marketing.

For reference: on real enterprise schemas, raw schema access scored 14.5% in our benchmark; compiled, governed context scored 98.2% with the same model.

The full breakdown — the scored comparison across the current field, with methodology and the cases where each tool loses — is here:

👉 The Best Text-to-SQL Tools in 2026, Scored on Accuracy, Governance, and Reproducibility

Originally published at colrows.com/blogs/best-text-to-sql-tools

dbt Semantic Layer Alternatives for Multi-Warehouse Estates (2026)

Harshit Chouhan — Wed, 19 Aug 2026 13:23:37 +0000

Most "dbt alternatives" lists are written by whoever wants to sell you the alternative.

Here's the version that starts by telling you when to keep dbt.

Keep dbt if

Your consumers are dashboards and analysts, not agents
Your metric set is reasonably stable
Your team already treats models as reviewed code
Someone owns the semantic YAML as part of their job

That is a real, common configuration and dbt serves it well. Switching would be churn for its own sake.

Start looking when

Signal	Why dbt strains
Agents become the main consumer	Coverage is limited to pre-defined metrics
Questions routinely fall outside the metric set	Each one becomes a pull request
Governance must be enforced in the query	dbt governs upstream, in the warehouse
Multi-warehouse estate	Cross-platform joins fall back to hand-written SQL
Definitions drift and nobody notices	No drift detection; staleness is silent

The multi-warehouse row is the most common trigger. Almost nobody's estate is on one platform — there's a warehouse, a lakehouse someone piloted, an operational Postgres, and a SaaS system that never got migrated.

The axis that matters

The useful question isn't feature parity. It's whether your semantic layer is a definition store or an execution layer.

A definition store answers "what is net revenue?" An execution layer answers "for this person, right now, across this estate, prove the join and return governed SQL."

Those are different products. Your next two years of AI roadmap decide which one you actually need — and the honest answer for many teams is: keep dbt for analytics engineering discipline, and put an execution layer above it for agent traffic. They are not mutually exclusive.

What to ask any alternative

Who maintains the model in year two — a person, or the system? If the answer is a person, you've bought dbt with different syntax.

The full breakdown — the full alternatives landscape, migration paths, and how to run a multi-warehouse evaluation — is here:

👉 dbt Semantic Layer Alternatives for Multi-Warehouse Estates (2026)

Originally published at colrows.com/blogs/dbt-semantic-layer-alternatives

Looker Pricing in 2026: What Google Publishes, What You Actually Pay

Harshit Chouhan — Wed, 12 Aug 2026 15:39:38 +0000

The Looker quote you receive is not the Looker bill you pay.

The licence covers the platform. LookML is where the budget quietly goes.

What's on the quote vs what lands

Line item	On the quote?	Notes
Platform / instance fee	Yes	The number people compare
Per-user tiers	Yes	Viewer vs Explorer vs Developer
LookML maintenance	No	An engineer's time, permanently
Warehouse compute	No	Billed by BigQuery/Snowflake, not Google
Re-modelling on schema change	No	Arrives as sprint work
Migration if you ever leave	No	Definitions are in LookML, not portable

The per-user tiers deserve attention: a "viewer" who filters a dashboard can reclassify as an explorer. Adoption success shows up as a licensing surprise.

The real cost driver

LookML was the right instinct — put metric definitions in reviewed code instead of scattering them across dashboards. Consistency improved and stayed improved.

The cost is that coverage equals authoring effort. Every new concept is a pull request. Every schema change is maintenance debt. Every question outside the model is a ticket, and the ticket is the actual user experience.

That is fine when the consumer is a human analyst who can wait two days. It stops working when the consumer is an AI agent asking things nobody pre-modelled, at machine rates.

How to build an honest comparison

Price three things, not one:

Licence and platform fee
The engineer who keeps the model current — the salary line nobody puts in the TCO
The latency between a business question and a trustworthy answer

The third is the one with real money in it. Cipla cut decision latency by over 90% and IT report requests by 80% — neither number appears on any BI invoice.

The full breakdown — current published figures, how the tiers actually reclassify users, and a like-for-like TCO model — is here:

👉 Looker Pricing in 2026: What Google Publishes, What You Actually Pay

Originally published at colrows.com/blogs/looker-pricing

dbt Semantic Layer vs Cube vs AtScale: Choosing an Enterprise Semantic Layer

Harshit Chouhan — Mon, 10 Aug 2026 15:55:42 +0000

Three semantic layers, three architectures, three very different bills.

All three will define what a metric means. None of them proves an AI agent is allowed to run it.

Quick orientation

	dbt Semantic Layer	Cube	AtScale
Core idea	Metrics as version-controlled code	Headless API in front of metrics	OLAP-style aggregate acceleration
Strongest when	You want engineering discipline	Many apps consume the same numbers	Heavy, stable aggregate workloads
Modelling	Hand-authored YAML	Hand-authored data model	Hand-authored cubes
Cost driver	Plan tier + query volume	Pre-aggregation builds + compute	Quote-based licence + compute
Governance	Upstream, in the warehouse	In front of the API	On the cube

Each is competent at what it was built for. If your consumers are dashboards and analysts, any of the three will serve you.

The question none of them answers

An agent doesn't arrive with a metric name. It arrives with an intent in English and has to work out which entities, which grain, which joins, and whether it's entitled to any of it.

That exposes two gaps every one of these shares:

Undefined intent has no answer. Coverage is whatever someone remembered to model. Business questions don't respect that boundary.
Authorisation is checked around the query, not inside it. A filter applied after execution means the data already moved.

What to actually evaluate on

Ignore feature matrices and score these five:

Answer a question nobody modelled, on your schema
Show why one join path was chosen over two others
Same question, two users with different entitlements — show both SQL statements
Ask something ambiguous. Refusal or guess?
Reproduce a number from six months ago with the definitions then in force

Most evaluations stop at 1. Numbers 3 and 5 are the ones that decide whether the thing ships in a regulated business.

The full breakdown — architecture-by-architecture comparison, cost profiles, and the migration implications of each — is here:

👉 dbt Semantic Layer vs Cube vs AtScale: Choosing an Enterprise Semantic Layer

Originally published at colrows.com/blogs/dbt-semantic-layer-vs-cube-vs-atscale

The Text-to-SQL Accuracy Cliff: Why Deterministic Compilers Beat LLM Guessing

Harshit Chouhan — Wed, 05 Aug 2026 14:18:33 +0000

Every text-to-SQL demo is flawless. Every production rollout is a coin flip.

The model didn't get worse between the demo and your warehouse. Your schema crossed a threshold it cannot reason past.

Accuracy doesn't decay. It collapses.

The intuition most teams carry is that accuracy degrades gradually as queries get harder. It doesn't. It holds, holds, holds — then falls off a cliff the moment a question needs a join the model has to guess at.

On our own enterprise benchmark, raw schema access scored 14.5%. The same model, given compiled and governed context, scored 98.2%.

Same model. Same questions. The only variable was the context it ran on.

The three gaps that create the cliff

Gap	What the model sees	What it needs
Naming	`cust_t`, `cust_type`, `customer_seg`	One typed entity with synonyms
Joins	200 tables, 3 plausible paths	A proven path, or a hard failure
Rules	No sign of the fiscal calendar	Grain and filters attached to the metric

Any one of these produces syntactically perfect SQL that returns the wrong number. That is the dangerous failure — a query that errors gets fixed, a query that returns 8% instead of 12% gets pasted into a board deck.

Why "temperature: 0" is not determinism

Setting temperature to zero makes sampling greedy, not correct. Greedy decoding over an ambiguous schema reliably picks the same wrong join every time. You have traded variance for consistent error, which is worse — now it looks trustworthy.

Determinism has to come from architecture, not decoding parameters:

The LLM parses language into a typed intent
The semantic graph — not the model — resolves entities, metrics and grain
The planner proves a join path exists, or compilation fails
Policy predicates are injected before SQL is emitted

Ambiguity produces a refusal instead of a guess. That is the whole difference.

The full breakdown — what the famous benchmark numbers actually measure, what failure looks like in real SQL, what a wrong number costs, and how every serious vendor has converged on the same answer — is here:

👉 The Text-to-SQL Accuracy Cliff: Why Deterministic Compilers Beat LLM Guessing

Originally published at colrows.com/blogs/text-to-sql-accuracy-cliff

RAG vs. Semantic Layer: Why AI Needs Deterministic Governance

Harshit Chouhan — Mon, 03 Aug 2026 18:09:55 +0000

Half the market is arguing about whether RAG or a semantic layer is the right foundation for enterprise AI.

They are not competing. They answer different questions, and most teams need both.

Two shapes of question

Every question an agent receives breaks into one of two forms:

"What did we say about X?" — lives in contracts, policies, tickets, docs. Unstructured. RAG was built for this.
"What is true about X?" — lives in your warehouse and governed metrics. Structured. A semantic layer was built for this.

Treating them as rivals is how teams end up with a system that can quote the pricing policy but cannot tell you this quarter's realised price.

Where each one breaks

	RAG	Semantic layer
Good at	Retrieving relevant prose	Resolving definitions and joins
Fails on	Aggregation, math, current state	Anything not modelled as data
Permissions	Flattened at ingest, rebuilt at query time	Compiled per person, per query
Answer stability	Varies with retrieval ranking	Identical by construction
Audit story	Cites a chunk	Reproduces the exact SQL

The permissions row is the one that ends pilots. A retrieval index that ingested everything has, by construction, assembled your most sensitive object — and reconstructing entitlement at query time is guesswork.

The layer that actually decides

Neither a document chunk nor a metric definition is worth much until something compiles it into a governed query and runs it.

That is the piece most architectures are missing: intent → context resolution → constrained planning → governed execution. RAG can feed the first step. It cannot perform the last three.

Point an agent at raw tables and the best models score in the low teens on real enterprise data. Give the same model compiled, governed context and it clears the high nineties. The retrieval quality was never the bottleneck.

The full breakdown — the precise division of labour, why hybrid architectures win, and how compile-time governance closes the gap RAG cannot — is here:

👉 RAG vs. Semantic Layer: Why AI Needs Deterministic Governance

Originally published at colrows.com/blogs/rag-vs-semantic-layer