What is AI-native?

The cloud-native analogy

Cloud-native never just meant "it runs on the cloud". You could lift an old application onto a virtual machine in AWS and change nothing about how it was built - that's hosting, not cloud-native. The term meant something more specific: software designed around the cloud's actual properties. Elasticity, managed services, ephemerality, microservices. Architected from the outset to take advantage of what the platform does well, rather than treated as a server that happens to live somewhere else.

AI-native is the same move, applied to AI. The system is architected around the model's properties from day one, and without the model there would be no product. Take the same step that cloud-native took, and point it at large language models instead of infrastructure.

A spectrum, not a binary

The term AI-native and its derivatives are everywhere at the moment, so here's an attempt to clarify. In my view the spectrum has three clear points on it:

AI-washed. The marketing claims AI, there's very little real substance behind it. A logo on a landing page and a press release. But what does it actually DO? And WHY?

AI-enabled, or AI-powered. A working product with AI added as a genuine feature - a chatbot stapled onto an existing CRM, say, or a summarise button in a tool that got along fine without one. The key test: remove the AI and the product still stands. It's diminished, maybe, but it's still a product.

AI-native. Remove the AI and there's no product left. The model is doing the central job, and without it you're holding an empty shell.

Most of what gets called AI-native is really AI-enabled, and that's fine - there's nothing wrong with adding AI to a solid product.

What's actually different about it

The difference shows up in how the thing is actually built, not in the marketing.

The AI runs through it, not beside it. Genuinely AI-native isn't a single API call to a model provider tacked onto one screen. The model shapes the whole design - how data is stored and retrieved, which cloud services you reach for, how a request flows through the system. Pull on almost any part of it and the AI is there.

It handles what you never specified. Traditional software makes you build for every expected input and every branch in advance, and anything outside that list just isn't supported. A model doesn't need a list. The clearest case is unstructured input: free text, emails, PDFs, scanned invoices, photos. Each of those used to need either a person or a parser written for one supplier's exact layout, and now a single path deals with all of them however the document happens to arrive. Also the input can be the user's own words, not items from a dropdown list.

It can act on your systems. An AI-enabled feature answers a question and hands the result back for you to do something with. An AI-native product gives the model tools and lets it get on with the job: read the message, pull the right record, check it against what is already there, and draft whatever comes next. That changes what you are building, because the model now needs tools it can call, permissions bounding what it is allowed to touch, and a record of what it did. We've been doing this on our own books, pointing agentic tooling at the Xero jobs nobody enjoys doing by hand.

The costs and risks are different. You tend to pay per use rather than a flat monthly bill, and there's a new set of safety problems to worry about - the model being tricked into misbehaving, or confidently making things up. Older security thinking doesn't fully cover these, which is why OWASP now keeps a dedicated Top 10 for AI applications.

AI you didn't ask for

What really gets me is that plenty of software you've happily paid for and used for years is suddenly sprouting AI features, and the price is going up to cover them. You didn't ask for the AI, you might not even want it, and now you're paying for it whether you use it or not.

That's the wrong way round. If a tool has done the job for five years, I should get to decide whether the AI is worth it to me. If it isn't, I shouldn't be paying for it. Opt in, not opt out with a price rise quietly attached.

There's a fairer model more software could offer, and it's one I'd love to see more of: bring your own key. Let me plug in my own account with the AI provider and pay the real cost of what I use directly, instead of a marked-up rate on top. The software gives me the clever part - the AI built sensibly into the tool - and I bring the fuel. Everyone can see exactly what they're paying for.

Done well, the AI is woven into what the app is actually for and stays in step with what you're trying to do. It works for the person using it, rather than being bolted on to tick a box or grow the invoice. Who the AI is really serving is the question to ask.

How we build AI-native systems

For us it starts before the technology. The first job is to understand what the business is trying to achieve and what the people using the software are actually trying to get done, then design from there. Get the goal clear and the question of where AI belongs - and where it doesn't - gets a lot easier to answer.

From there it builds on how we already work. We've been building cloud-native on AWS for years - serverless, event-driven, managed services, infrastructure as code - and AI-native sits naturally within that. The same foundation that lets a system scale and stay maintainable is what gives a model somewhere solid to live: your own data to draw on, events to react to, and the compute to run it all without servers to babysit. Amazon Bedrock is one piece of it, letting us use a range of AI models through a single managed service, grounded in your data, with the tools and safety guardrails a serious AI feature needs. AI-native done well is cloud-native with the model treated as a first-class part of the design, rather than bolted on the side.

This is still early doors. The tools are evolving fast, which is part of what makes it an amazing time to be building.