DEV Community: Mayank Mudgal

From Ambient Memory to Deterministic Autonomy: AI-Native Infrastructure

Mayank Mudgal — Mon, 21 Sep 2026 18:46:13 +0000

AI with memory is impressive. AI that makes consistent, governed decisions is transformative.

Those are not the same capability, and the gap between them is where most roadmaps stall.

Ambient memory is table stakes now

Every serious assistant remembers context across a session, sometimes across sessions. It recalls what you asked, what it answered, what you corrected.

That's genuinely useful for a conversation. It's nowhere near sufficient for an action.

What autonomy needs that memory doesn't provide

Capability	Ambient memory	Deterministic autonomy
Recall	What was said	What was true, and when
Consistency	Best-effort	Guaranteed by construction
Ambiguity	Interpolates	Refuses
Authorisation	The session's	Proven per action, per identity
Evidence	A transcript	Reproducible derivation

The "what was true, and when" row is the whole thing. A system acting autonomously has to know that a definition changed in April, and be able to reconstruct both sides of that change.

The progression

Ambient memory — remembers the conversation
Governed memory — a typed, versioned graph of what's true, with policy attached
Deterministic execution — decisions compiled through that graph, join paths proven, policy injected
Autonomy — the human leaves the loop because being wrong is structurally prevented, not statistically unlikely

Most products are at step 1 and marketing step 4. Steps 2 and 3 are unglamorous infrastructure, which is exactly why they're skipped.

Why the order can't be rearranged

You cannot bolt determinism onto a probabilistic pipeline after the fact. The guarantee has to be built into how queries are constructed — which means step 3 depends on step 2 existing first.

The full breakdown — the progression in detail, what each stage requires, and the infrastructure behind deterministic autonomy — is here:

👉 From Ambient Memory to Deterministic Autonomy: AI-Native Infrastructure

Originally published at colrows.com/blogs/ambient-memory-to-deterministic-autonomy

Semantic Layer vs Text-to-SQL: When Each Wins, and Why Mature Teams Use Both

Mayank Mudgal — Thu, 17 Sep 2026 14:53:52 +0000

Half the market is evaluating text-to-SQL against a semantic layer, as if it were a choice.

One turns language into a query. The other decides whether that query is allowed to mean what it says.

They operate at different layers

	Text-to-SQL	Semantic layer
Responsibility	Parse intent, emit syntax	Resolve meaning, grain, joins, policy
Knows what `revenue` means	No	Yes, versioned
Knows which join is valid	Guesses	Proves
Knows who's asking	No	Yes, and compiles accordingly
Fails how	Confident wrong answer	Explicit refusal

Buying the first without the second gets you fluent SQL over ambiguous meaning — which is the exact failure every enterprise pilot reports.

Why mature teams run both

The LLM is genuinely good at one thing: turning messy human phrasing into structured intent. That's real value and worth having.

What it's bad at is deciding what your business means — because that information was never in its training data and can't be fitted into a prompt.

So the mature architecture uses each for what it's good at: model handles language, graph handles meaning, planner handles joins, policy engine handles authorisation, compiler emits SQL.

The number that makes the case

Give the same model a resolved definition and a proven join and accuracy stops being a function of prompt quality. In our benchmark: 14.5% on raw schema, 98.2% with compiled context.

Take the semantic layer away and no model upgrade recovers that gap, because the missing information isn't in the model.

The evaluation question

Not "which one." It's whether the tool you're buying includes the substrate, or quietly assumes you already have one.

The full breakdown — the layer-by-layer division of responsibility, and how the two compose in production — is here:

👉 Semantic Layer vs Text-to-SQL: When Each Wins, and Why Mature Teams Use Both

Originally published at colrows.com/blogs/semantic-layer-vs-text-to-sql

Cube Pricing 2026: The Cloud Tiers, the Compute Units, and the Real Cost Drivers

Mayank Mudgal — Tue, 15 Sep 2026 14:01:00 +0000

Cube Cloud's pricing page is clearer than most in this category. Credit where it's due.

The cost that catches teams out isn't on the page — it's pre-aggregation.

The tiers are the easy part

Straightforward structure, published, comparable. Start there and then add the three things that actually move the number.

What moves the bill

Driver	Why it grows
Pre-aggregations	What makes Cube fast; they build and refresh continuously
Refresh frequency	Set once, rarely revisited, directly multiplies compute
Query volume	Scales with every app connected, not with users
Warehouse compute	Billed by Snowflake/BigQuery, not by Cube
Data model upkeep	An engineer's time, permanently

Refresh frequency is the single most under-examined lever. Teams pick something conservative during setup and never tune it, then wonder why the compute line grew faster than usage.

How to model it honestly

Count applications, not users — each connected app multiplies query volume
Enumerate pre-aggregations and their refresh cadence
Attribute the warehouse compute those refreshes cause
Add the engineer who maintains the data model

Then run the identical four-part model against anything you're comparing it to. Comparing Cube's tier against another product's total cost flatters it by roughly the size of a salary.

The verdict

Cube is well engineered and the pricing is honest. It's a good fit for multi-app estates with a stable metric set.

Just build the comparison on your actual refresh and query patterns rather than the headline tier — and include the modelling labour on both sides.

The full breakdown — tier structure, compute unit mechanics, and a complete cost model — is here:

👉 Cube Pricing 2026: The Cloud Tiers, the Compute Units, and the Real Cost Drivers

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

ThoughtSpot Pricing Explained: List Price, Real Contracts, and the Cost of Modeling

Mayank Mudgal — Thu, 10 Sep 2026 16:18:25 +0000

ThoughtSpot's list price is not the number that decides this deal.

The worksheet layer someone has to build and maintain is — and it never appears on the quote.

What's on the quote

Platform cost is comparable to peers and reasonably transparent once you're in a conversation. Consumption-based tiers scale with query volume, which means adoption success costs more — worth modelling before you celebrate usage growth.

What isn't

Cost	Why it's invisible
Worksheet curation	Determines search quality; needs an owner
Indexed data volume	Performance tuning turns into spend
Re-modelling	Every upstream schema change
Query volume growth	The success case is the expensive case

The worksheet layer is the real driver. Search quality is a direct function of how well it's curated and how current it's kept — and that's a salary line, not a licence line.

The pattern across this category

It's consistent: the licence buys the engine, and the semantics are a labour cost nobody budgets for. That's true of ThoughtSpot, Looker, AtScale and Cube alike, in different proportions.

Which means the only honest comparison prices three things:

Licence and platform
Compute and indexing
The person who maintains the model

Run that model against every option, including one where the modelling line is the system's job rather than a headcount. The ranking often changes.

How to negotiate it

Model your query volume at 3× current usage, not current. Consumption pricing rewards vendors when you succeed, and the second-year invoice is where that lands.

The full breakdown — list price vs real contracts, the modelling cost analysis, and a like-for-like TCO framework — is here:

👉 ThoughtSpot Pricing Explained: List Price, Real Contracts, and the Cost of Modeling

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

Qlik Sense Alternatives: Why Dashboard-First BI Is Dead for Agentic Enterprises

Mayank Mudgal — Tue, 08 Sep 2026 14:24:43 +0000

Qlik's associative engine was genuinely ahead of its time — exploring data by what connects to what.

An AI agent can't explore. It has to be right on the first attempt.

Two different interaction models

Associative exploration is built for a human following a hunch: click, see what co-occurs, follow the thread. That's a real strength and it's why Qlik kept its footprint.

Agents work the other way round. They arrive with an intent, need one correct interpretation, and must prove entitlement before running anything.

	Associative exploration	Agent resolution
Interaction	Iterative, human-guided	Single-shot, machine-initiated
Ambiguity resolved by	The user clicking around	The system, or a refusal
Join semantics	Discovered by navigation	Proven at compile time
Governance	App and sheet level	Compiled into the query
Output	A view to interpret	A number plus its derivation

What to weigh in an evaluation

Does the layer resolve business meaning, or expose an exploration surface?
Is the join path proven, or discovered by the user?
Is authorisation enforced in the generated query, or at the app layer?
Who maintains the model as schemas change?
Can the same question, asked twice, be shown to return the same answer?

The honest position

Qlik remains strong for analyst-led discovery, and if that's your dominant workload there's no argument for moving.

The question is what serves the consumers that are about to outnumber your analysts — and an exploration engine, however good, doesn't produce the proof that automated decisions require.

The full breakdown — the scored comparison, and the architectural difference between exploration and resolution — is here:

👉 Qlik Sense Alternatives: Why Dashboard-First BI Is Dead for Agentic Enterprises

Originally published at colrows.com/blogs/qlik-sense-alternatives

Snowflake Semantic Views Explained: What They Are, and What Sits Beyond

Mayank Mudgal — Mon, 07 Sep 2026 17:02:26 +0000

Snowflake shipped Semantic Views and a lot of people declared the category solved.

It's a real step forward. It's also scoped to exactly one warehouse.

What you genuinely get

Metric definitions living next to the data, governed by Snowflake's own model, queryable by Cortex and external tools. For a single-platform estate that beats redefining the same metric in four dashboards.

What to understand before building on it

Consideration	Reality
Authoring	Hand-written by your team
Scope	Ends at the Snowflake boundary
Governance	Snowflake RBAC — strong, but Snowflake-only
Drift detection	None; a stale definition stays stale silently
Join proof	Not provided — inference still happens upstream

The drift row is the one that bites over time. A definition that stopped matching how people query it produces no error, no alert, and no failing test. You find out when two teams disagree in a meeting.

The question that decides it

What happens to the third of your data that isn't in Snowflake?

For most enterprises there's a lakehouse someone piloted, an operational Postgres, and a SaaS system that never got migrated. A warehouse-native semantic layer can't see any of it, so cross-boundary joins fall back to hand-written SQL — and the metric gets defined a second time, differently.

The pragmatic position

Adopt Semantic Views. They're good, they're included, and they improve consistency inside Snowflake.

Just don't mistake a metric store for an execution layer. It tells an agent what a metric is; it doesn't prove the join is valid or that the caller was entitled to the rows.

The full breakdown — what Semantic Views do in detail, the boundaries, and what a cross-estate layer adds above them — is here:

👉 Snowflake Semantic Views Explained: What They Are, and What Sits Beyond

Originally published at colrows.com/blogs/snowflake-semantic-views

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