The phrase "AI-native" has already begun its journey toward meaninglessness. Six months into widespread adoption of the term, it appears in pitch decks alongside products that apply a linear regression to a CSV export and call the output intelligence. This is worth addressing directly because we use the term to describe our investment thesis, and we want to be precise about what we mean and what we do not mean. The distinction matters not as a labelling exercise but because products that genuinely integrate machine learning at the architectural level exhibit fundamentally different capability ceilings and cost curves than those that do not. Getting this wrong at the investment stage has real consequences.
Our working definition: an AI-native product is one where the core workflow cannot be executed — or cannot be executed at economically viable quality — without trained ML models running as first-class components of the process. The document processing automation that Workist is building is AI-native by this definition: the ingestion, classification, and field extraction pipeline does not degrade gracefully to a rule-based fallback for novel document formats; the model's generalisation capability is what makes the product viable across the diversity of invoice layouts that real procurement teams encounter. A product that applies a keyword classifier to route support tickets and calls this "AI" is not AI-native by the same definition — the classifier is an add-on to a fundamentally rule-based architecture, and removing it would leave the core workflow intact.
The practical consequence of this distinction is in the cost curve. A product built on trained ML models has inference costs that scale with usage, data flywheel effects that compound model quality over time, and an underlying capability that improves through retraining as labelled data accumulates. This produces a different competitive dynamic than traditional SaaS: the product that has processed more data of a given type has a compounding quality advantage that is difficult to replicate through pure engineering effort. For enterprise workflow automation, where the data is often proprietary (specific document formats, specific process structures, specific organisational vocabularies), this flywheel can generate moats that are genuinely hard to breach even for well-resourced competitors. We weight this heavily when evaluating whether an "AI" product has durable differentiation or is building on a capability that will be commoditised by foundation model providers within eighteen months.
The more nuanced question in 2021 is how to distinguish AI-native from AI-augmented at early stage, when the data flywheel has barely started spinning. Here we look at architecture rather than current performance. Does the product roadmap require ongoing model training to achieve its performance targets? Is the founding team's skill composition weighted toward ML engineering, or is it a software engineering team that has bolted a third-party NLP library onto an otherwise conventional product? Does the company have a clear plan for proprietary data acquisition that would make their models harder to replicate over time? These are not conclusive signals in isolation, but they triangulate toward an answer. The presence of a genuine ML research or engineering background in the founding team — not just familiarity with API calls to hosted model providers — is one of the most reliable early indicators.
We are not saying every B2B automation product needs to be AI-native to be a good business. Rule-based workflow tools serve real needs, and there are categories where the process is sufficiently structured that deterministic logic outperforms probabilistic models on reliability grounds. German enterprise buyers, in particular, have a justified preference for predictable system behaviour in business-critical processes. The thesis at Kiefern is specifically about the category of workflows that are too variable, too unstructured, or too dependent on contextual inference to be automated by rules alone — and where AI-native architecture is therefore not an architectural choice but a necessity. In that category, which includes document-heavy procurement, unstructured HR data management, and multi-channel conversational operations, being genuinely AI-native is the minimum bar for product viability, not a differentiating feature claim.