DEV Community: Mayank Mudgal

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/

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.

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.

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

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

YC's Company Brain RFS: What Hyper, GBrain, and the Competition Got Right (and Wrong)

Mayank Mudgal — Mon, 03 Aug 2026 18:50:24 +0000

Y Combinator put "company brain" on its request-for-startups list.

Within a month, every RAG wrapper on the market had renamed itself one.

The RFS is right about the problem

Institutional knowledge is scattered, undocumented, and walks out the door with every senior hire who leaves. Agents are operationally blind: they can query a warehouse and generate SQL, but they have no mental model of how the company works.

That's a real, large, unsolved problem. The disagreement is about what solves it.

What the current field gets right and wrong

	Where they're strong	Where they stop
Context-retrieval players	Fast ingestion, broad source coverage, good UX	Retrieval can't aggregate, join, or enforce entitlement
Warehouse-native tools	Deep integration, existing governance	Scope ends at one platform
Agent frameworks	Orchestration and tool use	No opinion on what data means

The pattern across all three: they solve roughly 40% of the problem — finding relevant material — and treat the rest as someone else's layer.

The missing 60%

Retrieval tells you what a document said about churn. Production decisions need what churn is, at what grain, for the person asking, computed over current data, with proof they were entitled to see it.

That requires:

A typed, versioned semantic graph rather than an embedding index
Join path proof rather than similarity ranking
Compile-time policy rather than post-hoc filtering
Point-in-time reproducibility rather than a citation

The honest competitive read

Context retrieval is necessary and insufficient. A company brain that only reads documents is a very good search box. One wired to governed execution is infrastructure.

By 2027 the category will split along exactly that line, and the retrieval-only products will be features inside something larger.

The full breakdown — the competitive teardown of Hyper, GBrain and Savant, the strategic separation, and the winners-and-losers call — is here:

👉 YC's Company Brain RFS: What Hyper, GBrain, and the Competition Got Right (and Wrong)

Originally published at colrows.com/blogs/yc-company-brain-rfs

Why Current Tools Fall Short: The Semantic Layer Accuracy Imperative for Enterprise AI

Mayank Mudgal — Sat, 11 Jul 2026 09:11:03 +0000

LLMs writing raw SQL against enterprise schemas achieve 16.7%–21.3% accuracy on realistic benchmarks. Semantic layers push that to 54%–97%. The reason is simple: a governed business graph beats unbounded probability. Here is the benchmark evidence, the competitive constraints of incumbents, and the CTO framework for evaluating where to invest.

Why Enterprise AI Needs a Semantic Layer Before It Can Trust SQL

AI agents are getting better at reasoning, planning, and interacting with enterprise systems. But when those agents are asked to answer business questions using company data, one problem keeps showing up:

They often generate the wrong SQL.

Not because the model is weak. Not because the prompt is too short. Not because the database is unavailable.

The real issue is that enterprise data does not explain itself.

A warehouse schema may show tables, columns, and relationships. But it rarely captures the business meaning behind those structures: what counts as an active customer, which revenue metric finance uses, how regions are mapped, which joins are valid, or which data a user is allowed to access.

That missing layer of meaning is why raw text-to-SQL breaks down at enterprise scale.

The problem with raw LLM-to-SQL

Most LLM-to-SQL demos work well on clean sample databases. Real enterprise environments are different.

They usually contain hundreds or thousands of tables, inconsistent naming patterns, undocumented business logic, historical schema changes, and overlapping metrics across teams. A human analyst learns these rules over time. An AI model sees only column names and tries to infer the rest.

That creates a dangerous failure mode: the answer may look correct even when it is wrong.

A model can produce syntactically valid SQL, return a number, and format the result confidently. But the query may use the wrong join path, miss a required filter, choose the wrong revenue definition, or expose data the user should not access.

For dashboards, this is already a problem. For autonomous AI agents, it becomes much more serious.

Why semantic layers change the equation

A semantic layer gives AI agents a governed map of business meaning.

Instead of allowing the model to guess SQL directly from raw tables, the semantic layer defines business entities, metrics, relationships, filters, access policies, and approved query paths. The AI agent expresses intent, and the semantic layer compiles that intent into governed SQL.

With raw text-to-SQL, the model is responsible for discovering business logic at runtime. With a semantic layer, business logic is defined once, versioned, governed, and reused.

That means the same business question should produce the same SQL and the same answer, assuming the same data and permissions. Invalid questions can fail safely before execution rather than returning a plausible but incorrect result.

Enterprise AI does not only need better language understanding. It needs deterministic execution.

The accuracy gap is really a semantics gap

Raw LLM-to-SQL struggles when schemas are large, relationships are implicit, business rules are hidden, or the database was never part of the model’s training data.

Semantic layers improve the situation because they reduce the space of possible mistakes. The model no longer has to infer everything from table names. It works through a governed business graph that already knows which definitions, relationships, and constraints are valid.

The better question is not “Can an LLM write SQL?”

The better question is: Can an AI system reliably answer business questions using the same definitions, controls, and auditability that the enterprise requires?

Without a semantic layer, the answer is usually no.

The biggest danger: silent confidence

The biggest danger in enterprise AI analytics is not that the AI says, “I cannot answer this.”

That is manageable.

The danger is that the AI gives a confident answer that is subtly wrong.

A board report uses the wrong ARR definition. A sales forecast excludes a region. A compliance workflow queries a restricted column. A customer-health agent uses stale product usage logic.

These are not hallucinations in the traditional sense. They are semantic failures.

And semantic failures require semantic infrastructure.

The bottom line

Enterprise AI will not become reliable just because models improve. Models need context, constraints, and governed execution paths.

Raw schemas are not enough. Prompt engineering is not enough. Ad-hoc retrieval is not enough.

For AI agents to answer business questions correctly, they need a semantic layer that turns business intent into deterministic, governed SQL.

That is the foundation of the company brain: not just memory, not just retrieval, and not just dashboards, but a governed execution layer where enterprise knowledge becomes reliable action.

Read the full version on Colrows: https://colrows.com/blogs/why-current-tools-fall-short/

Explore the Company Brain series: https://colrows.com/blogs/topics/company-brain/