DEV Community: Harshit Chouhan

MCP for Business Intelligence: How AI Agents Should Query Enterprise Data

Harshit Chouhan — Wed, 23 Sep 2026 14:41:48 +0000

Wiring an agent straight to your warehouse over MCP takes about an afternoon.

Explaining to your auditor what it did takes considerably longer.

The design decision hiding inside a config file

MCP makes the connection trivial, which is exactly why what sits behind the server matters more now, not less. There are two ways to build it and they look identical from the outside.

Expose the tables. The agent gets raw schema access and infers meaning. Fast to build, impossible to govern, and every answer is a guess with good grammar.

Expose the semantics. The agent sends intent. The server resolves entities against a typed graph, proves the join path, applies policy for the caller's identity, compiles SQL, and returns a governed result with lineage.

What that changes in practice

	Schema-exposed	Semantics-exposed
`revenue` means	Whatever column matched	One versioned definition
Join across 3 tables	Model picks a path	Path proven or request fails
Two callers, different rights	Same rows	Different SQL, correct for each
Auditor asks "what ran?"	Connection logs	Question → SQL → predicates → result

The BI-specific part

Business intelligence has a property most agent use cases don't: the output feeds decisions that get defended later. A dashboard number that's wrong gets corrected. A number an agent surfaced into a board pack and nobody can reconstruct is a different category of problem.

So for BI over MCP the requirement isn't "can the agent query" — it's "can we reproduce this answer, with the definitions that were in force, six months from now."

That's not a protocol feature. It's what the layer behind the protocol does.

The full breakdown — the server architecture, tool surface design, and how governed results are shaped — is here:

👉 MCP for Business Intelligence: How AI Agents Should Query Enterprise Data

Originally published at colrows.com/blogs/mcp-business-intelligence

Conversational BI Tools in 2026, Scored on Governance, Determinism, and Reach

Harshit Chouhan — Wed, 16 Sep 2026 15:14:57 +0000

Every BI vendor now ships a chat box. Almost none will tell you their accuracy on a real schema.

Here's how to score them on the questions that actually break things.

The demo question vs the real ones

The demo is always single-table: "show me revenue by region." Every tool passes.

These are the ones your business actually asks:

A metric requiring a join across three tables, one of which has a near-duplicate
A time comparison where the fiscal calendar isn't the calendar year
A question two people are entitled to different answers to
The same question, asked twice, an hour apart
A question with no valid answer

What each question reveals

Test	What a failure tells you
Multi-table join	The tool guesses join paths
Fiscal calendar	Business rules aren't in the model
Two entitlements	Governance is applied after execution
Repeat question	The pipeline is probabilistic end to end
Unanswerable	It will invent rather than refuse

Number five separates the field more than the other four combined. A tool that cannot say "I don't know" is a liability in any regulated workflow, because you can never identify which answer was the fabricated one.

The structural read

Conversational BI splits into two architectures dressed the same way. One infers meaning from a dataset model at query time. The other resolves intent against a typed semantic graph, proves the join, applies policy, then compiles SQL.

The first is faster to buy. The second is the only one that survives an audit — and on real enterprise schemas the accuracy gap between them is not marginal, it's the difference between the low teens and the high nineties.

The full breakdown — the scored comparison across the current field, with the governance and determinism criteria applied consistently — is here:

👉 Conversational BI Tools in 2026, Scored on Governance, Determinism, and Reach

Originally published at colrows.com/blogs/conversational-bi-tools

Generative BI (GenBI): What It Is, and the Tools That Do It Well in 2026

Harshit Chouhan — Mon, 14 Sep 2026 15:16:50 +0000

GenBI is the year's most oversubscribed label. Everyone claims it; almost nobody defines it.

Here's the line that separates a real one from a chat box bolted onto a dashboard.

What generative BI should mean

The system generates the analysis — the query, the visualisation, and the explanation — from intent alone. Not selection from pre-built content. Generation.

Most products labelled GenBI generate one of those three and hard-code the other two.

The four test questions

Question	Weak GenBI	Real GenBI
Does it generate the query?	Picks from saved content	Compiles from intent
Can it answer something unmodelled?	No	Yes, or refuses explicitly
Does the explanation describe the executed logic?	Narrates the chart	Describes the actual SQL and joins
What happens when it can't answer?	Produces something anyway	Says so

Row three is the quiet one. An "explanation" that describes what the chart shows is a caption. An explanation that tells you which tables were joined, which filters applied, and which policy predicates were injected is an audit artefact.

The gap is the layer underneath

The distance between "generates SQL" and "generates trustworthy analysis" is exactly the semantic layer.

Without one, generation is pattern-matching against column names. With one, the model handles language and the graph handles meaning: entities and metrics resolved, join path proven, policy compiled in, dialect-perfect SQL emitted.

The category is real and the good implementations are genuinely useful. Just evaluate on whether the thing generating your analysis has any structural knowledge of your business — or is inferring it, fluently, every single time.

The full breakdown — what GenBI means precisely, the current landscape, and who clears the bar — is here:

👉 Generative BI (GenBI): What It Is, and the Tools That Do It Well in 2026

Originally published at colrows.com/blogs/generative-bi-tools

Token Cost: Why Brittle Semantic Layers Bleed Capital

Harshit Chouhan — Wed, 09 Sep 2026 16:45:07 +0000

If your agent's token spend keeps climbing, the model isn't the problem.

You are paying, per query, to re-explain your schema to something that should already know it.

Where the money actually goes

Cost	Cause	Fix
Schema in every prompt	No resolved context layer	Resolve against the graph, not the prompt
Retry loops	Generated SQL fails or returns empty	Prove the join before execution
Multi-turn clarification	Ambiguity handled in conversation	Typed intent resolves it in one pass
Bigger model tier	Bought to compensate for missing context	Fix the context instead
Warehouse compute	Failed and re-run queries	Fewer, correct queries

Notice that four of the five are the same root cause wearing different clothes: the model is being asked to do work that belongs upstream.

The arithmetic

Stuff a schema dump into the context window and every question re-pays for it. Add retries and you pay several times per question. Then someone proposes a larger model to improve accuracy, and the per-token price goes up on a volume that was already inflated.

Teams read that curve as "AI is expensive." It isn't. Re-deriving meaning at inference time is expensive.

Compiled context inverts the economics

When resolution happens against a semantic graph instead of inside the prompt, the model receives a small typed intent rather than your entire warehouse. Fewer tokens in, fewer retries, smaller model sufficient.

The bill drops and accuracy rises for the same reason — the work moved to the layer that can do it deterministically.

That is the part worth internalising: token cost and accuracy are not a trade-off you have to manage. They are both downstream of the same architectural decision.

The full breakdown — the cost model, worked examples of prompt-side vs compile-side resolution, and where the savings actually land — is here:

👉 Token Cost: Why Brittle Semantic Layers Bleed Capital

Originally published at colrows.com/blogs/token-cost-hidden-tax-semantic-layer

Semantic Layer for BigQuery: Governed, Deterministic SQL for Your AI Agents

Harshit Chouhan — Mon, 07 Sep 2026 16:58:21 +0000

BigQuery will happily execute whatever SQL your agent invents.

That is the feature and the failure mode, in one sentence.

The engine has no opinion on meaning

BigQuery's job is execution and it is excellent at it — petabyte scans, sub-second aggregates, separated storage and compute. It has no view on whether the query it just ran meant what the asker intended.

Point an agent at it directly and you get fast, expensive, confidently wrong answers.

What the missing layer has to supply

Need	Why BigQuery alone doesn't cover it
Resolved definitions	Column names are not business meaning
Proven join paths	Including across datasets and outside BigQuery
Compile-time policy	Authorised views are per-view, not per-intent
Dialect-perfect GoogleSQL	Generic SQL loses BigQuery-specific semantics
Slot cost control	An agent retry loop is a billing event

The cross-dataset row matters more than it looks. Authorised views and row-level policies work well inside BigQuery — but they stop at the BigQuery boundary, and your estate almost certainly doesn't.

The shape that works

Intent → context resolution → constrained planning → governed execution.

An agent sends intent. The semantic graph resolves which entities and metrics are involved, at which grain. The planner proves a join path exists — and fails compilation if it doesn't, rather than improvising one. RBAC and ABAC predicates are injected for the caller. Only then is GoogleSQL emitted and run.

Get that right and BigQuery becomes a very strong execution engine for agent workloads. Skip it and you have built a high-throughput way to be wrong at scale, with a slot bill to match.

The full breakdown — the reference architecture, GoogleSQL generation specifics, and how policy composes with authorised views — is here:

👉 Semantic Layer for BigQuery: Governed, Deterministic SQL for Your AI Agents

Originally published at colrows.com/blogs/semantic-layer-for-bigquery

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