What the hell does “AI native” mean?

The machines can run it. We hope we can still understand it.

Sep 15, 2026

Companies are AI native. Job postings ask if employees have “AI native” skills. That new product is AI native. Our workflows and operating models are AI-native.

It’s one of those phrases that is deeply embedded and badly defined.

It’s a bunch of ideas being collapsed into a single term.

For one company it means everyone uses Chat GPT. For another it means that they deploy agents. Or expose their tools through MCP. Or automate a few of their workflows.

Maybe they’re just existing at the same time that AI exists.

If we can’t define it consistently, I don’t see how we can make a cogent argument about what moving toward “AI native” actually needs.

I’ve started - almost accidentally at first - talking about a distinction.

AI ready (or AI enabled): people use the system, but it’s also designed so that machines can understand and use it effectively.
AI native: machines use the system. It may or may not also be designed so people can understand and use it.

That distinction isn’t about how much stuff is in the system. It’s about who (or what) the system is primarily designed for.

AI ready is about legibility

Enterprise systems are designed around people.

A product manager reads a ticket.

A designer inspects a component.

An engineer reads documentation and works out how an API is intended to behave.

The system is there to provide information. The people are doing most of the work around interpreting that information.

And a lot of that work is invisible.

A person knows that two different tickets, using two different terms, are talking about the same problem. They know why that component is still documented, but not used. Which docs version is authoritative, why is there an exception there?

The systems that exist today aren’t necessarily great at being able to interpret themselves.

That’s different when we start talking about AI readiness. An AI-ready design system doesn’t just expose things. It also exposes enough information about their intended use for a machine to select and compose them correctly.

An AI-ready customer knowledge system won’t only store transcripts. It should be documenting relationships between customers, problems, requests, and previous decisions. Making them accessible enough for the software to reason as well as merely reference.

We’re still talking about a system that’s built first to satisfy human needs. But the environment becomes much more legible to machines.

A lot of the problems organizations have when they deploy AI isn’t about the model. It’s about the environment the models exist in.

The information is there. The models can even find it. But they can’t reliably interpret it.

AI native changes the primary actor

AI-native is different. It isn’t just an evolution on AI-ready.

The machine isn’t another participant, when the workflow is still designed around humans. Now the machine is the primary actor.

In a conventional, person-led, customer-support process, someone submits a request. Someone reads it, gives it a category, and looks for related issues. They make checks against the account, see if there’s an appropriate response. Then they can take action.

The AI-ready version of that would make all the same context available to an agent. The agent gets instructions on how to use that context. So it can identify that customer, find previous conversations, inspect relevant docs. Then it can find incidents. Finally it can suggest an action.

There’s still a human decision-maker. And our workflow is still organized around that. We’re just bringing the decision to them more quickly, with clear guidance.

An AI-native version may well be very different.

A request comes in.

The system interprets it. Gathers context. Decides if it has authority to act. And then it does so.

It might automatically answer the question. Change someone’s account settings. Issue a credit. It might open an engineering ticket (and see other agents take action against that ticket).

People aren’t involved by default. Only when the system hits a decision point where it doesn’t have authority, or confidence, to make.

AI readiness makes the existing environment understandable to machines.

AI nativeness assumes machines are operating the environment.

Most companies aren’t AI ready

All the current discussion about becoming AI-native ignores the fact that most organizations aren’t even close to AI-ready.

They have fragmentary data. Incomplete docs. All their workflows and permissions are designed around people. And there’s a bunch of important context in Slack threads, meeting notes, and institutional memory.

One customer has a different name in the CRM and in the project management system. But employees know that and can compensate.

Then we introduce agents. And we assume that “more AI” == “more automatable.”

The constraint actually isn’t how much AI there is. The constraint is everything around the model.

Those systems have been built for decades around people providing the final layer. And if we remove them, then we need to make a lot more of the interpretation be much more explicit.

What’s the migration?

So we’ve got three states.

Not AI ready: Humans can use the system. Machines cannot reliably understand it.

AI ready: Humans use the system, and machines can also understand and operate within it.

AI native: Machines operate the system, with people involved where judgment, authorization or oversight requires them.

The progression is obvious. We want to go:

not AI ready → AI ready → AI native

We can make our system more explicit. Build out improved quality of data and metadata. Write more front matter. Expose state and permissions. Try to create reliable machine interfaces, so that AI systems can participate in more and more of our workflow.

That moves people toward higher-level judgment.

But is that the right path? Couldn’t we also consider the impact of:

not AI ready → AI native

AI readiness can preserve the wrong process

If we evolve around all of our existing systems then we’re working to make the abstractions that exist accessible to the machines.

We’re not asking whether those abstractions are necessary at all.

If we take a project management workflow, it’s built around projects and tickets. People move the tickets around, and we have meetings to understand. And we try to close out enough tickets so that we finish the project.

AI-ready project management can do this process much faster. That’s really useful.

The ticket might not be the right unit of work at all. Just the human artifact we humans invented so that we could coordinate around the work. The AI might just want to derive all its work from goals, constraints, and current state.

Do we need to give an agent excellent, well-informed access to Jira? Or is Jira something that an agent doesn’t even need?

This ties directly to some of my concerns around why Figma wants to drive code back into canvas. It’s a methodology to force human workflows into certain environments, when the real opportunity might be for AI to break the dependence on canvas abstractions entirely. Move human collaboration later - onto the real thing.

AI native creates is a different kind of risk

OK, so let’s skip the adaptation step. We can just design everything from the ground up for machines to operate.

Machine-readable inputs.

Machine-readable state.

Machine-readable outputs.

Agents talk to agents.

People only come in when there’s a specific escalation need.

Those systems don’t necessarily need a human interface. But we start to hit problems when the system makes decisions that the people don’t fully understand.

If we have an AI-ready system, people and machines are working with a shared language and a shared environment. If an agent does something, a person can inspect what they did and reconstruct how it did it.

If it’s purely machine-native, that might not be the case. Machines can communicate through representations that are only optimized for themselves, not human understanding.

That might be the most effective and efficient way for them to complete tasks.

At least until something goes wrong.

Because then we’ve got a problem. How do we explain what happened? Why did the system do this? What information was it using? Did it have the right authority? What...exactly...did it even do?

Human legibility isn’t just convenience

I’m not sure if AI-ready and AI-native are sequential.

AI ready asks:

Can machines understand and act within an environment designed around human work?

AI native asks:

Can machines operate the environment themselves?

I think these can coexist. I also think that - in most cases - they probably should.

A purely machine-operated process with low consequences may be OK. It might not need humans to understand the whys and wherefores. But, the more consequences - financial, customer commitments, employment, healthcare, etc - people need to be a part of the control system.

People don’t need to approve all the actions. It can be automated. But a person needs to be able to understand the system. Have enough visibility and authority so that they can intervene.

On an AI-automated assembly line, a person still needs to understand what’s going on enough to be able to push the big red button.

So maybe we should be redefining the right version of AI native as:

Machine operated. Human legible.

Should companies evolve or jump?

I think the answer is probably both. It depends on the system.

Deep, mature existing systems have valuable data and institutional knowledge. The workflows are probably well embedded, so they’ll benefit from becoming AI-ready.

That gives machines reliable ways to act, accelerating an existing process. We can still put people in the right places within that process.

But new systems might need us to answer a more fundamental question:

Why does this workflow exist like this?

Which of its artifacts are there because people need them? And which steps exist as safety measures for software that hasn’t always been able to exercise judgment.

If machines can continuously observe AND act, which mechanisms are unnecessary?

We need to answer those questions to be able to really define AI native.

AI native does not mean more AI

It’s not just a technological question. It’s architectural.

AI ready: humans are operating the system. Machines can understand it and participate.

AI native: machines operate the system. Humans can understand it and participate.

Companies are pursuing the second state, and most of them still haven’t done the work to reach the first.

AI readiness and AI nativeness are not necessarily maturity levels. We could have an AI native system that’s entirely opaque. Or an AI ready system that requires every action to be confirmed by a human.

“AI native” shouldn’t mean “machines do all the work”.

It should mean that the machines can operate the system without people making all the intermediate decisions.

People are still going to be accountable for the consequences. They need to understand the system that’s making the decisions.