More From Green Room
We have had a consistent point of view on AI since early 2023: it would impact software in much the same way AWS and cloud infrastructure did, becoming a new layer in the enabling stack that allows vertical software companies to build better products more efficiently and extend what their applications can do.
Three years later, with more facts on the ground, that view has only strengthened. AI is becoming an enabling layer for the next generation of software applications, and those applications will be considerably more capable as a result.
What has also become clearer is what actually makes an application AI native. The term is now used broadly across technology, but the distinction is more specific than whether a company simply uses AI.
AI-native software is architected from the ground up around the strengths and requirements of large language models (LLMs). The distinction is architectural.
AI-native software is fundamentally different from software that incorporates AI into an existing application.
Connecting an existing SaaS application to an LLM so a user can ask questions about their data in a copilot experience is not AI native. Neither is using an LLM inside an existing feature, such as reading an uploaded document and automatically populating fields in a form. In both cases, the application hands a task to a model, receives the result, and continues to operate largely as it did before.
These are useful capabilities, and nearly every mature SaaS company is finding ways to integrate them into its products. They make traditional software more AI enabled or AI forward, but they do not make the underlying application AI native.
To be AI native, a platform must be architected around LLMs from the ground up. It is our opinion that the only way to get there is to completely re-architect a platform from scratch so that it is engineered around the strengths and requirements of LLMs.
AI-enabled software incorporates AI into the existing application. AI-native software is engineered around AI from the beginning.
Software development has continuously advanced toward higher levels of abstraction. Thirty years ago, developers had to think about memory, pixels, wire protocols, hardware, and a huge scope of underlying computer science. Over time, frameworks and platforms absorbed more of that complexity and allowed developers to operate at progressively higher levels of the stack.
LLMs represent another major step forward in that progression. The underlying coding of application features can increasingly be performed by the model, moving the human engineering role from doing the work of coding toward architecting and managing the work of coding.
The same shift applies to the end user. In traditional software, the human does the work inside the application by clicking through screens, entering information into forms, reviewing data, and moving workflows from one state to another. In an AI-native application, the human increasingly manages AI agents that perform that work.
That is the leverage and value proposition of AI-native software: the user moves from operating the software to managing intelligent systems that do the work.
AI-native applications unlock two capabilities that traditional software has never had at this level: intelligence and autonomy.
Intelligence means that, given access to the data of a business, the application can understand that business, answer questions about it, and reason through potential decisions. Every person on the team can effectively have access to an intelligent digital assistant operating with broad organizational context.
Autonomy means that because the application understands the business, it can follow instructions and perform tasks and workflows on its own.
Together, intelligence and autonomy create another layer of value: expertise.
Our portfolio company DebtBook is a treasury and accounting platform for cities, counties, and states. An AI-native DebtBook is not simply treasury management software. It becomes treasury management expertise.
That expertise can become increasingly specific to the customer. A city can give the application more instruction, more data, and more information about how it operates and what it wants to accomplish. The vendor and the customer are therefore working at another level of abstraction. They are not simply configuring software. They are building expertise and business alpha.
Vertical software companies can become vertical expertise companies. That is a different product with a different value proposition and a potentially much higher ceiling.
An LLM on its own is not an application. At its most basic level, a model receives information and produces an output. It does not inherently have persistent memory, access to a company's systems, or the ability to take action.
An AI harness is the system built around the model that turns the LLM into an application capable of performing work. The harness determines what the model sees, manages context and memory, gives the model access to external capabilities, executes actions, and feeds the results back into the system.
Within an AI harness, two concepts are particularly important: tools and skills.
For an AI-native application, tools and skills enable specialized vertical or customer-specific expertise. The LLM provides the intelligence to use them, while the company develops the methods and capabilities required to produce the desired outcomes.
This has an important implication for product development. Tools are generally small, deterministic applications, while skills can be represented largely in natural language. Once the appropriate architecture and infrastructure are in place, the expertise layer can therefore develop much faster and more flexibly than it could through a traditional software development cycle.
Historically, software was in short supply. What a company could build was bounded by the capacity of its engineering team and the pace of development. AI is rapidly changing that constraint as code production becomes increasingly abundant.
That changes the value of traditional software concepts such as forms, tables, dashboards, information views, and workflows. If those things can be generated quickly and inexpensively, they become less important as sources of differentiation.
AI-native applications can be designed around this new reality. Dashboards, information views, workflows, and other traditional software concepts can increasingly become on-demand customizations for the end customer. The application vendor creates an architecture that is recursive in nature, where users and AI continue to customize and expand the platform over time.
As the supply of software becomes effectively unlimited, customization moves into the hands of the user. The application is no longer a fixed set of screens and workflows shipped by the vendor. It is something the customer and the AI continue to build.
This is one of the most important implications of AI-native architecture for investors.
The model itself is not necessarily the moat. The AI harness is also only part of the architecture. Some of the hardest engineering work sits underneath it in the data integration, data pipeline, data model, and database.
Our portfolio company Madison AI provides agentic AI automation to local government agencies. Madison helps city managers and their teams process public records requests, generate staff reports, run RFPs, evaluate development proposals, and research policy and procedures.
For Madison to perform that work accurately, it first has to integrate with the government's underlying information. That includes structured and unstructured data across government systems, document repositories, spreadsheets, maps, images, and other file types. Madison then has to process that information into a format LLMs can use by extracting, categorizing, and indexing it against a government-specific data model.
This is real, difficult engineering work, and it is work that general-purpose model providers do not solve out of the box. Without the appropriate underlying data and context, even the most capable model cannot reliably produce accurate outcomes.
The data pipeline, data model, and database infrastructure can therefore become a primary competitive moat for vertical AI companies. Madison is productizing this layer as Madison Memory, which can provide the underlying government-specific data infrastructure even if a large city ultimately chooses to work directly with a frontier model provider.
The model is not the moat. It is the application infrastructure of the modern stack. In vertical AI, the durable competitive value sits in the proprietary data layer underneath it.
A properly engineered AI-native architecture can also be model agnostic. In our work, we use different models from different vendors, and multiple models from the same vendor, depending on the capability required and the cost-benefit tradeoff.
Switching models can be relatively straightforward because the underlying data, tools, and skills live within the harness architecture. The models themselves become intelligence infrastructure.
For AI-native companies, enduring value should therefore be built in the proprietary layers surrounding the model rather than depending on the long-term advantage of any single model provider. Model agnosticism also lets a company leverage the cost-benefit optionality of an increasingly dynamic and competitive LLM market.
The AI-native architecture is only part of the change. The process and organization required to build software are changing with it.
One approach emerging from this shift is spec-based AI development. Rather than prompting an AI coding system in small bursts, a team starts with a clear, detailed specification of what it wants built. The specification describes the intended behavior, inputs, outputs, constraints, edge cases, and what "done" looks like. The AI then works from that specification to produce the code.
The important shift is that the specification becomes the source of truth and the code becomes a build artifact generated from it. When something is wrong, the team improves the specification and regenerates the implementation rather than simply patching the output by hand.
Our designers and engineers are increasingly engineering the spec rather than the code. Since AI agents can operate continuously and in parallel, the pace of product development becomes driven by how quickly and effectively teams can develop good specifications, test the resulting work, and review the output.
For investors, this changes what team quality looks like in diligence. Engineering headcount becomes less informative on its own. The more important questions are whether the team knows what to build, whether it understands the architecture required to build it, and whether it has the domain expertise to turn increasingly abundant code into a differentiated product.
While the technical design patterns of SaaS are mature and well understood, AI-native architectures have no established playbook. AI-native applications are new, and teams around the world are inventing many of these design patterns in real time. Experience building these systems is not yet widespread, which gives operators and investors who understand the architecture a current advantage.
For us, the distinction between AI enabled and AI native is becoming increasingly important in investment diligence. We look at whether AI has simply been integrated into an existing application or whether the product has actually been architected around it; where proprietary value sits across the data layer, tools, skills, workflows, and domain expertise; whether the architecture can take advantage of improving models rather than depend on a single one; and whether the application ultimately moves the customer from operating software to managing intelligent systems that perform work.
We are seeing an increasing number of truly AI-native companies emerge in our investment sourcing activity. Many companies described as AI native today are still traditional software products with AI features layered on top. The difference is architectural, it is visible in diligence, and we expect it to become increasingly visible in company outcomes.
AI native is not a feature set. It is an architecture, an operating model, and a fundamentally different way of thinking about where value will accrue in the next generation of software.
.svg)
%20(1).png)
.png)