I’ve been around long enough to remember when semantic layer meant Universe Designer. In the 1990s BusinessObjects introduced a “universe” — a metadata model that hid SQL and let business people drag and drop their way through a relational database. If you worked in BI back then you probably spent months building one: picking tables, defining joins and measures, and praying the business wouldn’t change its mind.

Three decades later that old idea has resurfaced. LinkedIn feeds and Gartner reports are buzzing about semantic layers. Google Trends shows a hockey‑stick curve for searches on the term. Why now? What changed? And what can the past teach us about the future?

Subscribe now

Universes: hiding SQL from business users

The first commercially successful semantic layer was the Universe. BusinessObjects’ Universe Designer let developers build a metadata layer on top of relational databases. It mapped tables into business‑friendly objects and defined measures and dimensions so that users could query without writing SQL. The Universe acted as a bridge between raw data and people, abstracting complexity, providing governed access and enabling drag‑and‑drop analysis. For many enterprises in the 1990s and 2000s it became the backbone of reporting and budgeting.

But the early universes had limitations. They were tightly coupled to the BusinessObjects stack; building and updating them required specialised tooling; and each universe was tied to a single database. When SAP acquired BusinessObjects it introduced the UNX universe and Data Foundation to federate multiple sources. Even so, universes remained proprietary and slow to adapt. The lock-in was a major detractor. Teams needed faster answers, and self‑service BI promised agility.

Cubes and OLAP: pre‑aggregated semantics

At the same time, OLAP platforms like Microsoft Analysis Services and Hyperion Essbase defined hierarchies, measures and dimensions in cubes. Cubes pre‑aggregated data so queries were fast, and they embodied a kind of semantic layer by encoding business logic (e.g., calendars and product hierarchies). Yet they were also vendor‑specific and required ETL to flatten data into a multidimensional structure. They thrived in finance and supply‑chain planning but were less suited to the messy, evolving schemas of modern analytics.

Self‑service BI and the semantics vacuum

By the late 2000s a new mantra emerged: self‑service. Tools like Tableau and Qlik let analysts connect directly to databases, build their own dashboards and share insights without waiting on IT. This speed came at a cost: every team defined metrics differently. The shared context encoded in universes and cubes evaporated. Analysts wrote SQL with business logic sprinkled throughout; dashboards proliferated; definitions drifted. In other words, the semantic layer went away because it was too slow and too proprietary to keep up.

LookML, HANA and semantics as code

The next generation tried to marry agility with governance. Looker introduced LookML, a developer‑friendly language for defining dimensions, measures and joins in YAML. LookML treated semantics as code: version‑controlled, reusable and composable. But it was still locked inside the Looker ecosystem (now, the BigQuery ecosystem within Google Cloud).

SAP took a different approach with HANA. Its calculation views and Core Data Services (CDS) moved semantic modelling into the database itself, pushing down business logic for real‑time analytics. HANA’s semantic layer supported federated queries across universes, BW (BEx) queries and external systems. Despite these advances, semantics remained tied to particular vendors, and adoption was limited to enterprises deep in those stacks.

Semantics for purists, not for the business

One of the biggest failures of semantic layers was that no one, outside the data / BI team, cared about them. Data leaders would debate which semantic approach is best, and where you should manage your entities and their relationships.

But, the business didn’t care, and that meant that financially these endeavors would never take off. Companies built to fix the semantic layer problem struggled to get real traction, and saw their growth flatten out.

The context crisis: AI exposes the gap

Enter generative AI. Large language models (LLMs) can answer questions and generate analyses, but they don’t know what revenue means. When analysts ask natural‑language questions directly against a warehouse, LLMs often guess incorrectly; one study found that natural‑language queries against raw data were wrong in 80 % of cases. Without shared definitions, AI amplifies ambiguity and hallucinations.

On the flip side - well built semantic layers can generate massively reliable results, as dbt recently showed.

This context crisis is reigniting interest in semantic layers. Instead of hiding SQL from humans, the new goal is to teach machines what data means. AI‑driven analytics require deterministic definitions, machine‑enforceable relationships and real‑time governance. The old universes were built for reporting. The new semantic layers are built for agents.

What’s different this time?

Several things make today’s semantic layers more than a repeat of the past:

• Open and headless. Modern semantic layers are decoupled from any one BI tool. They expose definitions via open APIs (MCP, REST, GraphQL) so that agents, dashboards, notebooks, AI-assisted coding and chatbots can all consume the same context.

• Machine‑enforceable semantics. Definitions are not just documentation; they are executed automatically. When a query references net revenue, the layer applies the correct joins, filters and security policies without the analyst having to remember them, nor the business user needing to know them.

• Federated and composable. Unlike early universes, modern layers can sit on top of multiple warehouses, vector stores and knowledge graphs. They let you define semantics once and use them everywhere, even across platforms.

• Driven by AI. The killer application is no longer drag‑and‑drop reporting; it’s AI copilots and agents that need trustworthy data to automate tasks and decisions. Research shows that grounding LLMs in a semantic layer increases accuracy by more than 3×.

In short, we’re not going back to 1992. We’re building something new: a universal, open semantic layer that acts as the control plane for both humans and machines.

The new role: semantic engineering

All of this raises a people question. In the old days the Universe designer sat in IT and rarely interacted with the business. Today, someone needs to own your company’s semantic layer and continuously align it with reality. That person might be a finance lead who knows the nuances of ARR, an operations manager who understands edge cases, or an analytics engineer who curates dbt models. Naming them semantic engineers gives them a mandate: codify the business logic that AI depends on.

Their job isn’t just to build dashboards; it’s to maintain a living semantic model that exposes metrics, relationships and policies to every tool and agent. Success is measured by how reliably AI operates across the enterprise, not by how many reports they ship.

Writing SQL code by hand will be gone by the end of 2026. Maintaining semantic models will be the new norm.

Lessons from history — and how to start

The history of semantic layers teaches us three things:

1. Abstraction matters. Universes and cubes were successful because they hid complexity and empowered non‑technical users.

2. Coupling kills adoption. They fell out of favor because they were tightly bound to proprietary tools. As the stack diversified, semantics didn’t keep up.

3. Context is infrastructure. The AI era demands deterministic, governed semantics. Without them, LLMs hallucinate and agents do the wrong thing.

If you want to build a semantic layer today, start small. Pick a domain where metric drift causes pain; nominate a semantic engineer; generate a first model using existing SQL and BI assets (Solid can automate this for you); then iterate. Treat semantics as code, version it, and share it via MCP. Learn from the history and avoid the coupling mistakes of the past.

If you’d like to see a modern semantic layer in action, get a demo. We’ll show you how Solid generates and maintains a universal semantic layer on top of your data so that humans and AI can finally speak the same language.

Check out Solid

Last week, I did a very startup-y thing.

I took a bunch of our recent customer and prospect interactions, anonymized the sensitive stuff, and asked ChatGPT a simple question:

Why are organizations coming to Solid right now?

Not what do we think they want. Not what our pitch says they should want. Not what the analyst reports say the market wants.

What are they actually trying to solve?

This is not a scientific survey. It’s not a Gartner Magic Quadrant. It’s not statistically significant. It’s a qualitative analysis of the last couple of months of conversations, pilot plans, solution proposals, and meeting summaries.

Still, the pattern was surprisingly clear.

Companies are not coming to us because they woke up one morning and decided they need a semantic layer.

They’re coming because they want AI to do real work with their data, and they’re discovering that the missing piece is the context layer, and semantics, that makes their data understandable, governed, and reliable.

In other words: AI has created the urgency. Messy enterprise data has created the blocker.

Subscribe now

The short version: everyone wants agents, but agents need trusted data

A year ago, most conversations about AI and data were still vague.

“We want to use GenAI.”
“We want chat with data.”
“We want business users to self-serve.”
“We want to reduce analyst bottlenecks.”

Those conversations still happen. But they’re getting sharper.

Today, the question is much more concrete:

How do we let an AI agent query our data, understand our metrics, use the right joins, respect our business definitions, and return something people actually trust?

That’s a very different conversation.

It’s no longer about a chatbot sitting on top of a warehouse and hoping for the best. We wrote about that early on in Data Chatbots: what people are really doing, and the reality hasn’t changed much. If the AI doesn’t understand the data, the chat experience breaks very quickly.

What has changed is that organizations are now trying to move beyond demos. They want AI agents and AI-powered workflows in production.

And production is much less forgiving than a demo.

Trend #1: “Chat with your data” is still the door opener

The most common entry point is still some version of “chat with your data.”

Business users want to ask questions in natural language. Data teams want to reduce ad-hoc requests. Executives want answers faster. Everyone wants the magic box where you type a question and get a reliable answer.

This is not surprising. Snowflake, Databricks, Microsoft, Google, and others are all pushing the market in this direction. Snowflake has Cortex Analyst, Databricks has Genie, and the broader AI ecosystem is converging around standards like MCP.

The surprise is that “chat with data” is often not the end goal.

It’s the easiest way to describe the pain.

The real pain is that business users don’t know where the data is. Analysts are tired of being the routing layer between every business question and every database table. Data engineers are tired of maintaining fragile logic across dashboards, notebooks, semantic layers, and half-forgotten SQL files.

So the user says “chat with data,” but what they often mean is:

Please make our data understandable enough that humans and machines can use it without opening five Slack threads and asking the one analyst who has been here since 2017.

That’s a much bigger problem.

Trend #2: the analyst bottleneck is getting worse

Another strong pattern: data teams are overwhelmed.

Not “busy.” Overwhelmed.

In many organizations, analysts are still spending too much time finding the right table, reverse-engineering old dashboards, understanding metric definitions, and figuring out which version of a query is trusted.

We’ve written before that nobody cares about the efficiency of the data analyst. That headline was intentionally annoying, but the point was real: the business usually doesn’t buy “analyst efficiency” as the main outcome.

What they do care about is speed to decision.

What we’re seeing now is that the analyst bottleneck is becoming a business bottleneck. The business wants campaigns optimized faster. Sales wants better account signals. Finance wants cleaner performance views. Operations wants alerts that trigger action, not another dashboard to check.

The analyst is sitting in the middle of all of that.

So organizations come to us with a technical problem, but underneath it is a business problem: the demand for data work has exceeded the human capacity to fulfill it.

AI is supposed to help, but without a trusted semantic layer, it creates more review work, not less.

Trend #3: manual semantic modeling does not scale

This one comes up again and again.

Enterprises understand the need for a semantic layer. They know that metrics, dimensions, relationships, definitions, and business logic need to be captured somewhere. They know that without this layer, Text2SQL and agents will hallucinate.

The issue is not awareness.

The issue is labor.

Manual semantic modeling is slow. Evaluation is slow. Maintenance is slower. Every new domain requires people to identify the right tables, understand the logic, define metrics, document relationships, test the model, and keep it current as the data changes.

That may work for a few high-value BI dashboards. It does not work for enterprise AI.

We wrote about this in Semantic layer for AI: let’s not make the same mistakes we did with data catalogs. The core mistake is believing humans will happily document and maintain everything if only the project is important enough.

They won’t.

Humans hate documenting data. They especially hate maintaining documentation they didn’t need in the first place.

So when organizations come to Solid, they’re often looking for a way to generate the semantic layer automatically, evaluate it automatically, and maintain it with much less manual effort.

The important nuance: they don’t want a black box.

They want automation with control.

The model should be generated automatically, but reviewed by humans. Accuracy should be measured, not assumed. Fixes should be recommended, not hidden. The data team still owns the truth, but AI does the heavy lifting.

Trend #4: trust is becoming the real production blocker

Many organizations have already tried some version of “AI on top of data.”

The demo worked.

Then someone asked a slightly different question, and the answer was wrong.

Or the SQL looked plausible but used the wrong metric.

Or the agent joined tables in a creative way.

Or the business user got a number that didn’t match the dashboard.

That’s when the excitement turns into skepticism.

We wrote about this in Everyone wants Text2SQL, but the pros don’t trust it. The problem is not only whether AI can generate SQL. The problem is whether the people responsible for the data trust the generated SQL enough to put it in front of the business.

The market is now asking for evidence.

Not “our model is accurate.”
Not “the LLM is better now.”
Not “trust us.”

They want benchmarks. They want expected SQL. They want side-by-side validation. They want to know where the model failed, why it failed, and what needs to change.

This is a healthy shift.

AI in production requires measurable trust. Vibes are not enough.

Trend #5: the use cases are becoming more operational

Another interesting shift: the use cases are moving from “answer my question” to “run my workflow.”

The early data chatbot dream was mostly analytical. A user asks a question. The system answers. Maybe it creates a chart.

Now we’re seeing more operational use cases:

An agent that analyzes account signals and recommends next actions.
An agent that reviews campaign performance and suggests changes.
An agent that helps prepare customer-facing teams before a meeting.
An agent that monitors operational issues and pulls the relevant context automatically.
An agent that turns business signals into prioritized workflows.

This matters because operational workflows raise the bar.

If an AI assistant gives you a wrong answer in a sandbox, that’s annoying.

If an AI agent takes the wrong action in a production workflow, that’s dangerous.

So the underlying data logic needs to be more governed, not less. The more autonomous the agent, the more important the semantic layer becomes.

The ROI from AI will not come from buying a generic assistant and hoping employees find uses for it. It will come from improving specific workflows.

That’s exactly what organizations are trying to do now.

Trend #6: customers want flexibility, not another locked-in layer

One theme I didn’t expect to be so strong: flexibility.

Organizations are very aware that the AI stack is changing quickly. Today they may be testing one agent framework. Tomorrow it may be another. One team may be using a cloud-native AI tool. Another may be experimenting with an orchestration platform. Another may want to export semantic models into dbt, Snowflake, Looker, or something else.

They do not want to rebuild their context layer every time the AI tool changes.

This is why the semantic layer needs to be decoupled.

It should serve many consumers: BI tools, AI agents, Text2SQL engines, internal apps, and whatever comes next. That’s also why MCP is interesting. Whether or not MCP becomes the standard, the direction is obvious: AI systems need a structured way to access tools and context.

The enterprise buyer is increasingly allergic to anything that feels like a closed semantic island.

They want one governed source of business logic that can travel.

Trend #7: the market is accepting that data will stay messy

This may be my favorite one.

For a long time, companies would start the conversation by apologizing for their data.

“Our data is a mess.”
“Our documentation is bad.”
“Our warehouse is complicated.”
“Our metric definitions are inconsistent.”
“We’re not ready yet.”

Recently, the conversation is changing.

Companies still know their data is messy, but they’re less interested in pretending they can clean everything before AI arrives.

Good.

We wrote about this in “Sorry for the mess” - everyone’s data is messy, and it’s Okay. The point is not that messiness is ideal. The point is that messiness is reality.

The winning approach is not to wait until the warehouse is perfect.

It’s to build AI that can learn from the messy signals that already exist: schemas, query logs, BI dashboards, documentation, tickets, Slack discussions, Confluence pages, metric definitions, and usage patterns.

That’s where the real organizational knowledge lives.

Not in one pristine document called “Final_Final_Official_Metric_Definitions_v7.”

What this means for the market

My takeaway from this qualitative analysis is simple:

The market has moved from curiosity to implementation.

In 2024 and early 2025, many companies were asking: “Can AI help with data?”

Now they’re asking: “What do we need to put in place so AI can safely work with our data?”

That’s a much better question.

It’s also a much harder one.

The answer is not just a better LLM. It’s not just a data catalog. It’s not just a BI tool with a chat box. It’s not just a manually built semantic layer.

It’s an AI-native context layer that can create, evaluate, expose, and maintain business semantics across the organization.

That sounds a bit buzzwordy, so let me say it more simply:

AI needs to know what your data means.

Not just what tables exist. Not just what columns are called. What the business means when it says revenue, active customer, churn risk, qualified lead, suspicious transaction, campaign performance, account health, or pipeline sufficiency.

And it needs to know that in a way that is testable, governable, and usable by agents.

The funny part: most companies don’t come asking for that

This is the part I find most interesting.

Very few organizations start the conversation by saying:

“We need an AI-native semantic layer that can be automatically generated, benchmarked, maintained, and exposed through MCP to downstream agents.”

No one talks like that. Thankfully.

They come with symptoms.

They want chat with data.
They want agents.
They want fewer ad-hoc requests.
They want faster dashboards.
They want to migrate off old BI.
They want better campaign analytics.
They want better sales signals.
They want to reduce manual analyst work.
They want to stop hallucinations.
They want to make AI useful.

Our job is to help connect those symptoms to the root cause.

The root cause is not that the LLM isn’t smart enough.

The root cause is that the organization’s data knowledge is scattered across systems, people, dashboards, SQL queries, documents, and tribal memory.

Solid’s job is to turn that scattered knowledge into something AI can actually use.

Urgency found the market

A few months ago I wrote that we found urgency, or maybe it found us.

After looking at the last two months of conversations, I think that’s even more true now.

The urgency is not “semantic layers are cool again.”

The urgency is that enterprises want AI agents in production, and they’re realizing that agents without semantics are interns with database access.

Very enthusiastic. Very fast. Occasionally useful. Not someone you’d leave alone with important business decisions.

The next phase of enterprise AI will be less about demos and more about trust.

Less about asking questions and more about automating workflows.

Less about connecting AI to data and more about helping AI understand what the data means.

That’s the market pulse we’re seeing right now.

And honestly, it’s a pretty exciting one.

Talk to us

In a live environment, Text-to-SQL isn’t a simple translation task - it’s an agentic system. It’s a dynamic loop of generation, execution, and self-correction. To push the boundaries of what our agent can do, we conducted a comparison between our current baseline and the Snowflake/Arctic-Text2SQL-R1-7B.

The results represent a significant achievement for specialized AI: the Snowflake/Arctic-small 7B model expert didn’t just keep up; it exceeded expectations and painted the road for database-finetuned models.

Subscribe now

Agentic Framework for Text2SQL

The agentic workflow, partially illustrated in Figure 1, represents the end-to-end process for generating reliable SQL. The process starts with retrieving a semantic model that encapsulates the context of the question, i.e., the tables, columns, joins, metrics, and additional relevant data to answer the question. Then, with this context, an LLM based Initial SQL Generation Module (Figure 1a) creates the query that answers the question, which serves as the critical point of comparison between the GPT-based baseline and the Arctic SLM. Once the initial SQL is generated, a cycle of quality control and verification with automated checks assess the syntax, schema adherence, content and executability of the query, and attempts to fix the query if necessary (Figure 1b). The output of this process is a textual response including: the SQL query, the generation process explainability and detailed reasoning.

Building the Agentic Toolkit

Arctic-7B is a fine-tuned SLM specialized for generating SQLite queries given a semantic context. Incorporating it into a production agentic workflow requires controlling the information flow in and out of the model. Specifically, the prompt structure of the semantic context must be organized as the input that the model was trained on. In addition, the SQLite queries must be transformed to the specific SQL dialect of the environment database.

To this end, we encapsulated the model with the following pre- and post- processing procedures (Figure 2):

1. Prompt Standardization: We based our inputs on Solid semantic models, extending the OmniSQL standard, augmenting it with enriched descriptions for each column and table, extended metric and query examples, and a schema summary. This provided the model with a clear and valuable interpretation of the schema.

2. The Transpilation Layer: SQL dialects have distinct functions and syntax. Since the Arctic SLM was trained on a specific SQLite dialect, generated SQL code requires transpilation (conversion) to the dialect of the target data warehouse. In this set of experiments we used Snowflake, so we developed a custom layer to handle query transpilation to Snowflake dialect.

Results

For this experiment, we replaced the initial SQL generation module based on GPT models to a module based on the open source Snowflake/Arctic-Text2SQL-R1-7B small model (Figure 2). We used an internal evaluation benchmark comprising 137 couples of free text business questions and their related queries. Each agent performance was measured by executability, whether the generated SQL was able to execute successfully at the source system (Snowflake, in our case), and returned values alignment of the generated query to a reference (ground truth query).

The Arctic and baseline initial SQL generation was able to produce an executable SQL for 65% and 77% of questions, respectively. Understandably, most of the initial failures for the Arctic model were syntax errors, which were fixed after a single correction step. After completing the correction loops, both the Arctic and baseline models generated executable SQLs in a Snowflake dialect for 97% of questions. Additionally, there was not a significant difference in the generated SQLs retrieved values between the versions.

Conclusions and Future Work

Ultimately, this experiment demonstrates that specialized SLMs can rival industry giants when embedded within a robust agentic framework. By leveraging a modular loop of self-correction, the Snowflake/Arctic-7B model exceeded expectations, proving its performance is comparable to much larger models once initial errors are mitigated.

A key factor in this success was our use of Solid semantic models, which condensed large database schemas into enriched, high-signal summaries; this reduced the required context window and allowed the SLM to navigate complex data structures efficiently. Furthermore, using a SQLite-specialized base proved highly effective for generalizability; with the help of the transpilation layer, we narrowed the initial performance gap to just 12% due to syntax. This remaining delta was successfully closed during the fixing loop, resulting in nearly identical final executability. Moving forward, the true potential lies in database-specific fine-tuning, enabling these models to learn the unique nuances of individual datasets from the ground up.

dbt’s recent post, Semantic Layer vs. Text-to-SQL: 2026 Benchmark Update, is useful precisely because it moves the conversation forward. Instead of arguing from ideology, it argues from failure modes. And that is the right way to think about enterprise AI on top of data.

Their conclusion is also directionally right: both approaches matter. Text2SQL has gotten dramatically better. Semantic layers remain far more deterministic when the question is within scope. If accuracy matters, semantics win. If flexibility matters, Text2SQL still has an important role to play.

I agree with that.

But I think there is a more important conclusion hiding underneath their benchmark:

The real challenge is not Text2SQL or semantic layer. The real challenge is semantic model production.

Subscribe now

The benchmark proves more than it says

The most interesting part of dbt’s post, in my opinion, is not just that the semantic layer performed better on modeled data.

It is that when coverage was missing, they added just three additional models, reran the benchmark, and suddenly the semantic layer could answer every question in scope, while Text2SQL improved too. That is a very important signal. It tells us that the bottleneck is not only reasoning quality. It is the system’s ability to create the right semantic structure, at the right time, for the right business question.

That is exactly where most enterprise projects get stuck.

On a whiteboard, “just build the semantic layer” sounds reasonable. In the real world, that means defining metrics, joins, dimensions, business definitions, tests, ownership, and maintenance processes across a living data stack that keeps changing. New tables appear. Existing logic shifts. Teams rename KPIs. Dashboards drift. Query patterns evolve.

So yes, the semantic layer is incredibly valuable. I wrote about that in The Two Souls of a Semantic Layer: A Tale of Governance and Insight. But the moment you say “semantic layer,” you also have to ask: who is building it, who is testing it, who is publishing it, and who is keeping it alive six months later?

That is where the theoretical debate becomes an operational one.

This is the part Solid is focused on

At Solid, our view has been consistent for a while.

In Data, Meet Business: Why You Need JIT Semantic Models, Instead of a Static Semantic Layer, I argued that static semantic models are too slow for a business that changes every week.

In The Ghost in the Machine: How Solid drastically accelerates semantic model generation, I explained part of the “how”: the logic of the business is often not fully captured in the schema itself. It lives in usage patterns, query history, BI assets, and the actual paths analysts take through the data.

That is why I think the future is not “Text2SQL alone,” and it is not “semantic layer alone,” either.

It is Text2SQL plus semantics, connected by an engine that continuously creates, tests and maintains the semantics themselves - even as data changes, usage evolves.

Publicly, that is exactly how we describe Solid Build: automatically turning warehouse usage, BI semantics, SQL query history, and metadata into semantic models; keeping them current as the data changes; letting teams review and approve them; and validating model logic before publication.

That matters because the enterprise problem is not proving that semantic layers work in a benchmark.

The enterprise problem is making enough of them, fast enough, with enough quality, and keeping them fresh enough, that the benchmark becomes your everyday reality.

The real architecture is not “vs.” It is “and, plus automation”

So when I read dbt’s post, my reaction is not disagreement. Quite the opposite. I think it confirms where the market is going.

How do you produce and maintain that modeling at enterprise scale?

If the answer is “a heroic manual effort by a small team of experts,” then the system will help in the demo and decay in production.

If the answer is “use AI to marry exploration and semantics, and automate the lifecycle of the semantic models themselves,” then you start to have something much more durable.

That is the architecture I believe in:

Text2SQL for exploration.
Semantics for determinism.
And an always-on semantic engineering layer that generates, tests, publishes, and maintains the bridge between them.

That, to me, is where this market is actually headed.

And that is why I think the most important question in 2026 is no longer “semantic layer or Text2SQL?”

It is:

Who is building the semantics, and how fast can they keep up with the business?

I recently sat down with Ryan Wexler on the podcast, and I enjoyed this one a lot. It’s available to listen to now: YouTube, Spotify, Apple.

Usually, on Building with AI: Promises and Heartbreaks, I speak with builders, operators, and data leaders who are deep in one company’s AI journey. Ryan brought a different angle. As a Principal at SignalFire, he gets a horizontal view into the market: what founders are building, what enterprises are actually buying, where the hype is ahead of reality, and where something very real is already happening.

That made for a particularly interesting conversation.

Ryan is in a unique position to see patterns early. SignalFire is not a traditional VC that just writes checks and hopes for the best. It has built a real technology and data muscle internally, including Beacon AI, to support sourcing, recruiting, GTM, and portfolio support. So when Ryan talks about how AI is changing work, he’s not speaking only from the investor seat. He is also seeing how these systems get used in practice.

Subscribe now

Most enterprises are not refusing AI. They are stuck in the middle.

One of the most useful parts of the conversation was how Ryan broke down the market.

In his view, there are roughly three groups right now:

1. The disbelievers, the people who still think AI is mostly a parlor trick.

2. The big middle, where organizations are using AI tools and seeing value, but are not yet rethinking work around them.

3. A much smaller group that is fully bought in and actively redesigning workflows, teams, and products around AI.

That lines up pretty well with what I’m seeing too.

The market narrative is often too binary. Either “AI is changing everything” or “AI is overhyped and barely works.” Reality, as usual, is messier. Most large enterprises are somewhere in the uncomfortable middle. They have Copilot, ChatGPT Enterprise, Cursor, Claude Code, or some equivalent floating around the organization. Some people are getting real value from it. But the company itself is still not fully operating in an AI-native way.

This is also why I keep coming back to themes I wrote about in (Almost) no AI in production and Throwing away BI is a Bad Idea. People want the new experience, but they still need the old safety rails. They want AI, but they still need trust. They want agents, but they still keep a human in the loop.

That is not failure. It is transition.

Ryan’s point was that the biggest blocker is not disbelief. It is change management. The tools are still early. The models keep changing. The workflows are not yet stable. So even when people believe, it still takes time to move.

Founders should stop asking “what’s hottest?” and start asking “what can I win?”

Another part of the conversation that stuck with me was Ryan’s framing of the types of AI companies selling into enterprises today.

He described three broad buckets.

The first are transformation plays. These are the companies trying to help enterprises fully rethink how work gets done. Huge opportunity, obviously. Also hard. These deals involve process change, redesign, consulting, buy-in, internal champions, and patience.

The second are next-generation SaaS companies. These are applications where AI is built into the product itself. The buyer does not need to reinvent the whole company to get value. A customer support platform that now resolves tickets with agents is an example. Same budget owner, same category, new capabilities.

The third are bottoms-up prosumer tools. This is where an individual gets a tool that makes them more productive: ChatGPT Enterprise, Copilot, Cursor, Claude Code, ElevenLabs, and so forth. Ryan’s view was that this is where a lot of the fastest adoption has happened because the value is immediate and the buying motion is much simpler.

Then I asked him the natural founder question: if you were starting something new, which of the three would you build in?

His answer was excellent: “Whichever one you can win in.”

I liked that a lot.

Founders sometimes over-rotate to whatever category is currently generating the most noise on X or LinkedIn. But not every founder is built for the same motion. Some are excellent at bottoms-up adoption. Some are great at enterprise solution sales. Some can navigate long cycles and help customers rethink processes. Others cannot. And that’s okay.

The goal is not to build in the hottest category. The goal is to build in the category where your team has a real shot at winning.

That also ties directly to a point I made in Nobody cares about the efficiency of the data analyst. Buyers do not wake up wanting AI in the abstract. They want impact. They want better outcomes. They want a wedge that matters.

ROI is still messy, and that’s part of the story

We also dug into a question many founders and buyers still struggle with: how do you prove ROI?

If AI is automating a specific workflow, the math is easier. If an agent resolves a support ticket, runs a recruiting screen, or handles a voice interaction, you can start counting minutes, throughput, coverage, and outcomes.

But when AI is helping an individual employee do their job better, the math gets fuzzier.

How exactly do you measure the ROI of giving 10,000 employees access to a co-pilot? Lines of code are a bad metric. “Time saved” is often hand-wavy. Yet, clearly, something is happening.

Ryan was very honest about this. A lot of organizations are still buying these tools before they have perfect measurement. They know the direction is right, even if the spreadsheet is still weak.

That matches what I’ve been hearing from leaders as well. In my conversation with Meenal Iyer, one of the recurring themes was that the winning teams are not waiting for the world to become perfectly measurable. They are building AI literacy, experimentation muscle, and the right foundation now, so they can scale what works later.

Two areas Ryan is especially bullish on

The first is voice AI.

Ryan’s reasoning here is very pragmatic. With coding assistants or general-purpose copilots, ROI is harder to pin down. With voice, it is often much clearer. Humans can only speak so many words per minute. If AI handles some of those minutes, the value is much easier to quantify.

More importantly, voice does not only replace labor. It enables new interactions that were previously too expensive to staff.

Ryan shared a great example of a behavioral treatment organization that automated initial recruiting conversations with voice AI. The impact was not just efficiency. They were able to run more interviews, keep human recruiters focused on the more valuable parts of the process, and improve outcomes.

That’s a big deal.

The second area is self-improving agents.

This one is especially exciting to me.

Ryan described a future where one agent does the work, another evaluates the trace, another improves the prompt or rules, and the system improves over time through usage. In other words, not just agentic systems, but systems that get better at being agentic.

We’re already starting to see the early versions of this pattern. I think we’ll see much more of it over the next couple of years.

And frankly, that is where things begin to get really interesting. Not when AI merely answers a question, but when it learns how to make its own future answers better.

So where is this all going?

Ryan does not believe AI is a bubble in the simplistic sense.

Sure, individual companies will go up, down, miss expectations, or disappear. Some categories will get overcrowded. Some valuations will correct. That’s startup-land. But the broader shift is not going away.

On that, I agree with him.

We are moving from co-pilots to colleagues. From tools that wait for a prompt, to systems that can take initiative, execute tasks, and eventually coordinate with other systems. Some of this will first happen inside enterprises. Some of it will show up in consumer software. But all of it will require better context, better data, and a lot more trust than most people realize.

That’s what made this episode fun for me.

Ryan brought the market view, but the takeaways were refreshingly grounded: most organizations are still in the middle, ROI is real but often messy, founders should pick the motion they can actually win, voice AI is much bigger than many think, and agents improving agents may become one of the most interesting product patterns of the next couple of years.

I thank Ryan for taking the time to join me on the podcast. You can learn more about him on SignalFire’s team page, read about Beacon AI, and check out the AI Circle community he mentioned in our lightning round.

Or - hop straight into the episode now: YouTube, Spotify, Apple.

I first saw Rittika Jindal speak at Gartner in Florida a little over a year ago. She was presenting OpenSETU, a data agent for non-technical users, and I remember walking out thinking: this is someone who is not treating AI like a demo. She is treating it like engineering.

That distinction matters more at Thomson Reuters than in most places. This is a company serving legal, tax, risk, compliance and journalism professionals. In those environments, the wrong answer is not just annoying. It can affect real work, real customers, and in some cases real lives.

One sentence from our conversation captured that bar perfectly:

“accuracy is the key.”

I think that line is worth sitting with for a minute, because it explains almost everything that came next in our conversation (available on YouTube, Spotify and Apple Podcasts).

Subscribe now

In high-stakes AI, accuracy is not a metric. It is the product

Rittika works in Thomson Reuters’ Content Innovation group, an R&D team focused on how content is processed, enriched and delivered into products used by professionals. In practice, that means building AI and agentic workflows into pipelines that need to be fast, scalable, and above all trustworthy.

That emphasis on trust strongly echoed what we heard in my recent conversation with Joel Hron, Thomson Reuters’ CTO. The setting is different, but the core idea is the same: when AI enters high-stakes workflows, you do not get to hide behind a cool demo. You need systems, guardrails, evaluation and clear accountability.

That is also why I liked Rittika’s framing of the problem so much. She did not talk about hallucinations as a quirky model behavior that we all laugh off on X. She talked about them as a product failure.

OpenSETU was a bridge, not a magic trick

The first project I knew Rittika for was OpenSETU. “Setu” means bridge in Sanskrit, which is a fitting name.

The idea was simple and powerful: let non-technical teams ask natural-language questions about their data, and have an agent translate those questions into Python or SQL, run the code, and return the result. In other words, bridge the gap between business users and the analysts they usually wait on.

But the interesting part was not the interface. It was the discipline behind it.

Rittika was very clear that the team did not stop at “the code runs, so I guess it works.” They built with ground truth from day one. They knew what correct answers looked like for representative questions, and used that to evaluate whether the agent was producing the right output.

This rhymes strongly with how we think about evals at Solid, and with a point I keep seeing across strong teams: if AI is part of the product, evaluation cannot be something you bolt on at the end. It has to be part of the design.

Or, as Rittika put it:

“We make sure that we have the ground truth data. We are evaluating whatever we are building, starting from day one.”

That is not flashy. It is also probably why her work feels real.

Then the job of software development moved

A lot of people still talk about AI in software as “the thing that writes code faster.” That is true, but it is also the least interesting part of the story.

What Rittika described is much bigger. Her team has moved from AI-assisted development toward AI-native engineering. The code-writing step is just one piece. AI is now involved across planning, coding, testing, debugging, observability and review.

The workflow she described was one of my favorite parts of the episode:

A developer starts by creating a plan document with AI. That plan gets reviewed by humans. It goes into GitHub. Then code gets generated against that plan. Before a PR is opened, an internal review skill checks the plan, code, tests and architectural alignment. After the PR is opened, a bot reviewer runs automatically and comments on what it finds. The developer then feeds those comments back into their coding agent and iterates. Only after that does the PR land in front of a senior engineer.

So yes, Claude writes code. But Claude also reviews Claude.

If you have been following Rittika’s writing, especially posts like How We Taught Claude to Review Claude and Reviewing AI Code at Scale: A Principal Engineer’s Dashboard, this pattern will sound familiar. What I liked hearing on the podcast is that this is not a thought experiment. It is how her team is actually working.

It also pairs nicely with what we wrote when Solid moved to an agentic platform and later on how we observe that system in production with LangSmith. Once your development process becomes more agentic, observability and evals stop being “nice to have.” They become part of the development loop itself.

Yes, teams are shipping more. No, that does not mean quality stops mattering

One of the more striking parts of the conversation was the sheer change in pace.

Rittika described a world where some repos that used to merge five or six PRs a week are now seeing much more than that every single day. In her words, “we are merging 5 to 10 PRs every single day.”

That kind of compression changes expectations fast. It also creates a fear that I hear from a lot of people: are we just generating more slop, faster?

Her answer was more balanced than the hot takes you usually see online. Yes, AI slop is real. Yes, dead code shows up. Yes, review gets harder. But humans were never exactly writing slop-free code either. The real question is whether the team has built the mechanisms to catch the things that matter: wrong business logic, broken architecture, lack of tests, poor observability, missing evals.

That is why I found her emphasis on testing, logs, and review so important. In her team’s world, the answer to faster code generation is not hand-wringing. It is a stronger system around the code.

The future engineer may look more like a software thinker

The part of the conversation that stayed with me most was not about tools. It was about roles.

Rittika argued that engineers are now spending much more of their time on planning and design, and less on manually typing code. The work is shifting upward. You ask better questions earlier. You decide what should be built, whether it should be built, how it should be evaluated, and how the workflow should be instrumented once it is live.

That sounds subtle, but I think it is a major shift.

It also echoes what we heard in my conversation with Meenal Iyer: the winning teams are the ones building foundations first, then experimenting hard, then moving into production with clarity about trust and business value.

Rittika took the idea one step further when we talked about junior engineers and the next wave of talent. Her point was that the people arriving now are more AI-native than the rest of us. They are not “adopting” AI. They barely know how to work without it. That will change not just how teams build, but who teams hire for.

She said, almost offhandedly:

“Maybe after five years we’ll hire software thinkers.”

Maybe that is too provocative. Maybe it is exactly right.

After hearing how her team works, it no longer sounds crazy to me. The scarce skill is moving away from typing syntax and toward framing problems, building evals, setting constraints, and deciding when humans need to stay in the loop.

What I took from the conversation

If I had to reduce the episode to four points, it would be these:

1. In high-stakes domains, accuracy is not a dashboard metric. It is the product.

2. AI-native engineering is not about faster code completion. It is about rebuilding the whole SDLC around plans, review, evals and observability.

3. Shipping more PRs only helps if your quality system gets stronger at the same time.

4. The software engineer role is shifting upward, from code producer to system designer, reviewer and decision-maker.

Rittika is one of the more thoughtful voices I have heard on this topic because she is not speaking in abstractions. She is building inside a high-bar environment, writing openly about the lessons, and grounding the entire thing in practice. Her Medium is worth following, and so is Thomson Reuters’ broader engineering transformation story. For people trying to level up quickly, I also liked her recommendation to start with the docs from the model companies themselves and with DeepLearning.AI.

And yes, it will surprise no one that the AI tool she said she cannot live without is Claude Code.

Want to hear the full episode? Check it out on YouTube, Spotify, and Apple Podcasts.

On March 25, we hosted a webinar on a topic I hear about almost daily: everyone wants AI on top of their data, but very few teams are fully happy with the results. I got amazingly positive feedback on it, and wanted to share with you.

I had the pleasure of leading the discussion with Meenal Iyer of SurveyMonkey and data leader Solomon Kahn. We spoke candidly about what’s working, what’s failing, and where data leaders should focus if they want AI to drive real value inside the enterprise.

If you’d like to watch the full webinar, you can do that here.

A few ideas stood out to me.

Subscribe now

1. AI literacy does not happen in a slide deck

One of my favorite parts of the discussion was Meenal’s story about trying to bring AI into her organization.

Her first instinct was a very reasonable one: train the team. Create an internal AI academy. Upskill people. Teach the concepts.

It did not work the way she hoped.

What did work was much more hands-on. She had the team do a mini AI hackathon, focused on real problems in their own workflows. Suddenly, the conversation changed. People were no longer thinking abstractly about models, prompts, or which tool was hottest that week. They were thinking about friction in their day-to-day work, and whether AI could actually remove it.

That shift matters.

I keep seeing the same pattern across companies: people understand AI much better once they build with it. Not when they hear about it. Not when they read another thought piece on LinkedIn. When they actually try to solve something with it.

This is also very much in line with what I wrote in Building an AI-powered Intelligent Enterprise, where I shared more of Meenal’s broader journey and how her team has been evolving from experimentation toward production.

2. The problem is not “the data” alone. It’s the missing context around it

Another major theme in the webinar was one I think many teams learn the hard way.

You cannot just put a GPT on top of a dataset and expect magic.

Even if the dataset is clean.
Even if the columns are named well.
Even if there is a semantic layer underneath it.

That still does not mean the AI understands the business.

It does not know the internal logic behind the metrics. It does not know which edge cases matter. It does not know which definitions changed last quarter, which exceptions live in Confluence, which nuance is buried in Jira, or what your executives actually mean when they use a certain term.

Without that context, AI fills in the blanks on its own. That is where hallucinations and bad decisions start showing up.

This connects directly to what I wrote in “Sorry for the mess”. Enterprise data is messy. Everyone’s is. The answer is not to wait for some mythical moment where everything is perfectly documented and pristine. The answer is to build systems that can understand the reality of how businesses actually work.

3. “100% accuracy” is usually the wrong conversation

A big part of the Q&A ended up centering on accuracy, and understandably so.

If an AI system is 92% accurate, what do you do with the other 8%? Can you trust it? Should you use it for decision-making? Is that good enough?

My view is that we often hold AI to a strange standard.

Human analysts are not 100% accurate either. In many cases, they get to a high-confidence answer through back-and-forth, clarification, validation, and iteration. AI should be judged with similar realism. Not every use case requires perfection. Some do. Many do not.

The more useful question is: what is the use case, what is the risk, and what level of validation is needed?

For financial reporting, compliance, and tightly audited workflows, you still want highly controlled systems and dashboards. For exploratory work, data literacy, pattern finding, and helping people navigate large datasets, AI can already be very valuable even if it is not perfect.

That is one of the reasons I still believe throwing away BI is a bad idea. AI and BI should work together. One is not replacing the other anytime soon.

During the conversation I also brought up Waymo’s safety work as an analogy. The standard is not “never make a mistake.” The standard is whether the system performs well enough, consistently enough, in the context it is being used for.

4. Data leaders should be measured on business impact, not just on perfection

Solomon made a point that I think many data leaders feel deeply.

Data teams are often only noticed when something is wrong.

When the number is right, silence.
When the dashboard works, silence.
When the business gets what it needs, silence.

But when something breaks, or a metric is off, or an answer is confusing, that is when everyone suddenly remembers the data team exists.

That is a very hard way to operate.

The better framing is business impact. Are you helping the organization close deals, reduce churn, improve workflows, support better decisions, and move faster with more confidence? That is the real scoreboard.

This also ties back to something I wrote last year in Nobody cares about the efficiency of the data analyst. Efficiency is nice. Happier analysts are nice. But the main thing the business cares about is results. If AI helps deliver those results, people will forgive a lot. If it does not, no amount of cleverness will save it.

5. Start small, but start

The closing advice from the panel was refreshingly practical.

Do not boil the ocean.

Start with a smaller domain. Start with a use case where the data is relatively well understood. Start with a workflow where the upside is clear. Let people experiment. See what breaks. See what works. Learn quickly.

There is far too much pressure right now for companies to show they “have an AI strategy.” That pressure often creates giant top-down initiatives that look impressive in a deck and disappoint in reality.

A smaller, grounded, iterative approach is much less glamorous. It is also much more likely to get you somewhere real.

Final thought

If there is one message I would want people to walk away with, it is this:

Enterprise AI is not struggling because there is not enough excitement. It is struggling because real business data is nuanced, fragmented, and deeply contextual.

The teams that succeed will not be the ones with the flashiest demo.

They will be the ones that help AI understand how their business actually works, earn trust over time, and stay relentlessly focused on business outcomes.

Thanks again to Meenal and Solomon for such a sharp and honest discussion.

If you missed the webinar, you can watch it here. And if you want more on Meenal’s journey, this earlier post is a good place to start.

First, kudos to Jason Cui and Jennifer Li for their a16z post, Your Data Agents Need Context.

It’s a strong piece. More importantly, it puts the conversation in the right place.

A lot of the market still talks about data agents as if this is mainly a model problem. Better reasoning, better SQL generation, better interfaces, and suddenly everyone in the business can ask whatever they want and get back a trustworthy answer.

That’s not the main blocker.

Jason and Jennifer make the important point: the real blocker is context.

Not generic context. Real business context. Which definition of revenue is the right one. Which dashboard people actually trust. Which table is technically available, but should not be used. Which metric changed meaning last quarter. Which exception “everyone knows,” but no system has ever written down.

This is exactly why, in Data Chatbots: what people are really doing, I argued that enterprise data is not just a SQL problem. Every company has its own business language, and often multiple business languages. The model is not just translating English into SQL. It is trying to navigate an organization’s internal logic.

That is much harder.

Subscribe now

Context is the problem. Static context is the trap

Where I’d push the a16z argument a step further is this:

Context is necessary. But static context is not enough.

Most enterprise context is messy. It lives across BI tools, dbt models, semantic layers, dashboards, documentation, tickets, query history, Slack threads, and people’s heads. Some of it is useful. Some of it is stale. Some of it conflicts with other pieces. Some of it was right six months ago and wrong today.

That’s why I keep coming back to a simple point: everyone’s data is messy. No one has perfect documentation. No one has a fully clean warehouse. No one has a beautifully maintained source-of-truth map that always reflects reality.

And that’s okay.

The mistake is thinking the answer is to pause everything and go build a pristine context layer by hand.

That sounds good in theory. In practice, it can turn into the next documentation project that starts with great intentions and slowly falls out of date. We’ve seen this before in catalogs, governance projects, and semantic initiatives. It’s also why I think Tal’s point in Semantic layer for AI: let’s not make the same mistakes we did with data catalogs is so important: if humans have to manually maintain every part of the system forever, the system usually loses.

So yes, agents need context.

But the bigger requirement is that context has to keep up with a real business. New product lines get added. Definitions shift. Dashboards become stale. Teams change how they operate. The “trusted” table from last year may no longer be the one finance relies on today.

If your context layer cannot adapt to that, it is not really a context layer. It is a snapshot.

Enterprises already have more context than they think

The good news is that companies are not starting from zero.

A lot of their context already exists inside the work they’ve done over the past decade. It’s embedded in BI, in semantic models, in modeling layers, in warehouse metadata, and in query patterns. It may not be organized perfectly, but it’s there.

That’s one reason I wrote Throwing away BI is a Bad Idea. There is this temptation right now to act as if AI will replace everything that came before it. I think that’s the wrong frame.

Your BI stack contains years of accumulated business logic. Your dashboards, LookML, dbt models, Power BI reports, Tableau workbooks, and saved queries all encode decisions the organization has already made. Not perfectly, of course. But they are still among the highest-signal assets you have.

The right move is not to discard those systems.

It’s to extract from them.

That’s also why posts like Autogeneration of a semantic layer - the key for AI/BI and Data, Meet Business: Why You Need JIT Semantic Models, Instead of a Static Semantic Layer resonate so much with what Jason and Jennifer are saying. The market does need context. But it needs context that can be built and refreshed from the assets companies already have, not just from a manual curation exercise.

My takeaway

So my takeaway from the a16z post is pretty simple:

They are absolutely right that data agents need context.

I’d just add that context also needs infrastructure. It needs a way to be generated, refined, corrected, and updated without depending on humans to keep every rule and every definition perfectly current by hand.

That is the harder challenge.

And that, in my opinion, is where the next real wave of value will be created.

This is not some far off vision of how analytics might work one day. It is a pretty good description of what we are already building and deploying with customers.

And if you want a concrete example, we have a public case study with SurveyMonkey that shows these ideas in production today:
SurveyMonkey x Solid Case Study

Subscribe now

What Gartner actually means by “agentic analytics”

Let me translate the report into four simple ideas.

1. Start from specific, repeatable scenarios

Agentic analytics is not “ask anything in a chat box.” (we already discussed how that’s not an important use case)

The successful patterns start from well defined, high value workflows, for example:

• Weekly business reviews

• Account health and renewals

• Campaign performance

• Operational anomaly detection and follow up

These are things that already happen, on a schedule, with some manual collection of numbers and spreadsheets.

Gartner’s point is that you get real value when agents make these workflows faster and better, not when you show a cool one time demo.

2. Semantics and policy are the foundation

The report is very clear. If you point agents at raw tables and column names and hope they “figure it out,” you are going to get confident nonsense.

Organizations that succeed:

• Invest in semantic layers, ontologies and knowledge graphs for their important domains.

• Align metric definitions across tools, dashboards and teams.

• Make sure agents and models are grounded in that shared layer.

In Journey we have been calling this the “context layer” between your warehouse and your AI. Posts like “The Two Souls of a Semantic Layer” and “Behind the scenes: how we think about semantic model generation” are basically a deep dive on this point.

3. Human and AI roles need to be explicit

Gartner spends a lot of time on delegation, escalation and human review.

The questions they ask are simple:

• Which tasks can an agent do alone?

• Which tasks must always be reviewed by a human?

• When should an agent suggest rather than act?

The answer will be different for forecasting revenue, sending emails to customers, or building a one off dashboard for a team. The key is to make the rules explicit instead of letting each team invent its own.

4. Governance and cost are first class

Agentic systems can run expensive queries and call expensive models.

That means you need:

• Observability into what agents are doing.

• Guardrails around which data they can touch.

• Controls on how much they can spend for a given type of insight.

Gartner talks about this as managing the “cost per useful insight” rather than just tracking model usage. It is a good mental model.

So that is the theory. Now let us talk about how Solid is positioned inside that world.

How we position Solid in the agentic analytics landscape

When people ask what Solid is, I usually describe it like this:

Solid is the context layer between your data and your AI systems.

More concretely, Solid:

• Learns semantic models automatically from your warehouse, query history, BI and other sources.

• Keeps those models governed, tested and up to date as things change.

• Exposes that logic through APIs and MCP so that any agent, LLM or workflow can use it.

This is not a generic chatbot. It is an an enabler for all of your AI projects - those that leverage your structured data.

Here is how that maps to Gartner’s four themes.

Semantic foundations, automated

We agree with Gartner that semantic and policy alignment is foundational. The problem is that almost nobody has time to build and maintain a semantic layer manually.

That is why Solid:

• Mines query logs, BI dashboards and recurring reports to see how the business already uses data.

• Auto generates candidate semantic models that reflect real joins, metrics and entities.

• Lets humans review and refine those models instead of starting from a blank file.

We wrote about this in “The Ghost in the Machine: How Solid drastically accelerates semantic model generation” and in “End-to-end: generating semantic models for Snowflake Cortex Analyst/Intelligence in two weeks”.

The result is very similar to what Gartner describes: a selective semantic layer for the most important domains, aligned with how the business actually works.

Analysts first, “AI for everyone” second

In “Stop saying ‘Garbage In, Garbage Out’, no one cares”, we argued that the business will not wait until all your data is perfect before they try AI. You need a safe way to get value now and improve quality over time.

Our approach is to start with the analysts and data team:

• Give them an AI copilot that understands their warehouse and their metrics.

• Let them supervise and correct what the AI does.

• Only then open up the same capabilities to broader audiences in a governed way.

This is very close to Gartner’s picture of humans as supervisors and orchestrators of agentic systems rather than bystanders.

Embedded, not “sidecar chat”

The value of a “chat with your data solution” is extremely limited. That should NOT be your goal.

Solid is designed to show up where work is already happening:

• Inside recurring analytics rituals like QBRs and weekly reviews.

• Right next to existing BI tools and documents.

• Triggered by events in the data, not only by user questions.

This maps to what Gartner calls conversational and perceptive analytics. We just think of it as embedding AI where it can actually help people do their jobs.

How we run pilots in an “agentic” way

The other part of the Gartner guide that felt familiar was their advice to “start with concrete scenarios” and “treat pilots as the first step toward production, not proofs of concept.”

That is almost exactly how we run pilots.

1. Pick one high value, bounded scenario

We never start a pilot with “ask anything about your data.”

We start with something like:

• Help marketing run weekly campaign reviews without manual data collection.

• Give customer success a reliable view of at risk customers before renewals.

• Make it trivial for product managers to answer their five most common usage questions.

These scenarios have three things in common:

• They happen all the time.

• People are already doing them, but with a lot of manual effort and spreadsheets.

• There is clear business value in making them faster and more reliable.

This is very close to Gartner’s advice to anchor agentic analytics initiatives in specific analytical scenarios and measure cycle time and quality of decision, not just “AI usage.”

2. Build the semantic slice that matters

Once we have a scenario, we narrow down the data to the actual slice that powers it.

Solid then:

• Learns from historical queries and dashboards which tables and joins really matter.

• Proposes a semantic model with the relevant entities, metrics and relationships.

• Generates human readable documentation so business stakeholders can sanity check it.

You do not need a company wide semantic layer on day one. You need a good semantic model for the scenario in front of you, that can then grow step by step.

3. Define human and AI roles up front

Before any agent does anything beyond drafting and suggesting, we agree with the customer on clear guardrails.

For a given workflow we decide:

• What the agent is allowed to do automatically.

• What requires explicit human approval.

• What the agent is not allowed to touch at all.

For example:

• An agent may be allowed to draft commentary for a business review slide, but not to send that slide to an executive without someone reading it.

• An agent may flag unusual patterns in the data, but not create or modify alerts in production systems.

• Anything that touches pricing, discounts or regulated metrics always goes through human review.

This is our practical version of the delegation and escalation frameworks Gartner describes.

4. Measure outcomes, not just demos

Finally, we define what success looks like in terms that matter to the team.

Typical success metrics include:

• Reduction in analyst time spent on repetitive requests.

• Faster turnaround for key decisions (for example weekly reviews prepared in hours instead of days).

• Fewer “shadow” spreadsheets and one off queries.

• Reuse of the semantic model in new workflows after the pilot.

The goal is that a pilot creates a durable asset, not just a one time demo. The semantic models, guardrails and workflows we build in the first month are designed so that they can power the next set of use cases.

A quick example from the field

One short quote from our public case study captures the spirit of what “agentic analytics” feels like when it works.

In that case study, Meenal Iyer says:

“Our goal is for AI to remain dependable,” Meenal explained. “Teams should be able to use it with confidence, knowing the answers reflect how the business actually works.”

This is exactly why we care so much about semantics, governance and human in the loop design. Agentic analytics only matters if teams can depend on it.

If you want to see the full story, including the impact on accuracy, time to production and maintenance, you can download the case study here:
Download the case study

Where we are going next

Gartner also talks about “perceptive analytics” and agents that:

• Monitor events and changes continuously.

• Understand goals and constraints.

• Adapt their behavior based on feedback.

In this blog we explored similar ideas in “Vibe Analytics: The new era of data experiences”. The short version is that we want AI to feel less like a tool you occasionally consult and more like a reliable colleague who taps you on the shoulder when something important happens.

A lot of our current roadmap is about:

• Learning not just from schemas, but from how people actually use data over time.

• Bridging the “two souls” of the semantic layer, so that governance and insight are not in conflict.

• Making it easy for customers to go from one well defined scenario to a network of agentic workflows that reuse the same trusted foundation.

If you care about agentic analytics, here is what I would do next

If your leadership is asking “What is our agentic analytics strategy?” or “How do we move beyond pilots?”, here is a simple plan.

1. Read the Gartner Market Guide
   Grab it here and read it with your own organization in mind:
   Analyst Report: Gartner Market Guide for Agentic Analytics

2. Read the case study in parallel
   Look at how the ideas in the report show up in a real deployment:
   SurveyMonkey x Solid Case Study

3. Skim a few Journey posts to see how we think about this internally
   For example:

   • “AI for AI: how to make ‘chat with your data’ attainable within 2025”

   • “Behind the scenes: how we think about semantic model generation”

   • “(Almost) no AI in production”

You will see the same themes repeated again and again.

Start from concrete scenarios.
Invest in semantics where it matters.
Keep humans in the loop by design.
Treat governance and cost as product features, not afterthoughts.

That is what Gartner calls “agentic analytics.” For us, it is just how we build. We’d love to hear from you.

Contact Solid

The dream: anyone can ask anything

If you spend even a few minutes on LinkedIn these days, you will see some version of the same pitch:

“Imagine every business user in your company can just chat with your data.”

The demo is always similar:

• Someone opens a chat window

• Types “What were Q4 revenues in EMEA versus target?”

• A nice chart pops up

• Everyone nods. “This is the future.”

I get why this is compelling. We have spent a decade building dashboards, training people on BI tools, arguing about metric definitions. The idea that we can put a natural language interface in front of all of that, and suddenly “everyone becomes data driven”, is very appealing.

We have written before about why enabling this is so hard on the technical side, from Text2SQL accuracy issues in “Everyone wants Text2SQL, but the pros don’t trust it” to the heavy lifting needed in “Semantic layer for AI: let’s not make the same mistakes we did with data catalogs”.

This time I want to focus on something else:

Even if you solve all the technical problems, “chat with your data” has two very real business problems.

Subscribe now

Problem 1: usage is not ROI

When companies roll out a “chat with your data” experience, here is what they tend to measure:

• How many people tried it

• How many questions they asked

• How often they came back

• Satisfaction scores like “this answer was useful”

All of those are fine. None of them are ROI.

It is very hard to answer questions like:

• Did this chat experience help us win more deals?

• Did it reduce churn?

• Did it increase revenue per customer?

• Did it reduce cost per ticket in support?

You can say “Marketers now get answers faster” or “Sales can self serve their questions”, but that is not the same as proving material business impact.

We see a similar pattern to what we saw with early BI rollouts:

1. A big launch, internal roadshow, a few great demo moments

2. A couple of power users adopt it seriously

3. Everyone else goes back to:

   • Asking the same data people in Slack

   • Looking at the same dashboards as before

   • Exporting to Excel

You can show a nice adoption chart. You can say “we had 3,000 questions asked this quarter”. But when the CFO asks “What did we get for this?” it is very hard to go from “3,000 questions” to “X million dollars”.

That is not a problem unique to AI. It is the same problem BI has had for years. The difference is that with AI, the expectations are much higher.

Problem 2: after the novelty, no one knows what to ask

The second pattern we keep hearing in conversations with data and analytics leaders is even more worrying:

“The first month, people played with it. After that, usage dropped. People did not know what to do with it.”

We saw a similar behavior in the work behind “When users don’t chat with your chat”. Most users are not “trained” to interact with AI in a rich, structured way. A typical prompt is closer to a search query than to a thoughtful analytical question.

In practice that looks like:

• “Show me sales last month”

• “Top 10 customers”

• “Pipeline by region”

Those are fine questions, but they are not very far from what you already had in dashboards or reports. And once people have tried a few of these, they hit a wall:

• They do not know how to decompose fuzzier questions

• They are not sure what the system “knows”

• They do not want to get something wrong in front of their manager based on a chat answer

So they fall back to the pattern they trust:

• Open the dashboard that “everyone uses”

• Ask an analyst to “just pull something for me”

• Copy paste into a deck

Chat becomes another tool they occasionally open, not something that fundamentally changes how the business runs.

Why this is happening: chat is a pull interface

If you zoom out, there is a structural reason for this:

Chat is a pull interface. It relies on the human to:

• Notice there is a question worth asking

• Translate it into words the system understands

• Decide what to do with the answer

• Then go and do the work

That is a lot to ask from already overloaded business stakeholders.

The people you are most excited to “put AI in front of” are usually the ones with the least time and attention. They are managing teams, customers, numbers. Asking them to become “prompt engineers” on top of that is not realistic.

So you get:

• Some cool one off wins

• Good internal marketing material

• But not a durable change in how decisions are made and work gets done

Which leads to the core point of this post:

The real promise of AI on structured data is not “chat with your data”. That is a nice bonus. The real promise is agents that take work off people’s plates.

What agents do that chat never will

When I say “agents”, I do not mean a fancy wrapper around chat that calls a few tools. I mean systems that:

• Run on a schedule or trigger from events

• Pull from multiple sources:

  • Data warehouse and metrics

  • Product events

  • CRM

  • Support tickets

  • Even free text notes

• Apply reasoning and business logic

• Make a decision or propose one

• Then take action in the real systems of record

Some concrete examples.

Marketing budget reallocation

Instead of a marketer asking “How did Campaign X perform?”, an agent:

• Monitors performance of all campaigns

• Understands targets for CAC, LTV, and budget constraints

• Spots under performing campaigns and over performing ones

• Proposes a reallocation plan in the marketing tool

• Either executes it automatically, or prepares it for one click approval

Now the ROI is clear:

• Improved ROAS

• Faster reaction time

• Less manual spreadsheet work

Sales pipeline hygiene

Instead of a sales manager asking “What is my real pipeline?”, an agent:

• Scans open opportunities

• Cross checks product usage, email activity, last touch, win rates

• Flags deals that are clearly stale

• Updates fields, nudges reps, or creates summary views for forecast

Again, ROI is measurable:

• Forecast accuracy

• Time saved in pipeline review meetings

• Higher win rates because teams focus on the right deals

Support and product feedback loop

Instead of product managers asking “What are customers complaining about?”, an agent:

• Reads tickets, call transcripts, NPS comments

• Clusters them into themes

• Ties those themes to product areas, customer segments, and revenue

• Proposes a prioritized backlog and shares it with the team

Here the ROI is:

• Faster detection of issues

• Reduced churn

• Better prioritization

Notice what is common across all of these:

• No one typed a prompt

• The agent started the interaction

• Humans are in the loop for judgment and approvals, but not doing the mechanical work

In “Solid’s Leap to an Agentic Platform” we shared how we are reorienting our own product around this kind of behavior, not just a smarter chat window on top of the warehouse. That shift in architecture is what unlocks these use cases.

Why agents make ROI obvious

If you build the right agents, the ROI conversation becomes much simpler and much faster.

Instead of talking about value over “the next 18 to 24 months”, you can ask:

• In the next 1 to 3 months, how much time can we save per week for this role?

• In the next quarter, how many errors can we avoid?

• How much faster can we react to key events once an agent is in place?

• What measurable uplift in revenue or margin do we expect if we react in days instead of quarters?

You can usually tie that to:

• Reduction in manual steps

• A measurable change in a metric

• A clear before and after comparison on a specific workflow

You do not have to convince anyone with “We had 3,000 chats this month”. You can show:

• “We recover 2 percent more revenue on renewals because at risk customers get flagged and handled earlier.”

• “We uncovered 5 percent more business opportunities that are high quality.”

• “We cut time to resolution by 25 percent on a certain ticket type.”

That is a different level of conversation with your CFO or CEO.

Validating the quality of what agents actually do

There is a catch. Once agents are doing real work, they also have real power to mess things up.

So there are two questions you have to answer at the same time:

1. Are we getting business outcomes?

2. Is the agent’s behavior reliable enough that we trust it on those outcomes?

That is where evals and benchmarks come in.

In our post on how we do evals for Solid’s chat, we talked about building a proper evaluation harness instead of relying on “it feels good in the demo”. The same idea applies to agents, but the bar is higher.

A good agentic platform should let you:

• Define representative tasks
  Real prompts or events that mirror how the agent will be used in production. Not toy examples.

• Specify what “good” looks like
  Ground truth outputs, constraints, and checklists. For agents this can include not only the final answer, but also which tools they should or should not touch.

• Run benchmarks continuously
  Every time you change a model, a tool, a prompt, or business logic, you rerun the benchmark and see what got better and what regressed.

• Track the right metrics
  Inspired by the metrics we use for chat evals:

  • Accuracy: did the agent take the correct action, on the right entities?

  • Consistency: do we get similar behavior across similar scenarios?

  • Latency: is it fast enough for the business context?

  • Cost: are we comfortable with the per task cost at scale?

  • Safety and governance: did it respect permissions and policies?

Most serious agentic platforms are now building some flavor of this. If you are evaluating tools, I would put “What is your eval and benchmarking story?” very high on the list of questions.

Without this, you are left with anecdotes, screenshots, and a lot of “seems fine”. With it, you can treat agents like any other production system: you ship, you measure, you improve.

So is “chat with your data” useless?

No. It is useful, but you have to put it in its proper place.

Here is how I would think about it:

• Nice bonus, not the hero feature. Chat is great for exploration, long tail questions, and debugging. It is not where your big business outcomes will come from.

• Power tool for experts. Analysts and data savvy users can use chat to move faster, prototype, and inspect. But they are a small portion of your total user base.

• Support tool for agents. Agents will sometimes need to “explain themselves”, show their work, or help a human dive deeper. Chat can be the interface for that.

If you start with chat as the core story, you end up optimizing for demos that impress in 3 minutes. If you start with agents and real workflows, you optimize for systems that deliver clear value in the next quarter and keep delivering after that.

How to shift your roadmap from chat to agents

If you are a data and analytics leader planning your next couple of quarters, here is a simple way to reframe.

1. Start from business workflows, not from data access.
   Pick two or three high value workflows where:

   • The inputs are mostly digital and visible

   • Decisions are repeatable

   • There is clear business ownership

2. Map the “last mile” to action.
   For each workflow:

   • Who actually clicks the buttons today?

   • In which systems?

   • What information do they look at before deciding?

3. Design the agent as the “doer”, not just the “answerer”.
   The agent should:

   • Monitor conditions

   • Propose actions with reasons

   • Execute in systems of record, with audit and guardrails (with or without human-in-the-loop)

4. Bake in evals from day one.
   Before you roll out widely:

   • Build a small but sharp benchmark set for the workflow (Solid automates this for you)

   • Decide which metrics matter most (accuracy, safety, speed, cost)

   • Make every change to the agent go through this benchmark
     We learned this discipline the hard way on our own chat engine, and captured some of it in “The curse and promise of the white box”.

5. Add chat around the edges.
   Once the agent exists, surround it with:

   • Chat for “why did you do this?” explanations

   • Chat for “can you also do X?” refinements

   • Chat for analysts to debug and improve behavior

6. Measure the right things fast.
   Track:

   • Outcomes (revenue, cost, speed, quality) every week or month

   • Volume of work automated

   • Human time saved for the specific team
     Use “number of chats” only as a secondary signal, not the headline.

If you do this, “chat with your data” becomes part of a bigger, agentic strategy instead of the main show.

If you are evaluating vendors, or designing your own internal platform, I would encourage you to ask a different question:

“Over the next 3 to 6 months, what real work will AI be doing for our business, how will we know it is working, and how will we know it is working reliably?”

If the answer revolves mostly around a chat window, you are probably leaving most of the value on the table.

I kicked off Season 2 with Todd James. Todd has the kind of resume that makes you wonder if this guy is real: Coast Guard officer, Deloitte, 15 years at Fidelity, then leading data and AI at Kroger and 84.51°, and now running Aurora Insights, where he works directly with boards and executive teams on turning AI into real enterprise value.

I can assure you, he is real.

This episode had so much great content, we had to split it into two parts. Today, we’re sharing Part One - available on YouTube Spotify and Apple Podcasts.

Below are the ideas I keep thinking about, plus a few practical takeaways if you are trying to make AI matter in a real organization.

Subscribe now

1) The line that should kill most AI roadmaps

Todd said it in a way that simplifies what we’ve heard before:

“It’s not AI. It’s transformation enabled through AI.”

If you want to “play around with AI,” Todd’s point is that anyone can do it. You can fund pilots, do proof-of-concepts, and declare victory. But if you want material outcomes, including real EBITDA contribution, you are changing how the business operates.

That shift is why a lot of programs stall. A pilot can live in a corner. Transformation cannot.

This connects to a theme we’ve written about before on Journey: efficiency stories often feel good internally, but they rarely map cleanly to the P&L without operational change. If you missed it, this one is the blunt version: Nobody cares about the efficiency of the data analyst.

2) The 70/30 rule of enterprise AI

One of Todd’s most practical frameworks is how a senior data and AI leader should spend their time.

Roughly:

• 30% on the technical and programmatic mechanics

• 70% on the organizational dynamic: business alignment, incentives, trust, mobilization

I truly think most people don’t realize that’s the true ratio for success. It can sound weird, but it tells you what the job actually is.

A lot of leaders still treat AI as an engineering upgrade. Todd treats it as an operating model upgrade that happens to use AI.

3) Fragmented analytics is the silent killer of “strategic AI”

Todd talked about walking into environments where analytics is everywhere, and value is nowhere.

Not because the people are bad. Because the system is bad:

• Teams are embedded and optimized locally

• Prioritization is fragmented

• Definitions are inconsistent

• “Impact” is measured inside the analytics org, not in the business

If you have this setup, AI will not fix it. AI will amplify it.

This is also why the “chat with your data” wave is simultaneously inevitable and underwhelming. If the underlying data reality is messy, the chatbot just makes it easier to generate confident nonsense.

We’ve hit this from a few angles on Journey:

• Data Chatbots: what people are really doing

• Vibe Analytics: the new era of data analysis?

• Stop saying “Garbage In, Garbage Out”, no one cares

The common thread is the same: AI is an interface. The hard part is the system underneath.

4) Centralizing is not the hard part. Proving it works is.

Todd described reorganizing analytics in a way that will feel familiar to anyone who has tried to centralize talent.

There is always a moment where leaders feel like something was taken away from them. They lost “their” analysts. They lost control. They lost speed.

So Todd framed it as a race: reorganize quickly, then demonstrate that the leaders who “lost resources” will get better outcomes through the new model.

This is one of those dynamics that sounds obvious, but almost nobody treats it with the urgency it deserves. If you centralize and take a year to show impact, you will be reversed.

5) A perfect story about humans and automation: “I manage a micro bot.”

Todd told a story from a deployment where they involved the people who would actually be impacted (which is, by the way, a rare and crucially important move).

One woman told him:

“I used to be a transaction processor. Now I manage a micro bot. It makes me better. I make it better. And I get to do more of what I really love, which is creating great experiences for our customers.”

That is the actual win condition for most enterprise AI.

Not “we replaced a team.”
Not “we reduced headcount.”
Not “we automated analysis.”

It is: people move up the value chain, and the organization redesigns the work so that improvement compounds.

It also ties to a point that came up through the episode: as agents get real, more people will become managers of AI units. If your system is not legible, if it is a black box, nobody will trust what they are managing.

6) “AI is just another club in the bag”

Todd had a great metaphor I think more leaders should adopt:

“AI is no different. It’s just another club in the bag.”

Meaning: stop treating AI like a religion. It is a tool. A powerful one, yes. But still a tool.

The practical implication is important. You should not start with “where can we use AI?” You should start with “where does the business get stuck, where are decisions bottlenecked, and where is judgment repetitive enough that prediction helps?”

If your AI strategy starts with the model and ends with the business case, you are going to have a lot of demos and very few outcomes.

7) Why 84.51° could move fast (and why most incubations die)

I asked Todd about 84.51° and why it exists as a separate entity from Kroger.

First, the fun fact:

“It’s Longitude of Cincinnati. Think longitudinal analysis.”

Second, the more important insight: he explained why you do not “plant it in the mothership.”

“The last thing in the world you do is plant that in the mothership and put it on the core platforms and make it part of the corporate hierarchy. It’ll fail quickly.”

This is one of those quotes that should be printed and taped to the wall of every “AI Center of Excellence.”

If your “fast team” is forced to inherit the slowest platform constraints, governance cycles, and decision latency of the core enterprise, it will become slow too. Separation is not a branding choice. It is a survival choice.

8) The investor litmus test: “revenue per employee”

Near the end, Todd shared something interesting: investment analysts are trying to tell who is real about AI versus who is just talking about it.

One metric they are watching is “revenue per employee,” with the logic that real transformation should show up as either more sales or more efficiency per unit of sales.

I like this as a forcing function, but it comes with obvious caveats (you can “improve” it by cutting headcount). The point is not that it is perfect. The point is that serious stakeholders are trying to measure reality, not vibes.

This is also a nice reminder: if you cannot explain your AI program in the language of outcomes, someone else will ask the question for you.

A practical checklist I pulled from this conversation

If you are trying to get AI out of the pilot phase and into “this changed how we operate,” here’s what I would pressure-test:

1. Is the CEO meaningfully involved? Not “supportive,” involved.

2. Do we have 1-3 business outcomes we are willing to reorganize around?

3. Do we have a prioritization mechanism that business leaders trust?

4. Can we prove impact quickly enough to survive the org immune system?

5. Are the people impacted involved early, not after the build?

6. Is the system legible enough that humans can manage the automation?

If the answer to most of these is “not really,” the good news is you can still do pilots. The bad news is you should stop pretending pilots equal transformation.

If there’s one meta-takeaway from this episode, it’s this: most organizations do not need a better model. They need a better willingness to change.

That is what “transformation enabled through AI” actually means, and Todd is one of the few who knows it.

Last month, one of our backend developers changed the spacing on a dashboard component, adjusted a button’s border radius, and updated a tooltip’s copy - all without opening an IDE, cloning the repo, or asking a frontend developer for help. He wrote a Jira ticket, added a label, and came back twenty minutes later to a Pull Request with a live preview deployed.

This isn’t a hypothetical. It’s a system we built incrementally over a few weeks using GitHub Actions, the Cursor CLI, and a handful of Python scripts. We call it the Coding Agent.

The motivation was simple. At Solid, our frontend team is small. They should be spending their time on architecture, performance, and complex features - not context-switching to nudge a padding value by 4 pixels because someone on the product team noticed it was off. Those changes are real work, but the overhead of the *process* (local setup, find the file, lint, branch, PR) dwarfs the actual edit. We wanted to eliminate that overhead entirely.

Here’s how we built it, one workflow at a time.

Subscribe now

Step 1: A Manual Workflow That Proves the Concept

We started simple. Really simple. The first version was a single GitHub Actions workflow with a workflow_dispatch trigger - meaning you had to go to the GitHub Actions UI, click “Run workflow,” and manually type in a Jira issue key and branch name.

Glamorous? No. But it let us validate the core loop:

1. Extract the Jira issue. A Python script (extract_jira_issue.py) calls the Jira REST API, pulls down everything - summary, description (parsing Atlassian Document Format into readable text), comments, attachments, metadata - and writes it to a structured directory as both JSON and a human-readable Markdown file.

2. Feed it to the Cursor agent. We install the Cursor CLI in the runner and invoke it with a prompt that points at the extracted issue info.

3. The agent has full access to the repository, reads the ticket, figures out which files to change, and makes the edits.

4. Lint, commit, and push. After the agent finishes, we run our linter to clean up any formatting issues, then commit everything to a new branch and push.

5. Deploy to a preview environment. We call a reusable workflow that deploys the branch to a temporary frontend deployment named after the Jira ticket (e.g., RND123). This gives each ticket its own isolated preview URL.

6. Create a Pull Request. The workflow creates a PR titled RND-123 - [Coding Agent] - Fix sidebar spacing, with the Jira ticket link, the issue summary, the agent’s implementation summary, and the deployment URL all in the PR body.

7. Notify. A Slack message goes out with the status, Jira link, PR link, and deployment URL.
   

Even this minimal version was immediately useful. A backend developer could go to GitHub Actions, type RND-456, and ten minutes later have a PR with a live preview ready for review. No local environment needed. No frontend developer interrupted.

Step 2: Triggering From Jira With a Label

The manual workflow proved the concept. Now we wanted to meet people where they already work: Jira.

We set up a Jira webhook that fires a GitHub repository_dispatch event whenever the coding_agent label is added to a ticket. The payload is minimal - just the issue key:

On the GitHub side, we created a new entry-point workflow: coding-agent-event-dispatch. This workflow listens for the repository_dispatch event.

Its job is to be the router. It validates the Jira issue key, derives a deterministic branch name ({JIRA_KEY}-Coding-Agent), checks whether that branch already exists on the remote, and then calls the appropriate downstream workflow.

If the branch doesn’t exist, it calls the initial commit workflow to create it. This is the same workflow from Step 1, but now it’s also a reusable workflow_call - it can be triggered both manually and programmatically.

And once the PR is created, a Python script (add_jira_comment.py) posts a comment back on the Jira ticket with a link to the PR. So the person who added the label gets notified right inside Jira that the agent has done its work.

Now the flow became: open Jira ticket, describe the change, add coding_agent label, continue working on meaningful tasks, get notified the flow finished, and come back to a PR with a live preview when you can. No GitHub Actions UI needed. This allowed our product managers and our designers to implement small changes immediately, without knowing how to code.

Step 3: The Fix PR Flow - Making the Agent Iterative

A coding agent that only gets one shot at a change isn’t very useful in practice. The first implementation is often close but needs adjustments. Maybe the agent used the wrong shade of gray. Maybe it changed the right component but missed a second instance.

The traditional workflow would be: reviewer leaves PR comments, frontend developer reads comments, makes fixes. We wanted the agent to handle that loop too.

We built a second reusable workflow: coding-agent-fix-pr. Instead of creating a new branch, this one checks out the existing branch, gathers all the context it needs, and gives the agent a second (or third, or fourth) pass.

The context-gathering step is more sophisticated than the initial flow. The fix workflow:

1. Downloads previous state from our cloud storage. We persist all the agent’s working files (issue info, plan, summary, handled comments) to our cloud storage between runs. This way the agent doesn’t lose its memory between workflow executions.

2. Generates a branch diff. It runs a diff check on the branch and saves it to a file. This tells the agent what has already been changed, so it doesn’t redo work.

3. Fetches PR comments. It pulls both general PR comments and inline code review comments from the GitHub API.

4. Processes and converts comments to YAML. A Python script normalizes the comments into a clean structure, and another converts them to YAML - a format the agent can parse easily.

5. Tracks handled comments. A handled_comments.yaml file keeps track of which comment IDs the agent has already addressed, so it doesn’t process the same feedback twice.

After the agent makes its fixes, the workflow commits, deploys the updated preview, and posts a completion comment on the PR:

Coding Agent finished processing PR comments for RND-123. Changes have been committed and pushed to the branch. Deployment URL: https://rnd123.preview.url.com

Step 4: Mentioning @coding_agent in a PR Comment

The label-based trigger works great for the initial flow and for re-triggering from Jira. But once a PR exists, the natural place for feedback is the PR itself. Reviewers are already leaving comments there. Having to go back to Jira to trigger the agent felt like unnecessary friction.

So we added one more entry point: coding-agent-comment-dispatch. This workflow listens to the issue_comment event (which GitHub fires for PR comments too) and checks if the comment body contains @coding_agent.

When someone writes a comment like “@coding_agent please fix the font size on the header - it should be 14px not 16px”, the workflow:

1. Verifies the PR is open (it won’t process closed or merged PRs)

2. Extracts the Jira issue key from the branch name (since our branches follow the {JIRA_KEY}-Coding-Agent convention)

3. Posts a confirmation comment so you’ll know it’s listening

4. Calls the fix PR workflow

This closed the loop entirely. A reviewer can leave feedback, mention the agent, and walk away. The agent picks up the comments, makes the fixes, pushes a new commit, and deploys. The reviewer comes back to find their requested changes implemented.

What We Learned

Start with workflow_dispatch. Being able to manually trigger the workflow was invaluable during development and remains useful for debugging. Every reusable workflow we built supports both workflow_call (for programmatic triggering) and workflow_dispatch (for manual runs). Don’t remove the manual trigger when you add automation - you’ll need it.

Persist state externally. GitHub Actions runners are ephemeral. We use our cloud storage to persist the agent’s working files between runs. This gives the agent continuity across the initial implementation and subsequent fix passes. Without this, every run would start from zero.

Give the agent context about what’s already done. The branch diff is crucial. Without it, the agent would sometimes redo changes that were already implemented, creating confusing diffs. Telling it “here’s what you’ve already changed, don’t redo this” dramatically improved the quality of iterative fixes.

Meet people where they are. The Jira label trigger was the single biggest adoption driver. Backend developers and product managers were already in Jira all day. Making the agent accessible from there - rather than requiring them to navigate GitHub Actions - was the difference between “cool demo” and “tool people actually use.”

Know what it’s bad at. The agent handles well-scoped, single-concern changes reliably: fix this color, adjust this spacing, update this label. It struggles with anything that requires understanding cross-component relationships or making judgment calls about UX. We learned quickly to write tickets that are specific and visual - “change the header font size from 16px to 14px” works; “make the header look better” doesn’t. The quality of the output is a direct function of the quality of the ticket.

Conclusion

While the current flow works, and more importantly, it’s in use, there are a few improvements we would like to add. For example having an agent take screenshots of the change implemented (or clip when needed) and put them automatically on the Jira ticket. This will allow our product managers to close the check loop immediately on Jira. We’ll also want to allow them to ask for changes from Jira and not through Github.

The thing that surprised us most wasn’t the technology. It was the behavioral shift. Before the agent, small UI issues would sit in the backlog for weeks - not because they were hard, but because no one wanted to interrupt a frontend developer for something trivial. Now those tickets get resolved the same day they’re filed, often by the person who noticed the problem in the first place. The backlog didn’t just shrink. An entire category of work stopped accumulating. Of course we will need to validate this with actual metrics like time-to-merge, but the overall response from our teams was very positive.

You can find the full workflows, code, and explanation on our public repository. This will not work “out of the box”, but all the relevant building blocks are there which should be a great starting point to implement your own solution.

AI isn’t failing because it lacks intelligence - it’s failing because it doesn’t understand how businesses actually work. As companies race to embed AI into decision-making, workflows, and automation, they’re discovering a hard limit. No matter how powerful the models are, AI can’t deliver reliable results unless it understands the data it’s using — what the numbers mean, which rules apply, and which definitions the business actually trusts. That understanding is missing in most enterprises today, and it’s quietly becoming the biggest blocker to real AI impact.

Today, we’re launching Solid - and announcing a $20M funding round to help enterprises close the Data Understanding Gap that keeps AI stuck in pilots instead of production. Solid gives AI a trusted, continuously updated understanding of how a business’s data works, so companies can finally rely on AI to answer questions, power workflows, and take action safely at scale.

Subscribe now

Problem: What’s Broken

Enterprise data is complex, fragmented, and constantly changing. Business logic lives across dashboards, SQL, documentation, and - most critically - in people’s heads. Definitions shift. Metrics evolve. Rules vary by context. And companies are relying on connecting their data to AI alone as a solution.

Humans can navigate this complexity with experience and judgment. AI cannot.

So when organizations try to apply AI to their own data:

• Answers conflict across tools

• Automation breaks when logic changes

• AI agents hesitate or fail to act

• Data teams become bottlenecks for every request

Most companies try to patch this by manually maintaining definitions across BI tools, models, and AI systems. But as AI usage grows, that approach collapses under its own weight. Data understanding becomes the slowest, most fragile layer in the stack.

Why We Built Solid

We saw this problem everywhere - not just in one company or one industry, but across every organization trying to turn AI ambition into reality. Teams had invested in modern data platforms and cutting-edge AI tools, yet still couldn’t get consistent answers or reliable automation.

The issue wasn’t effort or talent. It was that no system owned the business meaning of data in a way AI could actually use.

We built Solid to solve that problem directly - not by adding more dashboards or asking teams to document harder, but by giving AI a dependable understanding of how the business works in the real world.

As AI takes on more responsibility, companies need a clear owner for business meaning - someone accountable for defining, validating, and evolving how data is interpreted as the business changes. We believe this will emerge as a new role inside the enterprise: the Semantic Engineer. This role builds naturally on the work analysts already do today, but shifts the focus from producing reports to ensuring AI systems consistently understand and apply the right business logic over time.

Since launching privately, we’ve been partnering with forward-thinking enterprises like SurveyMonkey to put this foundation into practice - helping teams move AI from experimentation to production with a shared, trusted understanding of their data.

What Solid Does

Solid bridges the gap between enterprise data and AI.

It automatically generates, tests, and maintains the semantic models AI needs to safely understand and use enterprise data - working with the platforms companies already rely on, not replacing them. It participates in the context graph, and accumulates the content that makes it possible.

“As we expand AI across SurveyMonkey, trust in our data is non-negotiable,” said Meenal Iyer, VP of Data at SurveyMonkey. “AI moves fast, but without a shared and reliable understanding of business logic, it breaks just as quickly. Solid has given us a strong framework where definitions stay aligned as our data and business evolve, so AI can deliver answers and power workflows we can actually trust.”

At its core, Solid:

• Learns the structure and meaning of enterprise data, including real-world nuance and edge cases

• Integrates with existing data platforms, BI tools, and AI systems

• Keeps business logic continuously up to date as data and definitions change

• Combines software with hands-on expertise to handle exceptions, capture nuance, and improve accuracy over time

We’re not a BI tool.
We’re not a semantic layer.

Solid is the layer - plus human expertise - that translates how your business works into something AI can reliably understand and act on.

Why We’re Built for This

Solid is built by people who have spent their careers inside enterprise data, analytics, and AI systems - watching firsthand how fragile data understanding becomes at scale. We’ve lived the pain of inconsistent definitions, broken workflows, and AI initiatives that stall not because of technology limits, but because business meaning couldn’t keep up.

That experience shaped every design choice behind Solid: automation where it scales, human expertise where nuance matters, and a relentless focus on making AI reliable in real-world conditions.

In practice, Solid delivers measurable results:

• Accuracy: Without Solid, AI + data accuracy typically ranges from 20–30%. With Solid, accuracy improves to 85%+.

• Effort: Solid reduces the manual work required to maintain and test semantic models by 50–70%, freeing data teams to focus on higher-value work.

• Time to Value: Solid shortens AI + data initiatives by a factor of 4, reducing deployment timelines from 1–2 years to just 3–6 months.

Launch Details

With today’s launch, Solid continues to work with enterprises to:

• Enable trustworthy chat-with-your-data experiences

• Power AI-driven workflows that don’t break when logic changes

• Support AI agents that can reason, decide, and take action safely

The $20M funding will accelerate product development, expand customer partnerships, and help more organizations move AI from experimentation into day-to-day operations.

If your company is investing in AI - and struggling to trust the results - we’d love to talk.

AI models will keep getting better. Tools will keep multiplying. But without a trusted understanding of enterprise data, AI will continue to create friction instead of leverage.

Solid removes that blocker.

We believe the next era of enterprise AI won’t be defined by smarter models alone - but by systems that understand the business well enough to act on its behalf. We’re excited to help build that future.
‍

To learn more about Solid and our partnership with SurveyMonkey, download the case study here.

If you listen to the doom-scrolling narrative on your favorite social network, the writing is on the wall: AI is coming for us, white-collar workers. We are told that software engineers, analysts, and data employees are the modern-day weavers awaiting the mechanical loom.

But if you look at the actual data, a very different story emerges.

A recent report from The Economist highlights a fascinating paradox. Since the public release of ChatGPT in late 2022—the exact moment the “AI replacement” clock supposedly started ticking—America hasn’t shed white-collar jobs. It has added roughly 3 million of them.

Even more specific to our industry: despite the rise of tools that can write code and query data, the number of software developers has grown by 7%. Roles that combine technical expertise with oversight, like project managers and information-security experts, have seen employment rise by nearly 30%.

Why? If AI can write the code and run the analysis, why are we hiring more people to do it?

The answer lies in a fundamental phase shift in technology. We aren’t seeing the end of the technical worker; we are seeing the birth of the Architect Era.

Subscribe now

The SaaS Lesson: Conservation of Complexity

To understand what’s happening, we have to look back at the last major phase shift: the rise of SaaS.

Before the cloud, deploying software was a physical, logistical nightmare. You needed server rooms, cooling systems, and armies of IT staff just to keep the lights on. Then came SaaS. Suddenly, you could spin up a CRM or an ERP with a credit card.

The narrative back then was similar: “This will make IT departments obsolete.”

Did IT departments disappear? No. They exploded in size and scope.

SaaS made deploying software simple, but it made the architecture infinitely more complex. Instead of one monolithic system, companies suddenly had 50 disjointed applications that needed to talk to each other. The complexity didn’t vanish; it moved up the stack. We needed fewer people to rack servers, but significantly more people to integrate APIs, manage data pipelines, and architect the ecosystem.

We are seeing the exact same pattern with AI, but on a much larger scale.

From Syntax to Semantics

Generative AI has effectively driven the cost of syntax to zero. Writing a Python script, generating a simple SQL query, or building a React component is now a commodity task.

But just as SaaS created a sprawl of applications, AI is creating a sprawl of logic and agents.

When you can “vibe code” a new feature in an hour, or when a business user can spin up a custom “digital employee” to handle procurement, you aren’t simplifying the enterprise—you are introducing a new layer of chaos. You are building a complex, adaptive system where thousands of non-deterministic agents are interacting with your data and your customers.

This doesn’t remove the need for technical talent. It demands a higher tier of it.

We are moving away from the era of the “Builder”—the person who manually types the syntax—and into the era of the Orchestrator.

The New Job Description

In this new world, the value of a technical worker isn’t measured by lines of code written, but by the clarity of the architecture they design.

• For Developers: You aren’t just writing functions anymore. You are acting as a “Bot Manager,” orchestrating agents to ensure they don’t hallucinate or break the build. You are building the “Cognitive Architecture” and the testing infrastructure that keeps the system sane.

• For Analysts: You aren’t just writing SQL. You are building the Semantic Layer—the “Detailed Librarian” that teaches the AI the difference between ‘revenue’ and ‘bookings’ so it doesn’t lie to the CEO.

The systems we are building today are orders of magnitude more complex than what we built five years ago because AI allows us to dream bigger. We are no longer limited by how fast we can type; we are limited by how well we can structure the logic, govern the data, and manage the system’s behavior.

The Phase Shift

The Economist notes that while routine back-office work is shrinking, “roles that combine technical expertise with oversight and co-ordination” are thriving.

This is the phase shift. AI is an industrial revolution for logic. It allows us to build systems that were previously impossible due to the constraints of human coordination and “mythical man-months.”

But complex systems require complex management. They require rigorous governance, deep context engineering, and a human-in-the-loop who understands the “Ground Truth” of the business.

The future of work isn’t about competing with the machine. It’s about architecting the factory that the machines run in. The demand for people who can do that isn’t going away—it’s just getting started.

I’ve been recording the Building with AI: Promises and Heartbreaks podcast for a while now, talking with people who are actually building things with AI, not just posting hot takes about it.

My recent conversation with Glen McCracken was one of those “I wish more boards could listen to this” episodes. (episode available here)

Glen is the Chief Product and Technology Officer at Lantum, a health-tech scale-up helping the NHS and other providers manage their workforce. He’s been working with what we now call “AI” for nearly 30 years. At one point he was literally working with the creators of R. He’s also one of my favorite contrarian voices on LinkedIn, and the only person I know who can explain AI adoption with a cartoon and a single sentence.

In the episode, Glen described AI as:

“overhyped and underestimated.”

That framing stuck with me. So in this post, I want to unpack a few of the big ideas from our conversation and translate them into concrete actions for data, analytics and AI leaders.

1. The noise machine, FOMO and “overhyped and underestimated”

Glen spends a lot of time calling out the noise machine around AI: vendors exaggerating, analysts inventing new categories, consultants telling you that you are already behind and must “move faster”.

He likes hype up to a point. Hype gets boards asking questions. It gets budgets allocated. It creates curiosity.

The problem starts when the question is:

“How do we shove AI into our organization?”

instead of:

“Where are we in pain, and could AI help us do this better?”

AI on LinkedIn now feels like Instagram for enterprise technology.

On Instagram, everyone is in Bali, eating perfect food, with perfect kids, in perfect light. Meanwhile your real life is: breakfast with your kids, Slack, six Zoom calls, and maybe some cold coffee.

On LinkedIn, every AI demo looks magical. Every company claims “we transformed X in 30 days with agents”. If you’re a leader sitting in the middle of a very real, very messy organization, you start to think:

“Is my AI journey wrong? Is my company behind? Am I missing something?”

Glen’s answer is basically: you are seeing the highlights reel, not the truth. The truth is much closer to what we wrote about in “Sorry for the mess” – everyone’s data is messy, and it’s Okay and Stop saying “Garbage In, Garbage Out”, no one cares.

You don’t see:

• The pilots nobody talks about because they quietly died

• The security reviews that blocked half the “magical demos”

• The teams who don’t have time to adopt the shiny thing because their backlog is already full

The goal is not to opt out of AI because of the hype, and it’s not to chase the hype either. It is to use the hype as air cover while you work on more boring, durable things: foundations, people, data, and actual business problems.

2. Push vs pull: why your best AI projects don’t start in a boardroom

One of Glen’s most useful lenses is how he classifies projects:

“There are push projects and pull projects.”

• Push projects: someone senior decides “we need AI”, or “we need an LLM strategy”, and pushes projects down into the organization.

• Pull projects: the business feels pain and is actively trying to pull help in. “This takes me 6 hours a week, there has to be a better way.”

Push projects, in Glen’s experience, “are really hard and invariably will fail”.

Pull projects are where the magic happens.

If you listened to our earlier episode with Meenal Iyer and read the write-up (Building an AI-powered Intelligent Enterprise), you’ll recognize the pattern: the best ideas come from the front line, not from the ivory tower.

Glen added another useful concept: moving your organization from “subconsciously incompetent” to “consciously incompetent” about AI.

Right now, in many companies:

• People don’t know what is possible with AI

• They do know that their work is painful and inefficient

• They don’t have the language or examples to connect the two

So his advice is simple:

1. Raise AI literacy: Give people safe ways to play with tools like ChatGPT, Claude, n8n, Make, etc., in their personal lives and in low-risk work contexts.

2. Let them feel that “there is a better way to do this”.

3. When they start coming to you with “Could we use something like this to…?”, that’s your backlog.

This is also where managing upwards comes in.

If your board is pushing you with “we need to do more with AI”, you often need to:

• Acknowledge the push

• Translate it into a pull strategy

• Buy time to do the boring work: literacy, foundations, and discovery

It is more honest to say:

“Yes, we’re on it. Here’s how we’re surfacing bottom-up opportunities and validating them.”

than to spin up three impressive but doomed pilots that will be in the “95% that fail”.

If you want a broader framework for this, The right way to set your data & analytics strategy goes into how to anchor D&A (and now AI) in real business priorities instead of tool shopping.

3. “Taking the robot out of the human”: AI and job fear

We talked about one of the hottest fear zones: SDRs and sales automation.

In one of his examples, Glen mentioned the classic pattern: you bring in AI to automate sourcing and outbound sequencing, and SDRs immediately ask:

“Is this thing going to replace me?”

Glen’s answer comes from years in robotic process automation (RPA). In that world, there is a line he referenced:

“Automation is all about taking the robot out of the human, so it’s taking those highly repetitive activities out of the human.”

You don’t eliminate the role. You change its shape:

• The repetitive, rules-based parts (if-then-else) get automated

• The exception handling, judgment, and relationship work move up in importance

We see something similar at Solid. We use tools like Amplemarket for outbound. Instead of writing 200 semi-personalized emails, a human defines:

• Who we want to talk to

• What value prop should resonate

• What “story” we want to tell

Then the system generates and executes the outreach, with actual tailoring at scale.

The result:

• The machine never gets tired

• Humans spend their time on conversations, not copy-paste work

• Performance goes up, not down

None of this makes the fear go away automatically. That fear is human. Which means you have to design for it:

• Involve people early in defining how AI will change their work

• Be explicit that they are still accountable for outcomes

• Give them tools that clearly make their day better, not just “more monitored”

When people feel something is being done to them, they resist. When they feel they are co-designing it, they lean in.

4. A real example: turning sales escalations into a “client 360” AI assistant

My favorite part of the conversation was a concrete story from Glen’s previous role leading data, analytics and AI at a large fintech.

The sales team had a familiar problem:

• To get a deal approved, they had to prepare a long escalation email for senior management.

• That email had to explain: history with the client, product usage, outages, contract evolution, comparable deals, recent interactions, external signals about the customer, and more.

• It took hours of manual digging across multiple systems.

Salespeople were very clear on their pain:

“There has to be a better way. We want to spend more time selling and less time doing admin.”

Glen’s team built what was essentially a RAG-powered “client 360” assistant:

• It pulled data from CRM, ticketing, usage, billing and external sources

• It assembled everything into the exact escalation format leadership expected

• It did this in minutes, not hours

A few things stood out:

1. They ran it in parallel first. Salespeople kept doing escalations the old way while the AI tool generated its own version. That gave the team real-world feedback and “human in the loop” reinforcement.

2. Adoption became self-reinforcing. The people in the pilot started getting hours back. Others saw that and wanted in. The “coalition of the willing” grew organically.

3. Quality went up, not just speed. Before, escalation quality varied a lot by region, product and salesperson. Now, everyone was effectively getting the help of “the best escalation writer in the company”.

There was also one unexpected downside:

Senior leaders realized that, previously, they could infer a salesperson’s thinking and skill from how they wrote escalations. Once AI standardized everything, that signal disappeared.

Their solution was clever: since they already had transcripts and emails flowing into the system, they built a lightweight coaching tool. It gave feedback to both the salesperson and their manager on things like:

• How discovery calls were run

• How objections were handled

• Where follow-ups were falling through

Same data, different product, different purpose.

There is a pattern here that echoes a lot of what we’ve written before, especially in Beyond Efficiency: How AI is Redefining Data Analytics:

• Start from a painful, specific workflow

• Build something that obviously helps the humans

• Expect second-order effects, and be ready to build on the new foundations you just created

And, crucially, Glen kept repeating: the salesperson is still responsible.

You do not want to hear: “Well, the AI wrote it, so if it’s wrong, that’s not on me.”

5. Stop waiting for perfect data

If you work in data, you’ve probably heard (or said):

“We can’t do AI until our data is clean.”

Glen has lived through the opposite.

In that same fintech, they were stitching together systems from more than 40 acquisitions. Different CRMs, billing tools, ticketing, you name it. The temptation was:

“Let’s fix the data first. Then we’ll build the cool stuff.”

Instead, they:

• Built useful Power BI reports and AI tools earlier

• Accepted that some data would be wrong

• Made it trivial for business users to flag issues

The result: they effectively crowdsourced data QA.

The people who knew the data best – the ones using it every day – now had a reason and a channel to say:

“This says they’ve been a client for three years. It’s at least seven.”

That feedback then improved the underlying pipelines for everyone.

Glen’s main regret: they should have started earlier.

This lines up almost perfectly with what we argued in “Sorry for the mess” – everyone’s data is messy, and it’s Okay and Stop saying “Garbage In, Garbage Out”, no one cares:

• No one has a perfectly clean house

• You cannot and will not fully “tidy up” before you invite AI in

• The right question is: “How do we build AI that can live in the mess and help us clean where it matters most?”

That requires humility from the data team:

• You test and monitor as much as you can

• You do your own anomaly detection and sanity checks

• But you are honest that the map is not the terrain, and you treat your users as partners, not just consumers

6. Do you really need a “VP of AI”?

Later in the conversation, I asked Glen to bust an AI myth in one sentence.

He went straight for this one:

“AI is really easy to implement. Like it really is… the myth I would bust would be that AI is hard. It’s not hard.”

If a vendor tells you “AI is hard”, his suggestion is simple:
Find one who genuinely thinks it is easy – because they’ve actually done it before.

His view on org design matches that.

He likes Charles Handy’s old idea of federated organizations and applies it to AI:

• You can create a separate AI office, a VP of AI, an “AI center of excellence”

• Or you can embed AI responsibility into every function, the way we did with email and the internet (Reut talked about this too)

• Marketing owns AI for marketing, Sales for sales, Finance for finance, with support from central data/AI teams

You didn’t appoint a Chief Email Officer when email showed up. You taught everyone how to use it.

That doesn’t mean there is never a case for a central AI team. Sometimes you really do need tight governance, shared infrastructure and consistent standards. At Solid, our platform team exists for a reason.

But if all AI energy is concentrated in a single “tower”, you get:

• Slow feedback loops

• Misaligned incentives

• Leaders who aren’t building AI skills in their own orgs

If, instead, AI is part of how every CxO does their job, you get:

• Better problem selection

• More realistic expectations

• Less magical thinking, more delivery

7. Practical takeaways for AI and D&A leaders

If you are a CDAO, CPO, CTO or Head of Data reading this while your LinkedIn feed screams “You’re already behind on AI”, here is how I’d summarize Glen’s playbook.

1. Start from pain, not from models.
Build your roadmap from pull: real, repeated pain that business teams are begging you to fix. “We spend 10 hours a week on X” is a better starting point than “We should have an agent strategy.”

2. Use hype as cover, not as a spec.
The noise machine buys you air cover to invest in literacy, foundations and boring plumbing. It doesn’t define your success metrics.

3. Invest in literacy and experimentation.
Your goal is to move people to “consciously incompetent” about AI. They should know enough to say, “I think we could automate this,” even if they don’t know how.

4. Design for augmentation, not replacement.
Repeat Glen’s line to your teams: automation is about “taking the robot out of the human”. Roles will change. They should also become more interesting.

5. Get something useful in front of people before the data is perfect.
Let your users help you discover where the real data problems are. Just don’t treat them as unpaid QA – respect their time and close the loop when they flag issues.

6. Keep humans accountable.
No “the AI did it” excuses. If your name is on the presentation, email or escalation, you own it. AI is a tool, not a shield.

7. Make AI everyone’s job.
Support from central teams is important. But the real responsibility sits with the people who own outcomes in Sales, Marketing, Product, Finance and Operations.

If you want to hear Glen in his own words – including his story about working with the creators of R back in the 90s, why he loves Otter, and why he thinks we’ll still be fighting about hype five years from now – you can listen to the full episode of Building with AI: Promises and Heartbreaks with him.

And if you’re trying to make sense of where AI actually fits in your own data and analytics journey, we’re always happy to talk about how Solid can help.

For decades, enterprise software followed a predictable, albeit painful, pattern: you bought a rigid, off-the-shelf platform and spent the next three years (and millions of dollars) trying to bend your business processes to fit its “best practices.” It was like buying a one-size-fits-all suit and then having to lose weight just to button the jacket.

But as we enter 2026, that story is quickly becoming obsolete. We are witnessing the rise of Vibe Coding in the enterprise - a seismic shift where “English is the new programming language”, and custom, purpose-built apps are becoming the default, not the exception.

This isn’t just about writing code faster; it’s about a fundamental inversion of the software supply chain. We are moving from a world of scarcity (where developer time was the bottleneck) to a world of abundance (where the only bottleneck is the clarity of your intent).

Subscribe now

From “Software as a Service” to “Software as a Vibe”

Andrej Karpathy famously coined the term “vibe coding“ to describe a world where you focus on the what and let the AI handle the how. In a startup context, this is about speed. In an enterprise context, it’s about Hyper-Relevance.

We are living in a reality where a department head can “vibe” a custom procurement tool or a supply-chain tracker into existence in a few days. This disrupts the traditional SaaS model entirely. Why pay for a complex, bloated expense management solution with 900 features you don’t use, when you can vibe a tailored one that fits your workflow perfectly?

Just last week, one of my board members (!) vibe coded his own travel expense software. He didn’t want a dashboard with generic KPIs; he wanted a tool that specifically highlighted policy violations based on his company’s unique handbook and exported the exact PDF format requested by his Finance department.

But let’s not pretend it’s magic. The reality of 2026 is that while the barriers to entry have dropped, the complexity of management has risen.

The New Development Cycle: Avoiding the “Recursive Fix-It” Trap

As we’ve seen in early experiments (and as noted by observers like Alex Dorand), vibe coding isn’t just shouting at an LLM and hoping for the best. Without discipline, it leads to what we call the “Recursive Fix-This-Shit” Era. This happens when you ask an AI to build a massive system in one go, and you spend the next week in a hellish loop of fixing one bug only to create three more because the AI lost the context of the original architecture.

To succeed in 2026, enterprises are adopting a new form of Iterative AI Development:

1. Context Engineering: Successful vibe coding requires breaking applications down into “contexts”: small, manageable chunks of logic. You don’t vibe an ERP; you vibe the “Invoice Matching Module,” then the “Vendor Approval Module.”

2. The “Feature Madness” Phase: We are currently in a period of “feature madness.” Because the cost of testing a hypothesis is near zero, businesses are iterating on features every 48 hours rather than every two weeks. The definition of “agile” has shifted from “shipping code” to “shipping business value.”

3. The Orchestrator Role: Developers aren’t disappearing; they are evolving into “Dev-Copilots” or Orchestrators. Their job is no longer to write the syntax but to manage the contexts - ensuring that the “Invoice Module” doesn’t hallucinate data when talking to the “Vendor Module.”

The Moat is the Infra, Not the App

As the cost of creating an application drops to near-zero, the value shifts. The moat is no longer the application code itself. it’s the cognitive architecture that allows the vibe to be accurate, secure, and useful.

If you just let 5,000 employees “vibe” apps on their laptops, you don’t get innovation; you get Shadow IT 2.0 - a chaotic swamp of unmaintained, insecure scripts. To move from “vibe-coded slop” to “enterprise-grade intelligence,” you need four pillars of infrastructure:

1. The Governed Semantic Layer

As I’ve written before, your AI is only as smart as its map. You cannot simply point an LLM at your raw SQL database and say “build me a dashboard.” It will hallucinate columns, misunderstand relationships, and calculate “Revenue” based on a schema deprecated in 2023.

Enterprises need a Data Semantic Layer - a rigorous, governed definitions layer that acts as the “Detailed Librarian.” It educates the vibe-coding engine on business logic. When a user types “show me high-value customers,” the Semantic Layer intercepts that intent and tells the AI: “High Value is defined as >$50k ARR, and Customer data lives in the ‘Global_Accounts’ table, not ‘Sales_Leads’.”

2. Built-in Governance & Private Deployment

We need a sandbox. To truly share and collaborate, enterprises need private infrastructure where vibe-coded apps can be deployed instantly without leaking proprietary logic to the public web.

Governance must be the “steering wheel” baked into the vibe-coding engine.

• Permissions: “Hey AI, build me a salary transparency tool” should be met with “I’m sorry, you don’t have access to the HR Payroll schema,” not a SQL dump of everyone’s wages.

• Compliance: Every generated app should automatically inherit the company’s SSO, audit logging, and data retention policies.

3. The “Unit Test” for Vibes: Robust Maintenance Infra

This is the most overlooked aspect of the revolution. What happens when the person who wrote that travel app leaves? Or when the underlying API changes?

We need robust testing and maintainability infrastructure. We cannot rely on “it looked good when I generated it.” (the new “it works on my machine”)

• Automated Vibe Testing: We need systems that run “regression vibes”—automatically prompting the app with standard user inputs every night to ensure the data structure hasn’t drifted or that the underlying logic is still valid.

• Self-Healing Code: The infrastructure should be able to detect runtime errors in these custom apps and feed them back into the vibe engine to auto-generate a fix, which is then presented to a human Orchestrator for approval.

4. Custom Data Stacks

Generic SaaS forces you to store data their way. Vibe coding allows you to build apps that sit on top of your data stack. The winners in 2026 are building “Interface Layers” that allow users to vibe code ephemeral UIs on top of a permanent, governed data lake (like Snowflake or Databricks). The app is temporary; the data is eternal.

The Bottom Line

The “AI-Readiness Gap“ is widening. The winners won’t be the companies that buy the most AI licenses; they’ll be the ones that architect the infrastructure to let their employees “vibe” safely.

We are moving toward what Alex Dorand calls the “Creativity Era”—a future where the AI context is so rich, and the infrastructure so robust, that the “how” truly disappears, and the “what” is the only limit.

But we aren’t there yet. Today, we are Orchestrators. If you can’t describe your business logic clearly enough for an AI to build it, or if you haven’t built the testing infrastructure to keep it running, that’s your new bottleneck.

What are you building today? Or better yet, what are you vibing?

I want to share a recent internal hackathon project that tackled a persistent friction point in product development: the disconnect between design and code.

The Bottleneck

We all know the theory behind a design system. It is the agreed-upon standard for consistency. It reduces technical debt and saves developer time by ensuring that once a component is built, it is reused rather than rebuilt. In a perfect world, the design system in Figma matches the code in the repository exactly.

But in reality, maintaining this synchronization is difficult. The process often involves a manual handoff where frontend developers must interpret design files and manually write the code to match pixel-perfect specifications. This repetition is inefficient and prone to human error.

During our recent hackathon, we asked a simple question: Can we use AI agents to automate the translation from design to code entirely? YES! Where there is a tedious, high-friction problem, there is now a solution in AI.

Subscribe now

Turning Hours into Minutes

Our initial estimates suggest this workflow can reduce the time spent on UI implementation by nearly 50%, effectively turning hours of manual back-and-forth into a process that takes just minutes. This shift allows our engineers to stop acting as “translators” for pixels and start focusing on the architectural logic that actually drives the product forward.

New Flow - Step by Step

Step 1: The Integration

First, we established a direct link between our design source and our coding environment. We connected Figma to Cursor using the Figma Model Context Protocol (MCP). This allowed the AI to read the properties of our design files directly.

Step 2: Start with a simple component

We started with the fundamentals by creating a “Main Action Button” as our base unit in Figma. Crucially, this wasn’t just a visual mock-up. We deliberately structured the component using Figma variables for every property - colors, padding, typography.

Instead of hardcoding raw hex values (e.g., #0057FF), we assigned semantic variables (e.g., primary-action-background). This step was vital for the integration. It ensured that when the AI accessed the design, it read structured, semantic data rather than raw pixels. This preparation allows the AI to generate clean code that maps directly to our established design tokens, rather than creating messy, hardcoded styles.

Step 3: Connect Cursor to Figma MCP

We then connected the Cursor IDE with the Figma MCP. Instead of a developer looking at Figma and typing out CSS and React code, Cursor pulled the component data directly. It generated the code automatically and immediately presented the working component in Storybook.

This step alone was significant. 🎉 It demonstrated that the initial construction of UI elements could be handled without manual intervention.

Step 4: The AI Agent

The true breakthrough came in the final step. We didn’t just want to generate code; we wanted to maintain a system.

We created a custom AI agent within Cursor. Its role was to analyze any new, complex component we designed. Before generating code, the agent performed a logic check:

1. It scanned the new design.

2. It cross-referenced our existing code base.

3. It identified if parts of the new design (like the Main Action Button) already existed in the system.

If a sub-component existed, the agent imported it. If it did not, the agent built it from scratch.

The Next Step

The implications for efficiency are clear. Frontend developers can stop focusing on the repetitive task of translating pixels into code. Instead, they can focus on logic, architecture, and user experience.

By letting AI handle the synchronization between Figma and the codebase, we turn the design system from a maintenance burden into an automatic, self-sustaining asset.

Everyone wants AI on their data. Almost no one trusts it.

Two waves are hitting companies at once:

1. “Chat with your data” on top of the warehouse or BI

2. “Agents with your data” that don’t just answer questions, they update CRM, tweak campaigns, move money

From the outside: magical.
From the inside, if you own the data: risky.

You don’t really know:

• Which tables and columns the model is using

• Why it picked this query instead of another

• How it analyzed the results before answering or taking action

And you know you’ll be held responsible if it’s wrong.

That’s what happens when the AI+data layer is a Black Box.

Subscribe now

Black Box vs Glass Box, for chat and agents

This isn’t just about “explainable models.” It’s about whether the system that combines models with your warehouse is understandable and controllable.

What Black Box looks like

Typical pattern:

• Connect a tool to your warehouse

• Point it at your schema

• Start asking questions or giving tasks to agents

You might see the generated SQL or API calls. But you don’t really control or observe:

• What’s fair game
  Which schemas, tables, columns and metrics it considers “ok to use.”

• Why it chose that query
  Why it joined on that key, used that grain, or picked that time window.

• How it analyzed results
  Which segments it compared, what thresholds it used, how it turned rows into “insights.”

• What it’s allowed to say or do
  When it must refuse, when it should escalate, and which actions are off limits.

The “reasoning and policy layer” is invisible. If that’s opaque, you have a Black Box, even if you can see the SQL.

What Glass Box should look like

A Glass Box starts from a simple premise:

The people who own the data should also own the rules for how AI can use it.

Concretely:

• Control over inputs
  Data teams decide which schemas, tables, columns, entities and metrics exist in the AI’s universe.

• Control over reasoning
  Clear mappings from business concepts to joins and metrics, and editable rules for how common questions are interpreted.

• Control over policy
  Guardrails for what the AI can answer or do, when to say “I don’t know,” and when to route to a human.

• Visibility into traces
  For every answer or agent run, you can inspect the data accessed, rules applied, and path taken.

That’s the minimum bar if you want AI touching real customers and real dollars.

Why Black Box breaks in production

Black Box might be fine for summarizing PDFs. Structured data and agents are different.

• Silent misunderstandings
  The model picks a “close enough” table or metric. The number looks plausible, until it’s in a board deck or powering an agent that changes a deal.

• Opaque analysis
  You see the SQL, but not why certain segments, thresholds, or outliers were chosen. The important logic lives above the query layer.

• Governance risk
  Tools blur the line between what’s technically accessible and what’s allowed. Sensitive combos of fields, or actions based on context that shouldn’t have been used, slip through.

• Loss of trust
  If leadership asks “Why did we get this answer?” or “Why did the agent do that?” and the real answer is “We’re not sure,” you won’t get production sign-off.

Black Box AI demos well. It dies in governance review.

Glass Box first. Context graph later.

There’s a lot of hype around “context graphs” and “systems of agents.” Underneath the jargon, there’s a simple idea:

• It’s not enough to know what the current state of the business is.

• You also want to understand how and why key decisions were made over time.

If you do Glass Box right, you get the ingredients for this “context graph” almost for free:

• Every answer and agent run comes with a trace:

  • Which entities and metrics were used

  • Which rules and guardrails fired

  • Where humans stepped in

• Over time, those traces connect your core business objects (accounts, tickets, policies, approvals) with the decisions that changed them.

You don’t have to sell this internally as “let’s build a context graph.”
You sell it as:

• “Let’s make our AI legible and auditable now”

• …and get a rich history of decisions that future agents and analytics can learn from later

Glass Box is the thing you must do.
The “context graph” is what naturally emerges if you instrument it well.

The catch: Glass Box sounds slow and manual

Most leaders nod along with all of this – then immediately worry about cost and speed.

Hand-crafting every metric, join, rule and guardrail for AI sounds like:

• Rebuilding your semantic layer from scratch

• A multiquarter project that never leaves pilot

This is why Black Box tools are attractive: connect warehouse, get a demo next week.

It feels like a tradeoff:

• Black Box: fast but risky

• Glass Box: safe but painfully slow

We think that’s a false choice.

You should be able to have your Glass Box and move fast.

The AI should help you build the Glass Box.

Solid’s theory: accelerate the Glass Box, don’t avoid it

At Solid, our bet is simple:

The only sane way to run AI on your data is as a Glass Box – and the only way to make that practical is to automate most of the Glass Box creation while keeping data teams in control.

In practice, that means:

1. Autogenerate, then curate

Your warehouse already contains a lot of structure: schemas, models, usage patterns, documentation.

Instead of asking data teams to author everything by hand, we use AI to:

• Infer likely entities, metrics and relationships

• Propose initial rules and guardrails around them

Data teams review and correct, instead of starting from zero. Control stays with humans; effort drops dramatically.

2. One Glass Box for chat and agents

No separate universes for:

• “Chat with your data”

• Agentic workflows that take action

Both run on the same governed layer of entities, metrics, rules and policies. Fix a misinterpretation once, and everything gets safer at the same time.

3. Decision traces as a built-in byproduct

Every AI answer and agent run produces a trace:

• Data accessed

• Rules invoked

• Guardrails triggered

• Human approvals

That’s your path to a useful “context graph” over time – without a massive upfront modeling project or a new buzzword program to sell internally.

A quick “Glass Box or not?” checklist

When you evaluate “AI on your data” tools, ask:

1. Can my data team choose and update what schemas, tables and columns exist in the AI’s world?

2. Can we define business concepts and metrics once and have those govern all AI behavior?

3. Can we encode what the AI is not allowed to answer or do as policy, not just prompts?

4. For any answer or agent run, can we see the full trace of data, rules and decisions?

5. Does the system help us build and maintain this Glass Box automatically, or does it rely on manual configuration?

If not, you’re not getting a Glass Box.

You’re getting a slightly translucent Black Box on top of your most important asset.

Where this is going

Systems of record aren’t going away. Systems of agents are arriving fast.
The real leverage is in the layer that connects the two in a way that’s understandable and controllable.

For AI on structured data, that means:

• Glass Box by design

• Decision traces by default

• Acceleration from AI, not avoidance of governance

That’s the path we’re building toward at Solid.

For the last few years, we’ve been living in the era of the LLM. 2024 and 2025 were the years of the Co-pilot—those handy, glorified autocomplete tools that sit in your IDE or your email, waiting for a prompt. They were a massive productivity hack for individuals, but let’s be honest: they were still just tools. They waited for you to tell them what to do.

As we enter 2026, the vibe is shifting. We are crossing the Agentic Event Horizon. We aren’t just adding more “manpower” to projects (a move Fred Brooks warned us against decades ago); we are hiring Digital Employees.

The difference is fundamental. A co-pilot assists you; a digital employee does the job.

Subscribe now

The Vibe Shift: Co-pilot vs. Digital Employee

In Solid’s recent hackathon, I saw this loophole in action. Usually, a hackathon is a caffeine-fueled marathon of manual keyboard-smashing. This time, I wrote fewer lines of code than ever. Instead, I wrote English. I acted as the Architect, while my “AI colleagues”, my digital employees, handled the construction.

A Co-pilot is reactive. It suggests a line of code or summarizes a meeting.

A Digital Employee is proactive. It takes a Jira ticket, analyzes the existing 400k lines of backend code, finds the required hooks, writes the PR, and ensures it passes the tests. It manages its own “to-do” list. It doesn’t just suggest the “how”; it executes the “what.”

The Infrastructure: You Can’t Navigate 2026 with a 1925 Map

You can’t just buy a digital employee off the shelf and expect them to start on Monday. To hire them in an enterprise, you need to build their Cognitive Architecture.

As I’ve written before, an AI is only as smart as its map. If you hand an overconfident genius a map of the Bay Area from 1925, they’ll still give you directions—they’ll just be confidently wrong. To make a digital employee effective, you need:

1. The Data Semantic Layer: This is the “Detailed Librarian.” It educates the AI on business logic so it doesn’t hallucinate “Revenue” based on a legacy table that hasn’t been used since the Clinton administration.

2. Usage as the New Schema: Digital employees need to read your “Data’s Diary.” They need to understand not just the static schema, but how humans actually use the data—the “desire paths” found in query logs and dbt models.

3. Built-in Governance: Governance shouldn’t be the brake; it should be the steering wheel. To let an agent operate autonomously, you need “Governance-as-Code” to ensure it stays within safe boundaries.

Onboarding and Training: Teaching the Tribal Knowledge

Onboarding a digital employee looks a lot like onboarding a human. You have to teach them the “local slang.”

We do this by feeding them the Interconnected Knowledge Graph of the company. They need access to your internal wikis, Slack channels, and historical PRs. This is where they learn the “Tribal Knowledge” that usually only lives in people’s heads. Training isn’t about fine-tuning a model on the internet; it’s about grounding it in your specific, granular context—your “Golden Paths.”

Maintenance, Auditing, and the “Knowledge Loss” Problem

When you “fire” or rotate a digital employee (e.g., upgrading to a new model or switching providers), the fear is knowledge loss. But here is the loophole: unlike humans, a digital employee’s knowledge is externalized.

By forcing them to document their work, the “why” behind the code and the “how” of the process, as a mandatory part of their “Definition of Done,” you actually gain institutional memory. At Solid, we’ve turned our developers and QA engineers into Bot Managers and Semantic Auditors. Their job isn’t to build; it’s to critique and verify. They ensure the machine’s output adheres to the “Ground Truth.”

We monitor them through aggressive automation and regression testing. If the AI writes the code, the human must ensure it works every time. The “Sprint” becomes a misnomer because we aren’t running - we’re flying.

The Bottom Line

The winners in 2026 won’t be the companies that buy the most AI licenses. They’ll be the ones that architect their infrastructure to let their digital employees “vibe” safely and productively.

We need to stop treating data documentation as a chore and start treating it as the core operating system for this new workforce. The industrial revolution for code is here. Are you still navigating with a 1925 map?

1. “We have an AI strategy.”

2. “We have a modern data stack.”

3. “Our AI still gives answers we do not fully trust.”

Models are powerful. Warehouses are mature. Yet when AI meets real enterprise complexity, you still see:

• Confident but inconsistent answers

• Agents that cannot safely take action

• People arguing over which version of a metric is “right”

The missing piece is not more dashboards or another LLM.
The missing piece is meaning.

In 2026, I think we will finally name and formalize the discipline that owns this problem:

Semantic Engineering
The practice of turning a company’s business and data knowledge into semantic models that AI can safely understand, reason over, and act on.

And the people who will lead it are not “AI gurus”.
They are the data and business analysts who already know how the business actually works.

Much like dbt brought to the world the Analytics Engineers, we will now see Semantic Engineers.

Subscribe now

Why semantics are now the bottleneck

Every large enterprise is racing to embed AI into how work gets done, from decision making and reporting to automated workflows and agents.

Very quickly they hit the same hard limit:

AI cannot deliver value unless it understands your data and your business logic.

Today that understanding is scattered:

• Metric definitions are duplicated across tools

• Business rules are buried in SQL, docs, and tickets

• Edge cases live only in people’s heads

• Governance rules change faster than reports do

Humans can work around this with context and memory.
AI cannot. When AI does not understand what a number means, it guesses.

At small scale you can patch this with ad hoc prompts, manual reviews, and heroic analysts.
At enterprise scale, it breaks.

Semantic Engineering is about treating that understanding as infrastructure, not as a side effect of dashboards or code.

The Semantic Models Lifecycle

If Semantic Engineering is a discipline, it needs a lifecycle.

At Solid we think about it as a five step loop. The slide you saw at the top is the visual version. Here is the narrative version.

1. Auto generated semantic models

You do not start from a blank page.

Your warehouse, BI tools, query logs, and documentation already contain a lot of implicit structure:

• Which tables are used together

• Which metrics people care about

• How teams slice and dice the same concepts

Tools like Solid can now mine this “digital exhaust” and generate an initial semantic model in minutes instead of months:

• Core entities and how they relate

• Frequently used metrics

• Common joins and filters

Think of this as raw material for Semantic Engineers. It is noisy, but it reflects reality.

For a deeper dive into how this works, we will be publishing more technical details in a follow up piece. If you enjoy that kind of thing, you might also like our earlier post “The Ghost in the Machine: How Solid drastically accelerates semantic model generation”.

2. Fine tune models

Generation gets you a draft. Semantic Engineers make it true.

This is where data and business analysts bring their knowledge of the organization:

• Rename metrics and entities to match the language people actually use

• Merge or split metrics that should not be separate in practice

• Add rules like “exclude test accounts” or “include only paying customers”

• Capture special cases: trial periods, multi currency revenue, regional exceptions

If you have read “Behind the scenes: how we think about semantic model generation” you will know how much nuance hides here. This step turns an auto generated graph into a faithful map of the business.

3. Test, validate, and publish

Once the model looks right, you still have to prove it.

Semantic Engineers treat semantic models like code:

• Regression tests for metrics across dimensions

• Comparisons against trusted reports

• Spot checks with domain experts

• Clear promotion steps from draft to “published” models

Only then do those models become available to AI experiences: chat with data, copilots in tools, operational workflows, or agents that take actions.

This is also where governance shows up. In “The Two Souls of a Semantic Layer: A Tale of Governance and Insight” we talk about how you need both: freedom to explore and strong guarantees when machines act.

4. Automatic updates

The business does not stand still. Neither can your semantics.

New products launch. Regions open and close. Pricing plans change. Regulations appear. If every change requires manually hunting through SQL and dashboards, the semantic model will always lag behind reality.

In a semantic engineering approach:

• The platform notices that queries and schemas are changing

• It suggests updates to the semantic model

• Semantic Engineers review, adjust, and approve

The goal is simple: AI should always reflect how the business works today, not last year.

5. Optimize from real usage

Once AI is live, you finally see the sharp edges.

Semantic Engineers watch how humans and agents actually use the models:

• Which questions appear over and over

• Where AI is uncertain or inconsistent

• Which workflows require human override

• Where adoption stalls because answers are confusing

Real usage becomes a feedback loop that continuously improves the model.

We talked in the past about how much you can learn by watching what people do when they are not excited to use your AI. Semantic Engineering gives you a concrete way to respond: update the semantics so the next interaction is better.

Who are Semantic Engineers in practice?

The interesting thing is that you probably already employ Semantic Engineers. You just do not call them that yet.

They are:

• The analyst everyone pings when numbers do not match

• The finance lead who can explain exactly how “ARR” differs between sales, finance, and product

• The operations manager who knows every exception in the customer lifecycle

• The analytics engineer who keeps dbt models aligned with reality

Today these people are often trapped in reactive work:

• Explaining the same metric definition over and over

• Fixing broken dashboards

• Translating between teams that all use the same words differently

Semantic Engineering gives them a new mandate:

• Your job is to teach AI how the business works.

• Your primary artifact is a living semantic model, not just a report.

• Your success metric is how reliable and scalable AI becomes for everyone else.

You do not need to hire an entirely new team to start. You need to give your existing experts a name for the work they are already doing and better tools to do it.

Why this happens in 2026

Why am I confident that Semantic Engineering will emerge as a real discipline this year?

A few reasons.

1. GenAI has moved from novelty to expectation.
   Two years ago people were still experimenting with “chat with my data”. In 2026 many executives expect AI to show up in their core workflows. Expectations are higher. Tolerance for inconsistent answers is lower.

2. Data teams are feeling the strain.
   In “Stop saying ‘Garbage In, Garbage Out’, no one cares” we wrote about how data leaders are asked to both “fix everything” and “ship AI” at the same time. Semantic Engineering is a way to focus on the thin layer that actually unlocks AI value instead of boiling the ocean.

3. Vendors have caught up on infrastructure.
   Warehouses, vector databases, orchestration, and LLMs are now mature enough that the new bottleneck is not plumbing. It is knowledge capture.

4. A clear lifecycle is emerging.
   The five step Semantic Models Lifecycle gives teams a concrete process to follow: generate, fine tune, test, keep up to date, and optimize from usage. Once there is a shared pattern, a named role tends to follow.

5. The industry is already talking about it.
   Leaders like Snowflake and Databricks are investing heavily in AI copilots that depend on semantic understanding. Folks like Tristan Handy at dbt Labs have written about how AI will transform BI and why semantics sit at the center of that shift. Semantic Engineering is the natural organizing principle for this movement.

How to start a Semantic Engineering practice in your company

If this sounds like a big change, it does not have to start big.

Here is a simple playbook you can run in the first quarter of 2026.

1. Pick one high value domain.
   For example: renewals, claims processing, patient onboarding, field service, or supply chain exceptions. Do not start with “the entire company”.

2. Nominate one or two Semantic Engineers.
   Pick people who already act as translators between data and business. Give them explicit ownership of the semantic model for this domain.

3. Generate a first model from reality.
   Use your existing tools, query logs, and BI assets to create an initial semantic model. If you are using Solid, this is where the auto generated model appears almost instantly.

4. Walk through the lifecycle.

   • Fine tune the model with real business rules

   • Validate against trusted numbers and experts

   • Publish to one AI experience, for one set of users

5. Instrument and iterate.
   Watch how people use it. Where do they hesitate? Where do they stop trusting the answer? Feed that back into the model.

6. Write down the playbook.
   Document what worked and what did not. The next domain will be faster.

By the time you have done this for two or three domains, you will have a small Semantic Engineering practice in place, even if nobody has changed their job titles yet.

Closing thought

Ten years ago, “analytics engineer” was not a common title.
Today it is hard to imagine a modern data team without one.

I am confident that in a few years we will say the same thing about Semantic Engineers.

As AI moves from demos to the messy reality of enterprise operations, the winning organizations will be the ones that treat business meaning as a first class system. They will:

• Capture it explicitly in semantic models

• Keep it continuously aligned with the business

• Put it to work safely through AI agents, copilots, and workflows

That is what Semantic Engineering is about.
And that is the discipline we expect to see emerge, loudly and clearly, in 2026.