In a previous post, I argued that AI is becoming a company operating system layer. The natural next question is how to tell whether that is actually happening inside a company.

The answer is not how many copilots are deployed, how many employees have access to ChatGPT, Claude, Cursor, or Codex, or how many AI experiments appear on an executive dashboard. Those are adoption signals. They are not operating model signals.

The better question is whether AI is changing how the company actually works.

Start with the workflow, not the tool

One mistake I see in AI maturity conversations is that they start with the wrong question: “How are you using AI?” It sounds reasonable, but it often produces a shallow answer. People list tools. Teams describe experiments. Executives get a dashboard. Everyone feels like something is happening.

A better diagnostic starts earlier. Before asking about AI, you have to understand how the company operates today:

• How does engineering ship?
• How does product decide what to build?
• How does sales learn why it wins or loses?
• How does customer success detect risk?
• How does finance understand cost and margin impact?
• How does governance decide which data AI systems can access?

If those workflows are unclear, inconsistent, or poorly instrumented, AI will not magically fix them. It will usually amplify the fragmentation.

AI activity is not AI operating leverage

Most companies already have plenty of AI activity. Engineers are using coding agents. Marketing teams are generating copy. Sales teams are summarizing calls. Product teams are drafting requirements. Support teams are experimenting with automation.

The problem is that much of this is happening independently. Different teams use different tools. Different people create different prompts. Different functions maintain different versions of the truth. Governance is often a policy page somewhere, not something agents can actually read and enforce. Management may see usage, but not impact.

That is not an AI operating model. It is distributed experimentation. A company can have high AI usage and still have low AI maturity.

What a real diagnostic should look for

A useful AI maturity assessment should not just ask who has licenses. It should look at whether AI is improving the operating system of the company.

That means asking:

• Are existing workflows documented well enough for AI to assist them?
• Are teams using shared patterns, or is every function inventing its own?
• Are the right data sources available, clean, and governed?
• Can the company measure whether AI improves speed, quality, cost, or predictability?
• Do agents know what data they are allowed to use, or are rules trapped in static documents?
• Is AI helping the company learn from customer calls, support tickets, product usage, roadmap decisions, and financial outcomes?

The point is not to create a more elaborate AI dashboard. The point is to understand whether AI is becoming part of how the company senses, decides, executes, and learns.

The board-level question

For CEOs, boards, and investors, the question should not be: “Do we have an AI strategy?” It should be whether AI is creating operating leverage.

A board should be asking:

• Is AI reducing decision latency?
• Is it improving engineering throughput?
• Is it helping sales understand why deals are won or lost?
• Is it improving retention signal?
• Is it exposing risk earlier?
• Is it changing the margin structure of the business?

If the answer is no, the company may still be in the experimentation phase, even if AI usage looks high.

That is why AI maturity is not about tool count. It is an operating model assessment. The companies that get this right will not be the ones with the longest list of AI tools. They will be the ones that turn AI into a repeatable way to improve workflows, decisions, governance, and execution. And last but not least, companies with clean workflows that are ideally already documented, will win in adopting AI quickly.

I had a few conversations over the past days that all pointed to the same conclusion: many technology companies are still being built like old SaaS companies. That is a mistake. If you are building a technology product now, the priority is not a polished frontend. It is the backend: the data layer, the ontology, the APIs, the analytics layer, the authentication model, and the infrastructure that makes AI agents fast, reliable, and cheap to run on top of the data backend. The frontend still matters, but it should not be the center of gravity anymore.

TL;DR

• Start with the backend and data model, not the dashboard.
• Build for token efficiency as a product requirement, not just an infrastructure metric.
• Expose core capabilities through APIs and agent-friendly interfaces first.
• Keep the UI light, flexible, and increasingly self-serve.
• If every deployment needs heavy forward deployed engineering, the product is not ready yet.

The Moat Is Moving Down the Stack

In the old SaaS model, a lot of value sat in the application layer. You built workflows, dashboards, role-based views, and configuration screens. In AI-native software, that is no longer enough. The durable part of the company is increasingly lower in the stack: the system that structures data correctly, retrieves the right context quickly, exposes useful actions cleanly, and does all of that in a reliable and token-efficient way.

If that layer is weak, the rest of the product becomes slow, expensive, brittle, and hard to customize. If that layer is strong, you can build a surprising amount on top of it very quickly.

The UI Should Get Thinner

A lot of teams still think about product development as: first build the dashboard, then add AI to it. I think it is increasingly the opposite. First build the backend that can answer questions, retrieve context, execute actions, and expose capabilities cleanly. Then add lightweight interfaces on top.

Initially, those interfaces may be very thin. In some cases they may barely be a product UI at all. A technical user might interact through Claude, another agent interface, or an internal tool layer. Over time, you can add more purpose-built interfaces and dashboards, but those should sit on top of a backend that already works well in a headless way.

Token Efficiency Is a Product Decision

One of the bigger mistakes right now is treating token usage as a backend optimization problem. It is not. It is a product design problem. If your system cannot give agents the right context in the right shape, the product becomes costly to operate and difficult to scale. That affects margins, response times, user experience, and the kinds of workflows that are even viable.

This is why the backend matters so much. You need data structures, query systems, and analytics layers that are built for AI interaction, not just for human dashboards. A beautiful interface on top of an inefficient backend is not an AI product. It is a demo with a future cost problem.

The Goal Is Self-Serve Customization

A lot of tech companies are also running into the same trap: they need too much forward deployed engineering to make each customer successful. That is understandable for now, but it is not where you want to stay. The goal should be to make the platform configurable enough that a solutions engineer, a sales engineer, or eventually even the customer can shape the experience without constantly pulling in core backend engineers.

That only works if the system is designed the right way. If the logic, data model, and capabilities are modular and exposed well, you can let people create their own views, workflows, and operating layers on top. If not, every customer request turns into a product detour.

Build the engine first. Build the data layer properly. Make it fast, cheap, reliable, and cleanly exposed. Then let the frontend become lighter, more dynamic, and more self-serve over time. That is increasingly the difference between an AI first company and a SaaS company with an AI feature.