AI-native, not just AI-enabled

The layer on top

Most software that “has AI” today follows the same pattern. There is an existing product. It has a database, a set of screens and a sequence of steps the user already knows. Someone adds a model on top. A chat box appears in the corner. A button now says “summarize” or “generate”.

That is useful. We are not against it. But the product underneath has not changed. The data model was designed for forms and fields. The screens were designed for clicking through records. The workflow was designed around what people had to do by hand.

The model ends up as a guest in a house built for someone else. It can help. It cannot rearrange the rooms.

Three places where the difference shows

When we say AI-native, we mean the capability shapes the product from the first decision. It shows in three places.

Architecture. In a layered product, the model reads data that was stored for other purposes. In an AI-native product, the state of the system is designed so a model can read it, reason over it and explain what changed. History, sources and context are part of the design, not an afterthought.

Interaction. Traditional software asks the user to navigate: find the menu, open the record, filter the table. When the system can understand a question, navigation stops being the main way in. The user asks, and the system answers from the right place.

Workflow. Many steps in a process exist only to move information between people. Copy this, summarize that, send it to someone who will reformat it. When the system can understand the material directly, some of those steps can disappear. Not faster. Gone.

An example: a brief instead of a deck

Take something as ordinary as sharing information with a slide deck.

The layered approach is easy to imagine. Keep the deck. Add a model that writes the slides faster. The output is still a sequence of pages. Someone presents it once. The questions get asked in the room, and the answers get lost.

The AI-native approach starts from a different question: what should a shared document be if the system can understand its contents?

It probably stops being a file that gets presented once. It becomes something that persists and changes over time, where readers can ask questions in context and the answers can be checked against the sources. The meeting is no longer the only place where understanding happens.

And nothing in that requires a sequence of slides. Slides exist because a projector shows one page at a time. That constraint does not have to be ours.

The keystone

Our brand uses the image of an arch. In an arch, the keystone is not decoration added at the end. It is the piece that lets the other stones hold.

That is how we think about AI in a product. If you can remove the model and the product still works the same way, the model was an ornament. If removing it makes the structure fall, it was the keystone. The second kind of product is harder to build. It also has a chance of doing something the old one could not.

What this means in practice

Building AI-native does not mean throwing away everything that exists. Databases, permissions and audit trails still matter. Retrieval and data engineering matter more, not less.

It means changing the order of the questions. The usual order is: here is our software, where can we add AI? We prefer: here is a new capability, what would we build if it had existed from day one?

It does exist now. The products that answer that second question will not look like the ones we already have.