The L&D software market has been due for disruption for years. Legacy learning management systems are widely disliked by the learners who use them and widely retained by the enterprise buyers who pay for them — a combination that tells you the switching cost is high and the alternatives have not been compelling enough to justify the migration pain. In the past three years, a wave of "AI-native" learning platforms has appeared claiming to finally deliver the disruption. Most of them have not. They have delivered better UX and some personalization features, but the underlying architectural assumption — that content curation and delivery is the core product — has not changed.
The difference between a learning management system and something genuinely different is not the presence of an AI recommendation engine. It is where intelligence lives in the product's architecture. This piece is about that distinction, why it matters for durable market position, and what it looks like when a company gets it right.
What LMS Architecture Assumes
A traditional LMS is built around a content repository and a course completion workflow. The system's job is to make content discoverable, track who has completed what, and report compliance status. Intelligence in this model is administrative: route the right content to the right employee, record the completion, generate the report for the L&D team or the regulator.
The AI-augmented LMS layer that most of the market has added is a recommendation engine on top of this architecture. Based on your role, your past completions, and sometimes your declared skills interests, the system suggests content you might find useful. This is genuinely better than a static content catalog. It is not fundamentally different from the LMS model because the value proposition is still the same: content management and compliance tracking, with a more personalized discovery layer on top.
The architectural assumption that does not change is this: the LMS knows what content exists and helps you find it. It does not have a model of what you need to learn, why you need to learn it, or what learning it would actually change about your performance in your role.
What AI-Native Learning Architecture Assumes Instead
An AI-native learning platform starts from a different architectural premise: the central product asset is a skills model, not a content repository. The skills model represents the relationship between skills, roles, performance outcomes, and learning paths — and it is updated continuously by signals from across the organization and from the platform's broader customer base.
In this model, the content is downstream of the intelligence. The platform knows — or infers — what skills gap a particular employee has relative to their role requirements, what learning intervention has historically closed that gap in similar employees, and what the expected impact on performance indicators would be if the gap were closed. Content is generated, curated, or sourced to serve those specific needs, rather than catalogued in the hope that users will find what they need.
The practical consequences of this distinction are significant. An LMS user experience depends heavily on the learner knowing what they need and being motivated to find it. An AI-native learning platform can surface the right learning at the right moment without the learner having articulated a need — because the platform's skills model has inferred the need from performance signals, skill gap data, or role transition trajectory. That is not a feature difference. It is a different theory of how learning happens in organizational contexts.
Why Most "AI-Native" Claims Are Premature
I spent four years as product lead at a Finnish LMS that scaled to three million users. I understand the engineering complexity of content management at scale, and I am not dismissing the difficulty of building well. What I am skeptical about is the claim to AI-native architecture from platforms that have not built the skills intelligence layer that would make the claim substantive.
The test I apply when evaluating an L&D startup: can you describe your skills ontology? Not as a feature — as an asset. How was it built, how does it update, what is its coverage across role families, and how do you verify that the skill-to-learning-path relationships it encodes are accurate rather than assumed? A skills ontology that has been manually built from job description text and has no feedback loop from learning outcomes or performance data is a static taxonomy, not a proprietary intelligence asset. It will become outdated as the organization and the labor market change, and it cannot improve from usage.
A genuine skills intelligence system learns from what happens after the learning intervention: did performance in the relevant competency area improve? Did the employee who completed the learning path progress along their role trajectory faster than peers who did not? These feedback signals are hard to collect and harder to attribute — there are confounders everywhere in organizational performance data — but they are the mechanism by which the skills model becomes more accurate over time. Without them, the platform is not learning anything from its deployments.
The Sana Labs Bet
When we made the Sana Labs investment in 2025, the core of our thesis was about the skills intelligence architecture rather than the learning delivery experience. The delivery experience is good — the product is genuinely better to use than the legacy LMS it typically displaces — but delivery experience is replicable. What is harder to replicate is a skills graph that has been built with explicit attention to the feedback loop between learning interventions and their downstream performance effects.
The early signal we found compelling was the specificity of how the team talked about skill inference. They were not describing a skills taxonomy built from job descriptions. They were describing an inference model that derives skills from behavioral signals — what content a person engages with, how they engage with it, what questions they ask, how their stated skill confidence correlates with their performance in skill assessments. That is a different data substrate than a self-reported skills profile or a manager-assigned skill inventory, and it produces a more dynamic and more accurate picture of where an individual's skills actually sit relative to where the role requires them.
We are not saying that approach is definitively correct — skills inference from behavioral signals has real limitations, particularly when behavioral engagement is low or when the content library does not have adequate coverage of the relevant skill domains. But the explicit focus on closing the feedback loop between learning and performance outcomes is what distinguishes an architecture worth building a company around from a recommendation engine bolted onto a content catalog.
The Enterprise Adoption Pattern
One thing that has surprised me about L&D adoption in the enterprises I have observed closely: the buying decision and the deployment success condition are almost always driven by different stakeholders. The buying decision is typically owned by the L&D function or the People team, who are evaluating content quality, platform usability, and compliance tracking features. The deployment success condition — whether the platform actually changes what people learn and whether that learning affects business performance — is owned by line managers and business unit leaders who were usually not in the procurement conversation.
Products that close this gap — that give L&D buyers what they need to make the procurement decision and also give line managers a meaningful signal about what their team members are learning and what skills they are developing — tend to see higher engagement and better retention than products designed purely for the L&D buyer. The manager visibility layer is often underbuilt because it is hard to design well without a real skills model underneath it. If your platform does not have a credible answer to "what skills is this employee developing and how does that map to their role requirements," you cannot build a manager layer that is more than a completion dashboard.
Content Commoditization and What It Means
Large language models have made content generation orders of magnitude cheaper and faster than it was two years ago. This has significant implications for L&D platforms whose primary moat was content quality or content breadth. When content is infinitely generatable, the defensible position is not "we have better content" — it is "we know what content each specific learner needs, when they need it, and what format will produce the most durable learning outcome."
That knowledge lives in the skills model and the learning outcome feedback loop, not in the content repository. The companies that understood this before content commoditization hit were building the right thing. The companies that are trying to retrofit a skills intelligence layer onto a content-first architecture are going to find the migration more disruptive than they expect — because the skills model needs to be a foundational layer, not an add-on service, if it is going to generate the feedback signals that make it valuable.
The L&D market is large enough and the switching costs from legacy LMS infrastructure are high enough that there is meaningful commercial opportunity for multiple approaches to coexist for the next several years. But the companies building durable market position will be the ones that used this window to build the skills intelligence architecture that the legacy platforms cannot credibly claim to have, not the ones that competed on content quality in a world where content quality stopped being differentiating.