Let's Talk
The AI-Native Gap: Why It Keeps Evading Fast-Growing Companies
AI Strategy

The AI-Native Gap: Why It Keeps Evading Fast-Growing Companies

Fritz Desir

· September 29, 2026 · 6 min read

Every company in your market can buy the same models. The frontier is a commodity, priced per token, available to your competitor this afternoon. So if access were the constraint, the field would have leveled by now.

It hasn't. And the companies falling behind are frequently not the slowest ones — they're the ones growing fastest.

That's the part worth explaining.

The trap is capacity, not capability

Ask a growth-stage operator why their AI program has stalled and you'll rarely hear "we couldn't find the technology." You'll hear some version of: we know exactly what we'd change, we just can't stop long enough to change it.

This is the agentic gap. To become AI-native, you have to redesign the work while still doing the work — and the work has a deadline every single day, while the redesign has none.

Three forces make it worse than it sounds:

  • The people who understand a workflow best are the ones least able to step out of it. Their absence is felt immediately, which is precisely why they were the right person to ask.
  • Business-as-usual has a customer waiting. Improvement work has a Slack thread.
  • So the rebuild moves to next quarter. And next quarter is busier than this one.

Growth makes it worse, not better

The intuition is that a fast-growing company has more resources to spend on a rebuild — more revenue, more headcount, more room.

The opposite is true. Load compounds faster than slack does. Demand arrives before the hiring closes; every new person is absorbed into running the current system; and the current system is the one that needed replacing. Growth doesn't create the space to rebuild — it consumes the space you had.

Which produces a genuinely awkward result: the companies most able to fund the change are often least able to make it.

So teams automate what's easy instead of what's expensive

Faced with no slack, people are rational. They pick the thing they can change without stopping anything — a formatting step, a handoff email, a weekly report. Real relief. Small ceiling.

The expensive system stays untouched, because touching it means touching revenue.

This is why so many AI programs look busy and read flat. It isn't a failure of ambition or of tooling. It's an entirely sensible response to having no room.

What actually decides whether a system is worth rebuilding

Three factors. And they multiply rather than add:

candidacy = value × feasibility × capability

Value — is the work expensive, repetitive, and load-bearing enough to justify the disruption.

Feasibility — is the data connected and clean enough that software can act on it, not merely report on it.

Capability — is there anyone who can own, run, and improve the thing after it launches.

Because it's a product, a zero anywhere is a zero overall. That single piece of arithmetic explains the behavior above: teams don't choose the wrong system out of ignorance. They choose the only one where all three factors happened to be non-zero — and that's usually the cheap one.

The factor nobody scores

Value gets estimated. Feasibility gets audited. Capability gets assumed.

It shouldn't be, because a rebuilt system needs three human roles filled after launch, not during the build:

Specify — someone who can describe what good output looks like precisely enough that an agent can be held to it. Without this you get a demo: impressive once, unreliable at volume.

Operate — someone who runs it day to day, adjusts its configuration, and handles what it escalates. Without this it drifts, quietly, until somebody notices a number moving the wrong way.

Improve — someone who reads what the system is learning and feeds that back into it. Skip this one and you haven't built a loop at all. You've built an automation that will be exactly as smart on its thousandth run as it was on its first.

These are roles, not headcount. One capable person can hold all three in a small team. What matters is that none of them is vacant.

Why this is a management problem

Here's the part that tends to land uncomfortably: running an agentic system is managing a small team of individual contributors.

You set the brief. You define what's in scope and what's escalated. You review output, correct it, and adjust the standing instructions. You notice when something has drifted. That is management — the same craft, pointed at a different kind of worker.

Which has an unwelcome implication. A company whose managers were never taught to manage — where the role was a promotion rather than a discipline, learned by imitation — will struggle to run agentic systems for exactly the reasons it struggles to run teams. The gap shows up as vague briefs, unreviewed output, and no feedback loop, whether the reports are human or not.

If you want a leading indicator of whether a company can go AI-native, don't start with its tech stack. Start with whether it has ever formally taught anyone to manage.

The way through is narrower than you think

Nobody rebuilds six systems at once. The point of ranking them is that you never have to.

Pick one system. Protect a specific, named amount of someone's time — not a sponsor, an owner. Prove one number against a real baseline. Then connect the second loop to the first, so they make each other smarter rather than running in parallel.

That's a considerably smaller ask than "become AI-native," and it's the only version of the ask that survives contact with a company that still has a business to run.

The agentic gap doesn't close because the technology gets better. It closes when someone gets deliberate about capacity, honest about capability, and disciplined enough to start with one.

AWSM DSPTCH

Get the dispatch.

Perspectives on AI activation — ROI, frameworks, and lessons from the frontier — sent when we publish. No noise.

How often?

We respect your inbox. Unsubscribe anytime.