I recently recorded a podcast episode with Preeti Vaidya, who works on AI at Morgan Health, part of JPMorganChase. Morgan Health focuses on improving outcomes for people covered by employer-sponsored insurance, which is a much larger population than many people realize. Roughly 160 million Americans receive health insurance through their employers, which means this is not a niche healthcare problem. It includes employees, families, benefits teams, clinicians, insurers, and the companies trying to help them all make better decisions.

Preeti sits at the intersection of healthcare, AI, data, clinical workflows, and employer-sponsored benefits. Naturally, we spent a lot of the conversation talking about AI in healthcare: care navigation, clinical decision support, radiology, fragmented health records, claims data, and the shortage of physicians. But the more we talked, the more I felt that healthcare was exposing a much broader enterprise AI problem.

Most AI programs still assume that the user wants to chat, and that’s wrong

Listen to the episode now on YouTube, Apple Podcasts, and Spotify.

That assumption works well for a very specific kind of user. It works for the person who is already curious about AI, already trying new tools, already comfortable writing prompts, and already willing to inspect the answer before trusting it. Preeti called these people “canary users.” Every organization has them. They are the early adopters who will test anything, find useful patterns, and prove that something is possible.

The mistake is treating their success as proof that the average user is ready.

Subscribe now

Canary users are not the average user

Every company has people who are excited about new technology. They are not just the first users of AI. They are the first users of almost every new tool. They ask for access before the tool is formally rolled out. They try things outside the organization and then come back asking whether they can use them internally. They are motivated, curious, and willing to tolerate friction because they believe there is value on the other side.

These users are incredibly important. They help teams discover what a model can do, where the workflows might change, and which use cases are worth pursuing. But they can also create a false signal. When an AI pilot works with canary users, it can look like the organization is ready for broad adoption. In reality, all you have proven is that motivated users can make a flexible AI interface useful.

That is not the same thing as building a product the average user will actually use.

The average user usually does not want to become good at prompting. They do not want to understand model behavior. They do not want to learn how to inspect every answer for hallucinations. They do not want another destination they need to visit during the day. They want help doing the job they already have.

This is where many AI programs start to break. They give everyone access to a chatbot, point to the success of the power users, and then wonder why the rest of the organization does not adopt it with the same energy.

The wrong default is “here is a chatbot”

The original GenAI experience was ChatGPT, so it makes sense that a lot of people still imagine AI through that interface. There is an empty box. You type something. The model answers. You refine. You ask again. Sometimes it works incredibly well.

But that is not how most operational work happens.

Preeti gave the example of a nurse in an emergency room. A nurse does not need a blank chatbot in the middle of a clinical workflow. She does not have time to stop, describe the situation, ask the model what to do, evaluate whether the model is hallucinating, and then figure out how to translate the answer back into care. The better experience is much more embedded. If a marker changes, surface it. If a patient needs attention, alert the right person. If relevant context exists, put it in front of the clinician at the point of decision.

That distinction matters. The value is not in making the nurse “use AI.” The value is in helping her deliver care more effectively inside the workflow she already has.

I see the same pattern in analytics. Giving a business user a blank “chat with your data” box sounds powerful, but it often creates more work. The user asks a vague question. The model makes assumptions. The answer looks confident. Then someone has to verify what happened, inspect the SQL, check the metric definition, and decide whether the answer can be trusted.

At that point, AI did not remove work from the system. It moved the work somewhere else.

This is why the product question cannot be, “How do we get everyone to chat with AI?” The better question is, “Where in the existing workflow would better information, surfaced at the right moment, change the outcome?”

Start with the workflow, not the model

Preeti’s approach was very practical. Before deciding where AI belongs, you need to understand the workflow as it exists today. Not the idealized version. Not the version described in a strategy document. The actual workflow, with all the handoffs, shortcuts, delays, repeated checks, and moments where people rely on judgment.

That means talking to the people doing the work. What does the nurse do today? What does the radiologist do today? What does the benefits administrator do today? Where do they lose time? Where do they need more context? Where are they overloaded with alerts? Where are they forced to make a decision with incomplete information?

Only after that mapping does it make sense to decide where AI should enter.

This sounds obvious, but a lot of enterprise AI programs do the opposite. They start with a model, vendor, or platform, then go looking for places to apply it. That usually produces impressive demos and disappointing adoption. The demo shows what is possible in a controlled setting. The workflow reveals what is useful in the real world.

The better path is less flashy but much more durable. Understand the workflow. Find the decision point where better context matters. Insert AI there. Make the output understandable to the person doing the work. Do not force that person to become an AI operator just to benefit from the technology.

In healthcare, that might mean clinical decision support. In analytics, it might mean surfacing the right governed metric, explaining a dashboard, generating SQL against an approved semantic model, or warning the user that the question is ambiguous before producing a number.

The pattern is the same: AI works better when it meets people where they already work.

Subscribe now

AI should support decisions, not pretend to make them

A lot of AI conversations eventually turn into the same question: will AI replace people?

In healthcare, that question often becomes: will AI replace doctors?

Preeti’s answer was clear. Healthcare is deeply personal. There are things AI can do extremely well, and there are things it should help with immediately. It can process large bodies of medical literature. It can help radiologists identify subtle changes in images. It can summarize relevant context. It can reduce administrative burden. It can help clinicians spend less time typing notes at the end of an exhausting shift.

But the human still matters.

A doctor may notice that something feels off even when the lab results look normal. A nurse may see a patient in a way the data does not capture. A clinician brings judgment, empathy, and accountability to the room. AI can support that work, but it should not be framed as a replacement for it.

That framing is useful outside healthcare too. In analytics, the goal should not be to pretend the AI is the analyst, the data team, and the business decision-maker all at once. The goal should be to help people make better decisions with less friction. That means giving them relevant context, governed definitions, clear assumptions, and answers that can be inspected and trusted.

Decision support is a stronger product promise than decision replacement. It is also a more honest one.

Data fragmentation is not one problem

At one point in the conversation, I asked Preeti about something I personally feel as a patient: my healthcare data is everywhere. I have multiple portals across different providers. There are labs, clinical notes, insurance claims, wearable data, family history, and information I may or may not remember to share. Even if I personally want all of it connected, the system does not make that easy.

So the question was simple: how can AI work if the data is so fragmented?

Preeti’s answer was basically yes, data fragmentation is a huge problem, but no, we do not need to solve all of it before AI can be useful.

I liked that answer because it avoids two bad extremes. One extreme is pretending the data problem does not matter. The other is waiting for a perfectly unified data world before building anything useful. Neither is realistic.

Preeti broke the problem into several layers. There is system fragmentation, where different providers and systems hold different parts of the patient picture. There is temporal fragmentation, where claims data may be useful but delayed by 30 to 90 days. There is also semantic fragmentation, where different systems describe things differently, and where clinical notes, claims codes, lab results, and provider judgment do not automatically line up just because the data has been collected.

That last layer is especially important.

Semantic fragmentation is not just a healthcare problem. Every enterprise has it. One team says “customer,” another says “account,” and another says “workspace.” A revenue metric means one thing in finance and something slightly different in sales. A dashboard contains logic that is not fully documented. A dbt model contains logic that is technically correct but not obvious to a business user. A Slack thread explains the exception, but the AI cannot see it.

Then someone asks an AI analyst a question and expects it to know what the business means.

This is why AI for analytics cannot just be a Text2SQL problem. Generating SQL is not enough. The system needs business meaning. It needs definitions, relationships, assumptions, governance, and context about how the data is actually used. Without that semantic layer, the AI may produce an answer that is syntactically correct and operationally wrong.

Build for incomplete context

One of the most important points Preeti made was that AI builders need to understand not only what their data can do, but what it cannot do.

That is easy to say and hard to implement. Most AI demos are built around the happy path. The model has the right data. The user asks a clean question. The answer exists. The output looks impressive.

Production is not the happy path. Production is missing context, ambiguous language, conflicting definitions, lagged data, undocumented business logic, and users who do not know exactly how to phrase what they need. The system has enough information to sound confident, but not always enough information to be right.

A useful AI system needs to recognize that gap.

In healthcare, that might mean knowing that it has today’s lab result and the current visit notes, but not the full patient history. In analytics, it might mean knowing that there are two definitions of gross margin and asking which one should apply. In both cases, the system becomes more trustworthy when it can explain what it knows, what it does not know, and which assumptions it is making.

This is one of the places where I think semantic engineering becomes essential. The goal is not to create a perfect data world. The goal is to make enough meaning explicit so that AI can behave responsibly in an imperfect one.

That includes knowing when to answer, when to ask a clarifying question, when to use a governed definition, and when to say that the data does not support the request.

The best AI may feel less like AI

One of the interesting patterns in the conversation was that the best healthcare AI examples did not sound like standalone AI tools. They sounded like better workflows.

Care navigation that appears inside the channels people already use. Radiology support that helps clinicians review images more effectively. Clinical context that appears when it is needed. Documentation support that reduces after-hours work. These are not experiences where the user goes somewhere else to “do AI.” They are experiences where AI makes the existing work easier.

That may be a good test for enterprise AI products.

If adoption depends on users leaving their workflow, learning a new behavior, and becoming good at prompting, the bar is very high. If AI is embedded into the place where the work already happens, the bar is different. The user does not need to believe in the AI transformation story. They just need the next step to be easier, faster, or more reliable.

This also changes how we should evaluate success. The question is not how many people logged into the AI tool. The question is whether the workflow improved. Did the clinician save time? Did the patient find the right provider? Did the analyst avoid repetitive work? Did the business user get a governed answer instead of creating another ad hoc spreadsheet? Did the data team reduce the amount of manual clarification required before answering a question?

AI adoption is not the outcome. Better work is the outcome.

The real promise is less friction and better decisions

The optimistic version of AI in healthcare is not that we all get an AI doctor and never see a human again. The optimistic version is more practical and, I think, more compelling.

Clinicians spend less time on administrative work. Patients get better navigation. Benefits become easier to understand. Radiologists get support spotting subtle changes. Doctors get faster access to relevant research. People in underserved areas get more consistent support. The shortage of clinicians becomes less painful than it otherwise would have been.

AI does not need to replace the system to improve it. It needs to reduce friction in the right places.

That is the lesson I took from the conversation with Preeti. It is also the lesson I think applies to almost every enterprise AI effort. The future will not belong to the flashiest chatbot. It will belong to systems that understand the workflow, respect the limits of the data, expose their assumptions, and help humans make better decisions.

That is true in healthcare.

It is true in analytics.

And it is probably true everywhere AI actually needs to work.

Listen to the episode now: YouTube, Spotify, Apple Podcast.

Over the last couple of weeks, three things happened that are worth putting together.

Snowflake announced Cortex Sense, a foundational context layer for CoWork that “automatically learns how a business defines its data and operations.” Cortex Sense uses signals from query history, metadata, dashboards in Power BI and Tableau, and enterprise data outside Snowflake to understand things like revenue definitions, fiscal calendars and snapshot tables. Snowflake also shared a pretty incredible internal test: CoCo and CoWork reached 83% accuracy with Cortex Sense, compared to 47% without it and 23% for frontier coding agents with Snowflake MCP. (snowflake.com)

Anthropic published a post on how they use Claude for self-service data analytics. The point was not “Claude can write SQL now.” The more interesting point was that analytics accuracy is mostly a context and verification problem. Their team wrote that the central challenge is mapping a user’s question to the right entities in the data model and knowing how to work with them. Once that context exists, writing the SQL becomes the easier part. (claude.com)

And Marc Benioff recently made the point that AI needs a semantic layer to work well. Salesforce has also been pushing this publicly through its Open Semantic Interchange work, arguing that agentic AI requires a realignment around the semantic data model, and that agents need trusted semantic definitions to translate intent into accurate outputs. (atscale.com)

Enterprise AI needs semantics. Which is exactly what we’ve been saying for over a year.

Subscribe now

Recap: why semantics are needed (feel free to skip)

The problem with AI and enterprise data is not just Text2SQL. It is not enough for a model to generate a syntactically valid query. The real challenge is understanding what the user actually meant, which data should be trusted, and how the business defines the thing being asked about.

When someone asks for ARR, do they mean booked ARR, billed ARR, active ARR or ending ARR? When someone asks for churn, are they asking about logo churn, gross revenue churn, net revenue churn, voluntary churn or something else? When someone asks about “active users,” what actually counts as active?

The answer is rarely obvious from the schema. A table name can help. A column name can help. But the real meaning is usually spread across dashboards, SQL queries, dbt models, BI tools, tickets, documentation, Slack threads and people’s heads.

That is why AI needs semantics.

We wrote about this in Autogeneration of a semantic layer - the key for AI/BI, where we argued that AI needs a business-aware layer between users and data.

Manual creation of semantics will get you nowhere

We wrote about it in Semantic layer for AI: let’s not make the same mistakes we did with data catalogs: the obvious failure mode is already familiar: companies will try to manually document everything, and the documentation will immediately start going stale.

That is the important part. The semantic layer AI needs cannot be another manual project.

Enterprises have too much data, too many systems, too many dashboards, too many metric definitions and too many edge cases. A small team can manually define the top 20 metrics. Maybe the top 100. But enterprise AI needs much more than that. It needs to understand the full structured data estate, including cloud and on-prem systems, old and new platforms, BI and warehouse layers, operational systems and the business workflows around them.

This is where auto-generated semantics become necessary.

Not because an LLM should blindly invent your business definitions. That would be a terrible idea. Anthropic is right to point out that auto-generated metric definitions can look plausible while preserving the exact ambiguity you were trying to remove.

The answer is not “let the model guess.”

The answer is to generate semantics from the enterprise’s existing evidence: actual queries, dashboards, lineage, metadata, transformations, documentation, usage patterns, tickets and business context. Then score that evidence, reconcile conflicts, surface uncertainty and let humans review, approve and own the definitions.

That is very different from asking AI to hallucinate a metric layer from raw tables.

But building an automated ain’t easy (we should know…)

A heavily used executive dashboard connected to a curated model is a strong signal. A random query from three years ago is a weak signal. A dbt model with tests and lineage is a strong signal. A stale dashboard nobody opens is probably not. A ticket explaining why a metric changed last quarter may be more useful than a column description written five years ago.

The semantic layer should learn from all of this.

And it should keep learning, because the business keeps changing.

This is where Solid is leading.

Solid was built around the belief that enterprise AI needs an enterprise-wide semantic foundation. Not a narrow layer inside one warehouse. Not a semantic model locked to one BI tool. Not a manual spreadsheet of metric definitions. A semantic layer that spans the full structured data set of the enterprise, across cloud and on-prem systems, and connects technical metadata with business meaning.

That is the future Snowflake, Anthropic and Salesforce are all pointing toward.

Snowflake is saying agents need context. Anthropic is saying analytics needs trusted mappings between questions and data models. Salesforce is saying agentic AI needs a semantic layer.

We agree.

We would just add one more thing: in the enterprise, that semantic layer has to be generated, continuously maintained and connected to the full data estate. Otherwise it becomes another partial artifact that starts clean and slowly drifts away from reality.

AI will not succeed in the enterprise by guessing what the business means. It will succeed when it has a trusted semantic foundation.

That is what we’ve been saying for over a year. And that is what Solid is building.

Semantic models need the same shift.

If semantic models are going to power AI agents, Solid’s Text2SQL, BI tools, Snowflake Cortex, Databricks Genie, Looker, dbt, and every other analytics interface, “I think this model is right” is not good enough. We need Test Driven Semantic Modeling. And this is one of the most important innovations we’re building into Solid.

Subscribe now

Semantic models are becoming production software

Semantic layers used to be mostly about consistency. Define ARR once. Define active customer once. Make sure dashboards don’t contradict each other too badly. That is still important, but AI changes the stakes.

Now the semantic model is the thing standing between a business question and the SQL an AI system generates. If the model understands the business correctly, the AI has a chance. If it doesn’t, the AI confidently generates nonsense.

This is why everyone is suddenly talking about semantic models again. The AI needs business context. But there is a hard truth underneath all the excitement: creating the model is hard, testing it is harder, and maintaining it over time is brutal.

Generation helps, and we’ve written before about why autogeneration of a semantic layer is key for AI/BI. But generation alone is not enough. A generated model still needs to be validated.

The old way does not scale

Today, most semantic model work is painfully manual. A data team starts with warehouse tables, ambiguous columns, dashboard logic, dbt models, old SQL queries, and business definitions scattered across the company. Then they manually choose entities, define joins, write metrics, add descriptions, test a few questions, fix obvious issues, and ship.

Then production happens.

A user asks a question the model doesn’t understand. A column changes. A metric definition changes. The AI picks the wrong join path. The generated SQL returns the right-looking number for the wrong reason. Now the team has to debug everything manually.

This is not a scalable process. It is also not how we build serious software.

The TDD idea, translated to semantic models

In software, a test defines expected behavior. For semantic models, the equivalent is a business question with expected SQL.

For example: “Which customers have high average daily balances but few open product types?”

That question is the test. The expected SQL is the ground truth. A semantic model passes only if the Text2SQL engine (such as Solid Analyze), using that model, generates SQL that returns the expected result and uses the right business logic.

That last part matters. It is not enough to accidentally return the same number. The SQL needs to use the right tables, joins, filters, and metric definitions. Otherwise, you don’t have correctness. You have luck.

This is what Solid Benchmarking does.

For every semantic model, Solid maintains a benchmark suite: business questions paired with expected SQL. These benchmarks can be generated automatically from historical SQL, added manually, imported in bulk, or promoted from real production questions asked through Solid’s MCP server. Solid then runs the questions, compares generated SQL to expected SQL, and shows what passed, what failed, and why.

That changes the workflow completely. Instead of building the model, hoping it works, finding out later, and fixing it manually, you get a loop: generate the model, run the benchmark, see what failed, apply fixes, run again, and save a better version.

That is red, green, refactor for semantic models.

Optimize turns failures into fixes

A failing benchmark is useful, but only if it helps you improve the model. A question might fail because the model is missing a column, because the wrong join was selected, because a metric is ambiguous, or because the expected SQL is outdated.

This is where Solid’s Optimize capability matters.

Benchmark failures feed into Optimize. Solid analyzes the failures, identifies root causes, groups related issues, ranks them by impact, and recommends fixes. In most cases, the modeler can review and apply the fix with AI.

This turns semantic modeling into an operational loop, not a one-time project. You are not manually debugging generated SQL for hours. You are reviewing prioritized recommendations based on actual failures.

Production becomes part of the benchmark

The best test suite is not only based on what you thought users would ask. It also learns from what users actually ask.

This is why the MCP usage loop is so important. When an AI agent uses Solid’s MCP server to answer business questions, Solid shows the questions asked, the SQL generated, and the answers returned. A modeler can take a real production question and add it directly to the benchmark suite.

Production teaches the model. The benchmark suite remembers.

This is how semantic models improve over time instead of slowly becoming stale.

Versioning makes it safe

Optimization without versioning is scary. What if a fix improves one question and breaks five others? What if accuracy drops after a change? What if the model worked last week and nobody knows what changed?

Solid’s Versioning closes that gap.

Benchmark runs are tied to specific model versions. If accuracy improves, you know which change helped. If accuracy drops, you can see which version introduced the regression and restore the previous one.

That creates the safety net semantic models have been missing. Benchmarking tells you whether the model is correct. Optimize tells you how to improve it. Versioning lets you make changes without fear.

This is the real innovation

A lot of people focus on Solid’s ability to generate semantic models automatically. That makes sense. Seeing a model created in minutes is impressive.

But the deeper innovation is the lifecycle.

A semantic model is not a YAML file. It is not documentation. It is not a one-time artifact. It is production infrastructure. And production infrastructure needs tests, observability, optimization, versioning, and rollback.

Software engineering learned this lesson decades ago. Data teams should not have to relearn it the hard way.

The future of semantic modeling will look much more like modern software development: tests before trust, benchmarks before production, optimization based on failures, versioning for safety, and production feedback as fuel.

That is Test Driven Semantic Modeling.

And if AI analytics is going to move from impressive demos to trusted production systems, this is not a nice-to-have. It’s the foundation.

If you want to see this in action, contact us.

A few months ago, I started recording a podcast with leaders and influencers in our space, specifically ones who have worked to build something of substance with AI.

The latest episode I recorded is with Nondas Virvikatis. Nondas and I have known each other for a while, and I always enjoy speaking with him about AI, where things are going, what is actually working, and what is still painful. You can jump straight into the episode NOW: YouTube, Spotify and Apple Podcasts.

Nondas leads a team of product managers at UBS Wealth Management Americas, building AI capabilities for financial advisors in the US. Before that, he spent years across product, analytics and data, including in financial services and growth-stage startups.

Subscribe now

AI is not replacing the financial advisor

When most people hear “AI in wealth management”, their mind probably goes to ChatGPT managing their money, buying and selling stocks, and deciding what they should do with their portfolio.

That’s not what Nondas and his team are building.

Wealth management is a relationship-heavy business. Financial advisors understand the client’s financial goals, tax situation, estate planning needs, personal context, risk appetite and life goals. In the US, Nondas explained, financial advisors often operate almost like entrepreneurs. Their client relationships are deeply tied to them.

So the goal is not to replace the advisor.

As Nondas put it, “AI is not going to replace the humans in this industry, but people who use AI will replace the people who don’t use AI.”

That framing is important. AI is not the product. The financial advisor is still the product, in many ways. AI is the leverage.

This is similar to how I think about AI in analytics. We’ve written before that throwing away BI is a bad idea, and that blindly giving business users an unchecked chatbot can be dangerous. The better path is usually augmentation: help humans do the work faster, better and with more confidence.

That same idea applies here.

A good advisor still needs to sit with the client, understand them, calm them down when markets are chaotic, explain tradeoffs, and help them make decisions. AI can help the advisor prepare better, find information faster, personalize service and operate more effectively.

But you still want the human in the loop.

Generic AI gets you part of the way. Specialized AI gets you further.

We also talked about the difference between generic AI tools, like Microsoft 365 Copilot, and more specialized tools built for a specific workflow.

Nondas sees both as valuable.

Generic AI tools can help with productivity. They can write, summarize, help create questionnaires, draft interview questions, prepare for internal presentations, process information and generally accelerate knowledge work.

But in a regulated, high-stakes environment, “good enough” is not always good enough.

There are cases where a generic tool gets you 80% of the way there. That’s useful. But there are also cases where you need much higher certainty, stronger control, better data integration, better evaluation and workflow-specific behavior.

This is very aligned with what we see in data and analytics. General-purpose AI is amazing, but when you want to connect it to enterprise data, definitions, dashboards, metrics and permissions, you need more than a generic chatbot. You need context, governance, evals, observability and a workflow that understands the job to be done.

That’s why we spend so much time thinking about semantic layers for AI, evals and how to keep a close eye on AI behavior with tools like LangSmith.

The same is true in wealth management.

Copilot is useful. But if you want AI to support financial advisors in specific client workflows, with firm-specific data, policies, expectations and risk controls, you need specialized products.

The Chief AI Officer is not just a fancy title

We talked about the rise of the Chief AI Officer role. Someone on LinkedIn once joked that having a Chief AI Officer today is like having a Chief Electricity Officer 100 years ago.

Funny. Also, not completely wrong.

But in a large enterprise, especially a regulated one, the role makes sense.

Nondas described it as a hub-and-spoke model. The central AI organization helps with tooling, training, infrastructure, responsible AI, governance, communities of practice and avoiding 20 teams building the same thing 20 times.

Then each business area figures out how to apply those capabilities to its own workflows.

That balance matters.

If everything is centralized, AI becomes too detached from the business. You get platform teams building impressive capabilities that no one uses.

If everything is decentralized, every team reinvents the wheel, risk management becomes impossible, and the enterprise ends up with chaos.

The winning model is somewhere in the middle: central enablement, local execution.

That feels right to me.

We’ve seen similar patterns in data. A central data team can build the foundation, governance and core assets, but the business value usually happens closer to the workflow. The people who understand the work need to be close to the AI.

Adoption is a product problem

One of the most interesting parts of the conversation was not technical at all.

Nondas emphasized that building the technology is not enough. You need communication. Training. Repetition. Champions. Use cases. Feedback loops. Follow-up.

Financial advisors, as he said, are wired to sell. They are not wired to adopt new technology just because a product team shipped it.

This is such an important point.

Many enterprise AI efforts fail not because the model is bad, but because the rollout is bad.

People need to understand:

• Why should I use this?

• How are my peers using it?

• What does “good” look like?

• When should I trust it?

• When should I not trust it?

• What happens if it fails?

Nondas and his team spend a lot of time close to the field, speaking with users, collecting feedback, identifying champions, and sharing use cases across teams.

This is exactly the mindset I think enterprise AI needs. You cannot just launch and hope for the best. AI adoption is not a Slack announcement.

It’s a product motion.

And the users of internal AI tools should be treated like customers. You look at usage. You segment users. You interview power users. You interview people who dropped off. You ask what changed. You figure out what triggered adoption or abandonment.

That applies whether you’re building AI for financial advisors, analysts, salespeople, product managers or engineers.

The technical problems are still very real

Of course, there are also plenty of technical challenges.

Nondas called out a few:

• Data availability

• Data quality and readiness

• Performance

• Evals

• Feedback loops

• Fallback processes

• Risk controls

That list should sound familiar to anyone building AI inside an enterprise.

The application layer may look simple. A user asks a question. AI gives an answer. Magic.

But underneath, there is a lot of plumbing. Do you have the right data? Is it permissioned correctly? Is it fresh? Is the answer good enough? How do you know? What happens when the model is wrong? How do users report issues? Can they fall back to a traditional process?

This is why I keep saying that AI for enterprise workflows is much harder than demos make it look.

A demo can be built in a weekend.

A production-grade enterprise AI system needs to survive contact with messy data, real users, security teams, compliance teams and business expectations.

As we wrote in (Almost) no AI in production, there’s still a huge gap between experimentation and production. Nondas’ experience reflects that gap, but also shows how serious organizations are starting to cross it.

Regulated environments need levels of freedom

One of the tensions we discussed is the gap between what you can do at home and what you can do inside a large bank.

At home, you can vibe code freely. Open Claude, Cursor, Gemini, ChatGPT, connect things, upload files, build little tools, burn tokens, break stuff, fix stuff, start over.

Inside a major financial institution, that freedom has to be constrained.

And rightfully so.

Nondas described a useful mental model: the broader the impact, the stronger the controls should be.

If you are using AI for yourself, the risk is smaller. You can have more freedom.

If you are building something that affects your team, you need more structure.

If you are building something that affects clients, advisors or the broader firm, you need real controls, approvals, model risk management and governance.

That makes sense.

The trick is not to eliminate freedom. If you do that, you kill innovation.

The trick is to match the level of control to the level of risk.

Small blast radius, more freedom.

Large blast radius, more control.

That is probably the right way to let enterprise AI grow without letting it blow up.

Copilot, Gemini and the “can I do this faster?” habit

Nondas also shared a very practical habit that I loved.

Every time he is about to do something on his computer, he asks himself whether he could do it faster or better with AI.

That’s it.

That habit alone probably separates people who really benefit from AI from people who just occasionally open a chatbot.

He uses AI to draft questionnaires, prepare interview questions, work on internal presentations, process data and support both professional and personal workflows. In his personal life, he uses Gemini heavily because his personal ecosystem is already in Google. At work, his professional context lives more in Microsoft tools.

His comment was great: “your imagination and your connectors, I think, are your two limitations.”

That is exactly right.

The model matters. But the connectors matter too.

If AI has access to your calendar, files, documents, messages, data and workflows, it becomes dramatically more useful. If it is disconnected from everything, you spend your life copying and pasting.

This is why the next few years will likely involve a massive amount of work around APIs, connectors and workflow integration.

The chatbot window is useful. The connected AI system is much more useful.

Vibe coding is addictive

We ended up talking about something I think many of us are experiencing, but maybe don’t always admit.

Vibe coding is addictive.

Nondas described building personal tools with Claude and Claude Code, including an asset aggregator across accounts in Greece and the US, and even a networking database that could help match people in his network based on what they need.

I immediately understood the feeling.

You sit there. You prompt. It builds. It fails. You prompt again. It gets closer. You prompt again. Suddenly your wife is telling you that you need to leave, and you’re saying, “just one more prompt.”

It feels like an arcade machine, except instead of putting in coins, you’re burning tokens.

There is something very powerful about having a machine work with you in real time. It is not passive software. It responds. It tries. It improves. It sometimes frustrates you. It sometimes surprises you.

And yes, sometimes it goes too far.

Nondas made a great point about models overthinking or continuing too long before checking whether they are on the right path. His approach is to constrain the work: do this for three profiles first, let me review it, then scale it.

That’s a good lesson for all of us.

Treat AI like a junior teammate. Give it enough room to be useful, but don’t let it run 500 miles in the wrong direction before checking in.

AI is not cheating

In the lightning round, I asked Nondas for an AI myth he would bust.

His answer was that people should stop feeling uncomfortable admitting they used AI to get to an outcome.

I strongly agree.

There is still a weird stigma around using AI, as if using it means you didn’t really do the work.

That’s nonsense.

Of course, don’t plagiarize. Don’t blindly submit something you didn’t review. Don’t pretend you wrote every word by hand if you didn’t.

But using AI to think, draft, analyze, improve, summarize, structure, code, research or prepare is not cheating.

It’s using a tool.

In a few years, I think this stigma will look silly. Just like no one says you cheated because you used Excel instead of doing math on paper.

The question won’t be whether you used AI.

The question will be whether the output was good.

The next five years: connectors, connectors, connectors

When I asked Nondas for one AI prediction for the next five years, he made it conditional.

If we invest more in APIs and connectivity between applications, AI will really take off.

I think he’s right.

Models will keep improving. But for enterprise use, the bigger unlock may be access. AI needs to connect to the systems where work happens.

CRM. BI. Data warehouses. Documents. Email. Calendar. Ticketing systems. Product tools. Financial systems. Workflow engines.

Once AI can securely and reliably operate across those systems, the value changes.

It stops being a chatbot.

It becomes a worker.

Not a replacement for humans, at least not in most of the enterprise workflows we discussed. But a worker that can help humans move faster, make better decisions and spend less time fighting the machinery around them.

That’s the direction we’re all heading.

I thank Nondas for spending the time with me on the podcast. You can listen to our conversation on YouTube, Spotify and Apple Podcasts.

In the meantime, if you would like to learn more about Solid, reach out to us.

Thanks for reading Building an AI-powered Analytics Startup! Subscribe for free to receive new posts and follow our journey.

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?