DEV Community: Mayank Mudgal

ThoughtSpot Alternatives: Why AI Agents Need a Semantic Compiler

Mayank Mudgal — Thu, 03 Sep 2026 06:05:58 +0000

ThoughtSpot bet that people want to search their data. They were right, and it worked.

Then the primary user stopped being a person.

Search was a genuinely good idea

Search-first BI made analytics approachable for business users, and the indexing engineering behind it was serious. For analyst-led exploration it still holds up.

Agents don't search — they resolve

Need	Search ranking	Semantic compiler
Which definition applies	Top-ranked candidate	The authoritative one, versioned
Which join to use	Relevance score	Proven path, or failure
Authorisation	Around the content	Injected into the query
Determinism	Ranking can shift	Identical by construction
Audit	Cites the worksheet	Reproduces the SQL

"Best match" is a reasonable standard for a human exploring. It isn't a standard of proof, and every row above is downstream of that difference.

The modelling burden nobody mentions

Search quality depends on a curated worksheet layer someone maintains. That's where most deployments quietly stall — not on user adoption, but on the sustained modelling effort that keeps search results correct as schemas move.

Ask any vendor in this category: does the system's knowledge of my business grow because someone curated it, or because it read my sources and maintains itself?

When ThoughtSpot remains right

Analysts exploring, curiosity-driven work, a team that owns the worksheet layer. Good fit, real value.

The trigger to look elsewhere is when the output starts feeding automated decisions or regulated workflows — because then ranking isn't enough and you need proof.

The full breakdown — the scored alternatives comparison, the modelling cost analysis, and the agent-native requirements — is here:

👉 ThoughtSpot Alternatives: Why AI Agents Need a Semantic Compiler

Originally published at colrows.com/blogs/thoughtspot-alternatives

The ROI of a Company Brain: What the Evidence Actually Shows Executives

Mayank Mudgal — Tue, 01 Sep 2026 15:43:30 +0000

Every AI business case I see is built on a vendor's ROI calculator.

Here's what the numbers look like when they come from deployments instead.

Three patterns that hold up

Decision latency collapses before headcount changes. At Cipla, decision latency fell over 90% and data adoption rose 8×. The win was speed, not savings — and it arrived first.

The IT burden drops as a second-order effect. An 80% fall in report requests wasn't the goal. It happened because people stopped needing a human to interpret data for them.

Diagnosis time is where the outsized numbers live. Campaign diagnosis went from days to effectively instant — roughly a 1000× improvement — because the causal path was already modelled rather than reconstructed by an analyst each time.

The pattern across deployments

Organisation	Result
Cipla (pharma)	8× data adoption · >90% lower decision latency · 80% fewer IT report requests
SSP Group (travel retail)	40% less data-management overhead · 3× faster issue resolution
Confidential ARC (BFSI)	>95% lower evaluation cycle time · 100% regulatory coverage

What this says about how to budget

ROI doesn't come from replacing analysts. It comes from removing the wait between a question and a trustworthy answer.

That ordering matters for the business case. Fund the layer that makes answers trustworthy and the productivity numbers follow. Fund the productivity tool first and you get a pilot, because nobody acts on numbers they can't defend.

The number to put in the model

Not headcount saved. Decision latency — how long between a question being asked and a defensible answer existing. It's measurable today, it's usually embarrassing, and it's the variable that actually moves.

The full evidence review — the deployment data, the methodology behind each figure, and how to build the business case — is here:

👉 The ROI of a Company Brain: What the Evidence Actually Shows Executives

Originally published at colrows.com/blogs/company-brain-roi-evidence-for-executives

Wren AI Alternatives: When Open-Source GenBI Needs Production Governance

Mayank Mudgal — Tue, 01 Sep 2026 15:40:32 +0000

Wren AI is the most credible open-source answer to conversational BI right now.

It's also the fastest way to learn that the hard part was never the chat interface.

Why open source is the right pilot choice

No procurement, full visibility into behaviour, easy to prove or kill the concept. For validating that your users actually want this, it's hard to beat.

Where production changes the calculation

Concern	Open source reality
Semantic modelling	Yours to author and maintain, indefinitely
Governance	Integrates with your stack rather than enforcing in-query
Multi-tenant isolation	Your engineering problem
Audit trails	Your engineering problem
Accuracy ceiling	Plateaus at whatever modelling effort you sustain
Drift detection	Not included

None of that is a criticism — it's what open source is. The question is whether your team wants to own a semantic layer as a product, or consume one as infrastructure.

The two-year test

Ask who authors the semantic model in year two, after the engineer who set it up has moved to another team.

If the answer is "we'll rotate it," you've committed to permanent maintenance with no owner. That's the pattern that turns a successful pilot into a stalled deployment — not a technical failure, just entropy.

What to compare on

Who maintains the model as schemas change — a person, or the system?
Is authorisation proven pre-execution, or filtered after?
Is the join path proven, or inferred?
Can you reproduce a historical answer with the definitions then in force?

Wren scores honestly on all four; you just need to know that three of them become your backlog.

The full breakdown — the scored comparison, the build-vs-consume framing, and what production hardening involves — is here:

👉 Wren AI Alternatives: When Open-Source GenBI Needs Production Governance

Originally published at colrows.com/blogs/wren-ai-alternatives

Cortex Analyst Alternatives: Why Your Company Needs More Than Snowflake's Agentic Analyst

Mayank Mudgal — Thu, 27 Aug 2026 15:01:11 +0000

Cortex Analyst is a good product with one hard boundary: it ends where Snowflake ends.

Most enterprises find that boundary about three weeks in.

When it's the right answer

Everything you care about is in Snowflake, and someone maintains the semantic model file. That's a real configuration, it's already in your bill, and the integration depth is genuine.

When the evaluation starts

Signal	Why Cortex strains
Data across Snowflake + lakehouse + operational systems	Scope stops at Snowflake
Questions needing cross-boundary joins	Falls back to hand-written SQL
Governance must be consistent everywhere	Snowflake RBAC covers Snowflake
No owner for the semantic model file	Accuracy tracks a file nobody maintains
Agents asking unmodelled questions	Improvises rather than refusing

The last row deserves emphasis. Warehouse-native assistants generally don't distinguish "I have no basis for this" from "here's a plausible join" — so the failure is silent.

Two categories of alternative

Other warehouse-native assistants — Genie, Power BI Copilot and similar. Different platform, identical architecture, identical boundary. Switching gets you a different logo and the same ceiling.

Cross-estate semantic layers — resolve intent against a graph spanning every source, prove the join path regardless of which engine holds the tables, compile policy uniformly, and emit dialect-perfect SQL per target.

Only the second category answers cross-platform questions without someone hand-writing the join underneath.

The question to bring to any demo

"Show me a question that spans Snowflake and something that isn't Snowflake." It's a short conversation, and it's the one that matters.

The full breakdown — the scored alternatives comparison, the multi-platform architecture, and migration considerations — is here:

👉 Cortex Analyst Alternatives: Why Your Company Needs More Than Snowflake's Agentic Analyst

Originally published at colrows.com/blogs/cortex-analyst-alternatives

Company Brain Security: Deterministic Governance for Enterprise AI

Mayank Mudgal — Tue, 25 Aug 2026 17:58:07 +0000

Every company brain demo ends with "and it knows everything about your business."

That's the pitch. To a CISO, it's also the entire objection.

Why the objection is correct

A system that ingests every document, ticket, contract and table has, by construction, assembled the most sensitive object in the company. Then you point an LLM at it and expose it via chat.

The security question isn't paranoia. It's the deployment blocker, and it's usually raised too late.

The four questions that decide whether it ships

Question	Bad answer	Good answer
Does the index respect source permissions?	Flattened at ingest	Entitlement preserved per concept
Two users, same question — same answer?	Yes	No, and correctly different
When is entitlement evaluated?	Per corpus, at build	Per query, at compile time
Can you prove a specific person could see a specific answer?	Access logs	The SQL with predicates inline

Row two is the sharpest test. If two people with different clearances get identical answers, entitlement was lost somewhere in the pipeline — and "we filter the response" means the retrieval already surfaced it internally.

Why retrieval architectures struggle here

Embeddings don't carry ACLs. When you flatten a corpus into vectors, source permissions are metadata at best, and reconstructing them at query time is approximate by nature.

Compile-time governance inverts the order: policy is evaluated as part of resolving the question, so an unauthorised answer is never assembled. Nothing to filter, because nothing was retrieved.

What to require

Policy attached to concepts, not documents. RBAC plus ABAC plus row and column predicates injected before execution. De-identified resolution paths for aggregate questions. And a point-in-time reproducible audit trail — which your annual assessment needs anyway.

The full breakdown — the security architecture, the privacy model, and how compile-time governance handles unstructured sources — is here:

👉 Company Brain Security: Deterministic Governance for Enterprise AI

Originally published at colrows.com/blogs/company-brain-security-privacy

Cube Alternatives: When a Headless Semantic Layer Stops Fitting Your AI Agents

Mayank Mudgal — Thu, 20 Aug 2026 17:11:26 +0000

Teams don't leave Cube because of Cube. They leave because the consumer changed.

An API built for applications turns out to be the wrong shape for an agent.

Cube's model is clean

Define a metric once, serve it everywhere over an API. For multi-app estates where several front-ends need the same numbers, that holds up well and the caching story is genuinely good.

Where the pressure appears

An agent can't name the metric it needs. It arrives with intent and has to work out entities, grain, joins and permissions on the fly. An API contract doesn't help with any of that — it assumes the caller already knows what to ask for.

Question	Headless API	Compiled layer
Resolves arbitrary intent?	No — pre-defined metrics only	Yes
Join path	Modelled by hand	Proven at compile time
Governance	In front of the API	Injected into the SQL
Model upkeep	A person	The system, with drift detection
Undefined question	404, effectively	Resolved or explicitly refused

The four things to compare on

Does the layer resolve arbitrary intent, or only pre-modelled metrics?
Is the join path proven, or assumed?
Is governance in front of the API, or compiled into the query?
Who maintains definitions as the schema drifts?

Question four is the cost question in disguise. Pre-aggregation maintenance and data-model authoring are both engineering time, and neither appears on the invoice you're comparing.

When to keep Cube

Many applications, stable metric set, humans or code as consumers. That's the configuration it was designed for and there's no reason to move.

The trigger to look elsewhere is agents becoming the primary caller — because then coverage stops being a modelling exercise and starts being the bottleneck.

The full breakdown — the scored alternatives comparison, migration considerations, and the cost model — is here:

👉 Cube Alternatives: When a Headless Semantic Layer Stops Fitting Your AI Agents

Originally published at colrows.com/blogs/cube-alternatives

Snowflake Cortex Analyst vs Databricks Genie: Where Warehouse-Native AI Stops

Mayank Mudgal — Tue, 18 Aug 2026 15:01:11 +0000

Both promise your business users can simply ask the warehouse a question.

Both quietly require someone to hand-curate the context before that works.

Having run both against real enterprise schemas

	Cortex Analyst	Databricks Genie
Context artefact	Hand-authored semantic model file	Curated Space + example queries
Strong when	Inside Snowflake, file well-written	Inside Databricks, Space well-curated
Accuracy tracks	Quality of that YAML	Quality of that curation
Outside the curation	Degrades, often silently	Degrades, often silently
Cross-platform	No	No
Join proof	No — inferred	No — inferred
Governance	Snowflake RBAC around the query	Unity Catalog around the query

The honest scorecard: both are good implementations of the same idea, and both externalise the hard part back to you. The curation is the product.

What that means practically

Your evaluation isn't really of the tool. It's of your organisation's sustained capacity to author and maintain context files — a task with no natural owner and no visible reward.

When the question falls outside what was curated, you get a confident answer built on a guessed join. Nothing in the output signals that boundary was crossed.

Neither is wrong for a single-platform shop

If your estate genuinely lives on one platform and someone owns the context artefact, either will serve you well and it's already in the bill.

Both stop at the platform boundary, and neither proves the join path before executing. Those two limits are architectural — they're the reason a cross-estate compiled layer exists, not a feature gap that will be closed in the next release.

The full scorecard — the head-to-head with methodology, pricing implications, and where each stops — is here:

👉 Snowflake Cortex Analyst vs Databricks Genie: Where Warehouse-Native AI Stops

Originally published at colrows.com/blogs/cortex-analyst-vs-genie

Deterministic vs. Probabilistic Text-to-SQL: Why Accuracy Matters

Mayank Mudgal — Mon, 17 Aug 2026 14:48:59 +0000

Ask the same question twice and get two different numbers.

That's not a bug you can patch. It's the architecture telling you what it is.

Variance isn't a tuning problem

Probabilistic systems sample. Sampling means variance. Variance in a marketing subject line is fine; variance in a regulatory filing is a finding.

And setting temperature: 0 doesn't fix it — greedy decoding over an ambiguous schema reliably picks the same wrong join every time. You've traded variance for consistent error, which is worse, because now it looks reliable.

What deterministic actually means here

Not that the model stops being probabilistic. That the model never decides anything that matters.

Decision	Probabilistic design	Deterministic design
Language → intent	Model	Model
Which entity / metric	Model guesses	Semantic graph resolves
Which join path	Model guesses	Planner proves
Authorisation	Post-filter	Policy engine, at compile time
SQL emission	Model writes	Compiler emits

Four of the five decisions move out of the model. What's left is the one thing an LLM is genuinely good at: parsing natural language into structure.

The consequences that follow

Same question, same graph version, same answer — every time
Ambiguity produces a refusal, not a guess
The answer is reproducible point-in-time, which is what auditors need
Results are cacheable and reviewable, because they're stable

Why it shows in the numbers

On real enterprise schemas, raw schema access scored 14.5% in our benchmark. The same model with compiled, governed context scored 98.2%.

That's not a better model. That's removing every point at which the model had to guess.

The full breakdown — why "deterministic settings" aren't deterministic, the architectural split, and the benchmark methodology — is here:

👉 Deterministic vs. Probabilistic Text-to-SQL: Why Accuracy Matters

Originally published at colrows.com/blogs/deterministic-vs-probabilistic-text-to-sql

From Copilots to Autonomous Companies: Building AI-Native Operations

Mayank Mudgal — Thu, 13 Aug 2026 17:55:19 +0000

A copilot that's wrong 5% of the time is a productivity tool.

A system that acts on its own and is wrong 5% of the time is a liability.

That single distinction explains the plateau

Most enterprises are stuck at copilot, and it isn't a capability problem. The human in the loop isn't there for speed — they're there to absorb the error rate.

Remove them and the error rate has to be structurally controlled, not statistically improved.

What autonomy actually requires

Requirement	Copilot	Autonomous
Wrong answers	Caught by the user	Must be impossible, not unlikely
Ambiguity	User clarifies	System must refuse
Authorisation	User's own session	Proven per action, per identity
Traceability	Rarely needed	Every action, reproducible
Failure mode	Annoying	Reportable

The second row is the one teams underestimate. A system that guesses when uncertain is fine with a human reviewing it and unacceptable without one. Refusal has to be a first-class outcome.

Probabilistic systems can't offer this

Sampling produces variance. Variance in a draft email is fine; variance in a ledger entry is a finding. You cannot get to structural correctness by tuning temperature — the guarantee has to come from architecture.

A compiled path can offer it: intent resolved against a typed graph, join path proven or compilation failed, policy injected before execution, audit emitted automatically. The query either satisfies every constraint or it doesn't run.

The actual path

Not a better model. A layer that makes being wrong impossible rather than improbable — and then removing the human from the loop becomes a decision rather than a gamble.

The full breakdown — the operating model shift, what changes organisationally, and the architecture that supports it — is here:

👉 From Copilots to Autonomous Companies: Building AI-Native Operations

Originally published at colrows.com/blogs/from-copilots-to-autonomous-companies-ai-native-operations

The Best Semantic Layer for AI Agents in 2026: A Buyer's Guide

Mayank Mudgal — Tue, 11 Aug 2026 15:42:04 +0000

Gartner expects 70% of enterprises to deploy a semantic layer by 2027. The debate about whether is over.

The sharper reality: most will pick the wrong architecture, and won't find out for eighteen months.

Three structural categories

	Warehouse-native	Tool-centric	Cross-estate substrate
Examples	Snowflake Semantic Views, Databricks Metric Views	LookML, dbt, Cube	Compiled semantic layer
Scope	One platform	One BI ecosystem	Whole estate
Modelling	Hand-authored	Hand-authored	Generated + confirmed
Governance	Platform-native	Around the tool	Compiled into every query
Agent-ready	Within the platform	Within modelled metrics	Arbitrary intent

Picking between these isn't a routine tooling upgrade. It's a fork that determines what your AI roadmap can do for the next five years.

The four questions that separate a 2026 buyer from a 2021 buyer

A 2021 buyer asked about dashboard consistency, modelling language, performance and cost. Those still matter. These four decide the outcome now:

Can it answer a question nobody modelled in advance?
Is the join path proven, or ranked?
Is entitlement enforced before execution, per person?
Can you reproduce a specific answer six months later with the definitions then in force?

Why "almost right" is expensive

Eighteen months into the wrong architecture you have definitions, dashboards, trained users and integrations built on it — and the limitation you hit is structural, not a missing feature. There's no upgrade path from "designed for known questions" to "handles arbitrary intent."

That asymmetry is the real argument for evaluating on the four questions above rather than on feature parity.

The full buyer's guide — the 12-point evaluation framework, how each category scores, and how to run the evaluation in practice — is here:

👉 The Best Semantic Layer for AI Agents in 2026: A Buyer's Guide

Originally published at colrows.com/guides/best-semantic-layer-for-ai-agents-2026

How to Build an MCP Semantic Layer Server (Architecture, Code, and the No-Rip-and-Replace Case)

Mayank Mudgal — Thu, 06 Aug 2026 13:44:30 +0000

3 agent frameworks. 4 data sources. 12 brittle connectors.

Then someone renames a column and three agents break at once. MCP fixes the wiring — but the wiring was the easy part.

What an MCP semantic layer server actually exposes

The design decision is what your tool surface represents. Expose tables and every agent infers meaning independently. Expose semantics and they all compile through the same graph.

A governed server exposes something closer to:

Tool	Returns
`list_concepts`	Typed entities and metrics the caller may see
`describe_concept`	Definition, grain, filters, allowed dimensions
`resolve_intent`	A typed plan — or a refusal with the reason
`execute`	Governed result + the SQL + predicates applied

Notice there's no run_sql. That's deliberate — the moment you expose arbitrary SQL execution, every governance guarantee becomes advisory.

The request path

Intent → context resolution → constrained planning → governed execution.

Agent sends intent plus caller identity
Server resolves concepts against the versioned semantic graph
Planner proves a join path — no path, compilation fails
RBAC and ABAC predicates injected for that identity
Dialect-perfect SQL emitted and executed
Result returned with lineage and an audit record

The no-rip-and-replace part

This sits above your warehouse, not instead of it. Snowflake, Databricks, BigQuery and Postgres stay where they are; the layer reads your existing catalogs and BI models to build the graph, then compiles down to each engine's dialect.

The most common objection is migration fatigue — teams have spent millions consolidating and won't move again. They don't have to. Additive layers are the only ones that get deployed.

And because MCP and REST can front the same compiled core, switching protocols later never means re-proving your governance.

The full breakdown — the full architecture, code for the server, the tool schemas, and the integration path — is here:

👉 How to Build an MCP Semantic Layer Server (Architecture, Code, and the No-Rip-and-Replace Case)

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

Company Brain for Enterprise AI: Why the Data Layer Decides Everything

Mayank Mudgal — Tue, 04 Aug 2026 14:58:12 +0000

When your best people leave, everything they knew leaves with them. The pricing exceptions. The churn playbook. Why Q3 really dipped.

What's left is scattered across wikis, chat threads and half-remembered decisions — and now you're pointing an LLM at it and asking for answers you can act on.

The part everyone skips

Almost every company brain being built right now is retrieval. Index the documents, embed them, search them, feed the chunks to a model.

That answers "what did we say about X?" It cannot answer "what is true about X, right now, for the person asking?" — because a document chunk has no schema, no grain, and no idea who's allowed to see it.

Retrieval vs execution

	Retrieval-based brain	Execution-based brain
Answers	What a document said	What the data currently shows
Source of truth	Text chunks	Typed semantic graph
Joins	Not applicable	Proven before the query runs
Permissions	Flattened at ingest	Compiled per person, per query
Same question twice	May differ	Identical by construction
Auditable	Cites a document	Reproduces the exact SQL

Why this bites in production

Three failure modes appear around month three, and none are fixed by better retrieval:

Permission flattening. The index ingests everything, then reconstructs entitlement at query time. Two people ask the same question and get the same answer — a breach, not a feature.
Silent contradiction. Two documents disagree about how churn is defined. Retrieval returns whichever ranked higher. Nobody is told there was a conflict.
Confident staleness. The source changed; the embedding didn't. The answer is fluent, sourced, and wrong.

What closes the gap

Entities, metrics and relationships typed and versioned
A proven join path — no valid path, no query
Access policy compiled into the SQL, before data moves
An audit trail that reproduces an answer months later

The model isn't the bottleneck. The context it runs on is.

The full breakdown — the architecture in detail, what it looked like in production at Cipla (8× data adoption, >90% lower decision latency, 80% fewer IT report requests), where Colrows fits and where it doesn't, and what it costs — is here:

👉 Company Brain for Enterprise AI: Why the Data Layer Decides Everything

Originally published at colrows.com/blogs/company-brain-for-enterprise-ai

title: "Company Brain for Enterprise AI: Why the Data Layer Decides Everything"
published: false
description: "A company brain turns fragmented knowledge into a governed layer AI can act on. Why the data-semantics pillar decides if your agents are trustworthy."
tags: ai, rag, architecture, dataengineering
series: "The Company Brain"
cover_image: https://colrows.com/assets/images/devto/company-brain-for-enterprise-ai.png

canonical_url: https://colrows.com/blogs/company-brain-for-enterprise-ai/