5 min read

AI-Native Confusion: What it actually means to be AI-native, and why most startups and scaleups are far from it.

AI-Native Confusion: What it actually means to be AI-native, and why most startups and scaleups are far from it.

Many of the founders I meet claim to be building AI-native companies. Few actually are.

They've integrated AI into their workflows, their engineers use tools like Claude and Codex, and the non-technical teams are even building out skills. It feels AI-native, but it isn’t. What they're actually doing is retrofitting AI onto a business that was entirely designed for humans - using AI to do existing work faster, rather than designing the business from the ground up around what AI excels at.

I am lucky enough to have seen real AI-native startups with my own eyes. A company that retrofits AI really well might get 4x productivity at a business level. Ones that are AI-native from inception operate at upwards of 20x. That gap is growing, and it will continue to grow.

This is what AI-native actually looks like - across the people, the products, and the infrastructure connecting them. If you can't get there, you'll likely lose to a team that can.

AI-native people

An AI-native person is someone whose default mode of working assumes AI handles the execution and they handle the judgement.

The common thread is the division of labour. AI does the doing, whilst the human does the thinking - deciding whether the work was worth doing, whether it was done correctly, and what comes next. In many cases today, the people also build the surrounding process - optimising their workflows, building skills and .md files, and creating environments where AI thrives, rather than sticking AI into pre-baked scenarios where it struggles.

Progress has been most obvious in engineering. There are engineers in commercial environments orchestrating 20-30 agents simultaneously. But to get 30x output, those agents need to be working on tasks where they thrive. AI-native people don't see a problem space where AI struggles and think "I'll do it myself quickly". Instead, they ask "why is the agent struggling, and what work can I do now to ensure that when this task next appears, it's in a more friendly format or environment for AI to tackle perfectly?"

Outside engineering, things are earlier but accelerating. Non-technical people who are AI-native think in outcomes, not tasks. They are obsessive about the outcome they need to achieve, and begin with "how can I leverage AI to give me the best chance of success?". Almost all roles done in an AI-native way end up being fundamentally different in terms of input, whilst achieving far more impressive outputs.

You can think of this a bit like a horse and carriage of the olden days, and a car of today. The correct answer was never to retrofit the horse in an attempt to make it run faster. It was to remove the horse entirely and replace it with an engine - something that is entirely different, and many, many times more effective.

Being AI-native is less about increasing the speed in which people complete tasks, and more about reimagining the function of a job entirely, in the specific way where AI can be leveraged for the biggest advantage.

AI-native products

An AI-native product isn't simply one that uses AI. It's one where AI fundamentally changes how the product is experienced and how it delivers value. The experience it delivers couldn't exist without AI at the foundation, and you couldn't replicate it by using the underlying AI directly without the product around it.

I have experienced a few early versions of this, which is why I'm so giddy about it. An example is Vera - even if you are not the ICP (you may well be, many people are), I strongly recommend giving it a go. It will open your eyes to what AI-native product experiences, even in the early stages of development, feel like. When I tried it, my true, word for word feedback was "onboarding for almost every product everywhere should be like this."

AI-native experiences are fundamentally different from more typical software, and in some cases (most, actually), that should be taken a step further.

If a human can ask an agent to use your product and successfully get the desired outcome, I am firmly convinced that they will never interact with your product again unless absolutely necessary. That doesn’t mean they stop being a customer - it means that their agent uses your tool to get work done on their behalf. In other words, if you don’t have an additional interface and experience that is agent first and built for agents to use (agents prefer to write code or run scripts to do things, not click around your front end built for humans), you’ll lose.

If a human can’t ask an agent to use your product and successfully get the desired outcome, that is your product’s problem to solve, not theirs.

We don’t all have persistent personal agents on our phone today (some people do - I do), but the world in which we do is not at all far away. When it’s here, if your product can’t serve that market, it simply won’t be competitive anymore.

I encourage you to truly consider how a real, AI-native product experience would solve your customer’s problems. I doubt it is similar to what you’re building today.

AI nucleus

An AI-native company is one where a central intelligence - what I've been calling the AI nucleus - orchestrates agents, tools, and information flows across the entire business, with humans providing oversight rather than detailed instruction.

Every company today has information scattered across dozens of tools. Meeting notes in one system, customer data in another, project status somewhere else, financials in a spreadsheet, critical institutional knowledge locked in someone's head. I don't see a world where all of that gets stored in a single place. Instead it should remain where the work gets done.

The nucleus is closer to a central nervous system than a filing cabinet. It holds high level, continually relevant context, acts on that context, and calls on other tools where more is needed - assigning work to agents, checking quality, routing information, escalating when something breaks, and keeping the business moving without a human directing traffic at every intersection. It doesn't do the work itself. It directs the tools - which are AI-native, meaning optimised for agentic direction - to do the work.

Your AI implementation will mirror your organisational structure, whether you plan for that or not. If your company is built around departmental silos with handoffs between teams, your AI will replicate those silos exactly. The result is AI-assisted bureaucracy. Slightly faster, but still largely useless. And even small startups built on human process look painfully corporate and bureaucratic when compared to AI-native startups.

Of course, startups with no existing processes don't face this issue. They build the nucleus first and let the company form around it. Y Combinator is now calling for startups to build "company brains" - for what it is worth, real AI-native startups have already begun building versions of this internally.

Closing the gap

The companies with the biggest levels of success over the next decade will be small teams filled with AI-native people, building AI-native products in a business that runs on an AI nucleus. If that is not you, there should be some level of concern.

Becoming AI-native through retrofit is basically impossible. Instead, it requires redesigning the organisation from the ground up. Early companies will find this easier as there’s less to ‘unlearn’, but larger companies (even later stage startups) will find this very daunting.

The fact that it’s daunting doesn’t make it any less necessary. The question of “how can we disrupt ourselves, and what would that look like?” should be asked, and when you find the answer, do it.

The 4x you may eventually get from retrofitting is nice. It’s unlikely to be enough.