The Slide Nobody Expected to End a Two-Hour Keynote
When Jensen Huang walked off the stage at the SAP Center in San Jose on March 16, 2026, the last image on screen wasn't a chip. It was a dense grid of 103 company names, a crowded, almost deliberately overwhelming slide that Huang called his "AI Natives." Businesses built from the ground up on artificial intelligence, many of them NVIDIA customers, and all of them, in Huang's framing, evidence that the platform shift he has been predicting for a decade has finally, undeniably arrived.
The number that anchored the moment was $150 billion: the venture capital invested into AI-native startups in the past year alone. Huang cited it alongside a claim that would have sounded delusional three years ago but now landed as straightforward reporting: computing demand for NVIDIA GPUs is "off the charts," with what he estimated as a one-million-fold increase in demand over the past few years. The $1 trillion revenue projection through 2027 got the headlines. The 103-company slide got the engineers thinking.
This article is not about NVIDIA's hardware announcements. Those are covered exhaustively elsewhere. This is about what the 103 companies Huang named actually reveal when you map them systematically, cluster them by function, and read the architectural signal underneath the branding. Because the list is not random. It is a deliberate display of the application layer of the AI stack, and understanding it structurally tells you more about where engineering investment is going than any VC report published this year.
The Problem Space: Why "AI-Native" Is an Architecture Claim, Not a Marketing Label
The term AI native gets used loosely, but Huang was using it with a specific technical meaning. At Davos in January 2026, he laid out his five-layer framework explicitly: energy infrastructure at the bottom, then chips and compute, then cloud and data center services, then foundation models, and finally the application layer on top. The 103 companies on his GTC slide are almost entirely application-layer companies. They are not building chips or training frontier models from scratch. They are building products where AI is not a feature added to an existing workflow but the core computational substrate from which the product is derived.
This distinction matters enormously from an architecture standpoint. Traditional software companies add AI as a module. An AI-native company designs its data pipeline, its product surface, its pricing model, and its operational architecture around the assumption that inference is cheap, models are capable, and the bottleneck is not intelligence generation but intelligence orchestration and delivery.
Huang observed that companies are seeing large investment flowing in because for the first time, the models are good enough to build real products and businesses on top of them. That threshold crossing is what separates the current moment from the 2021-era AI enthusiasm. The models have crossed a capability floor below which building reliable AI-native products was genuinely impractical. Above that floor, you can build companies that would have been science fiction five years ago.
The failure mode of the previous generation of AI companies was treating AI as a differentiated capability in a market where it was not yet differentiating. Too many companies spent enormous resources building brittle NLP pipelines and computer vision systems that were fundamentally unreliable at the precision levels real enterprise workflows required. The result was a graveyard of "AI-powered" tools that were actually just rule-based systems with better press releases.
What changed is the gap between model capability and reliable product performance has narrowed to a point where AI-native product architectures are actually viable. The companies on Huang's slide understand this, and their engineering choices reflect it.
The Core Technical Concept: Reading the 103 Companies as an Architectural Map
The 103 companies cluster into six distinct functional categories when you examine them through an engineering lens. Each category represents a different architecture pattern for how AI capability gets translated into product value.
Foundation Models and Reasoning Infrastructure forms the first cluster. This includes OpenAI, Anthropic, Mistral AI, Cohere, xAI, and Perplexity. AI labs including Anthropic, Black Forest, Cohere, Cursor, Harvey, Meta, Mistral AI, OpenAI, OpenEvidence, Perplexity, Runway, Thinking Machines Lab and xAI are among those adopting the NVIDIA Rubin platform to train larger and more capable models. These companies sit at the intersection of infrastructure and application. They are not pure infrastructure plays, they sell products directly but their core engineering challenge is the training, fine-tuning, and inference optimization of frontier-class models. Their architecture is defined by massive distributed training systems, inference serving infrastructure, and the increasingly complex post-training pipelines (RLHF, Constitutional AI, DPO) that produce reliable, aligned model outputs.
Vertical AI Products constitute the second and largest cluster. This is where the genuine architectural diversity lives. Harvey AI is building a legal-domain AI system designed to operate at the precision level actual legal work requires, where hallucination is not an acceptable error rate and citation accuracy is non-negotiable. Cursor and CodeRabbit are building AI-native development environments where the model is not an assistant to the coding workflow but the primary execution surface. Decagon is building AI-native customer support infrastructure, and Genspark is building an AI-native research and synthesis layer for enterprise knowledge work.
What unites these companies architecturally is that they have all made the same core design decision: the model is not a component of the product; it is the runtime. This means their engineering investment flows into retrieval-augmented generation pipelines that are accurate enough for professional use, context management systems that maintain coherence across long tasks, evaluation frameworks that can measure output quality programmatically, and human-in-the-loop designs that catch failures before they reach users. These are hard engineering problems that look nothing like the "prompt engineering" discourse that dominated AI product development conversations two years ago.
AI Infrastructure and Developer Tooling forms the third cluster. LangChain, Together AI, Fireworks AI, and Weights and Biases are the connective tissue of the AI-native ecosystem. They are not end-user products but the platforms on which AI-native products are built. Together AI and Fireworks AI are solving a genuinely difficult distributed systems problem: serving many heterogeneous LLM models at low latency, at scale, with efficient batching and scheduling across GPU clusters. The naive implementation of LLM inference is catastrophically expensive and slow; optimized inference serving using techniques like continuous batching, speculative decoding, and KV cache management is an active area of systems engineering that directly determines whether AI-native products are economically viable.
LangChain represents a different architecture pattern: the orchestration layer that sits between raw model APIs and complex multi-step agent workflows. The technical challenge it solves is state management across multi-step reasoning chains, tool dispatch and error handling, memory retrieval and context window management, and the increasingly complex coordination logic required when multiple specialized models or agents need to collaborate on a single task.
Physical AI and Robotics is the fourth cluster and arguably the most technically ambitious. Physical Intelligence (Pi), Agility Robotics, and several others are attempting something that makes the text-generation AI revolution look comparatively tractable: building AI systems that reliably perceive and act in unstructured physical environments. The engineering architecture here is fundamentally different from the other clusters. These companies must bridge the gap between simulation, where models are trained, and reality, where they are deployed. NVIDIA announced a Physical AI Data Factory Blueprint designed to automate how training data is generated, augmented, and evaluated for robotics, vision AI agents, and autonomous vehicles, because real-world data is scarce and synthetic data plus simulation can turn compute into the raw material these systems need.
Healthcare AI forms the fifth cluster, including companies like OpenEvidence and partners from the genomics space. These companies face a version of the hallucination problem that is genuinely life-critical: in medical diagnosis and drug discovery, a confabulated citation or an incorrect molecular binding prediction is not a UX failure but potentially a safety incident. Their architecture is therefore distinguished by retrieval systems that are heavily grounded in curated, verified knowledge bases, uncertainty quantification layers that can communicate model confidence alongside model outputs, and validation pipelines that integrate with existing clinical and regulatory workflows.
Agentic Infrastructure is the sixth and most emergent cluster. This includes companies building the orchestration, memory, and observability layers for multi-agent AI systems, a category that barely existed as a distinct engineering discipline eighteen months ago. The architectural challenge here maps directly to what makes distributed systems hard in general: consistency, fault tolerance, observability, and coordination at scale, with the additional complication that the agents themselves are non-deterministic and their failure modes are poorly characterized.
Practical Implementation: What the Architecture Patterns Actually Look Like
The most important architectural insight that emerges from studying the 103 companies is that the key engineering investment is not in the model but in the infrastructure that makes the model useful at production quality.
Consider what a vertical AI product like Harvey or Cursor actually requires to function reliably. The raw model capability, sourced from OpenAI, Anthropic, or an open-weights frontier model, is table stakes. The actual engineering challenge is:
User Request
↓
Context Assembly Layer
• Retrieval from domain-specific vector store
• Session memory management
• Tool availability resolution
↓
Prompt Construction and Routing
• Prompt template management
• Model selection (routing based on task complexity)
• Token budget management
↓
Model Inference
• Streaming response handling
• Parallel tool call execution
• Error and retry logic
↓
Output Validation Layer
• Domain-specific constraint checking
• Confidence scoring
• Citation verification (for grounded tasks)
↓
Response Delivery
• Streaming UI rendering
• Audit logging
• Feedback capture for fine-tuning pipeline
Every layer in this stack is a non-trivial engineering problem. The retrieval system requires careful embedding model selection, chunking strategy design, and hybrid search implementation (dense retrieval combined with sparse BM25 retrieval outperforms pure vector search across most domain-specific use cases). The routing layer requires a meta-model or heuristic system that can classify task complexity and select appropriately between an expensive frontier model and a cheaper, faster model without sacrificing output quality. The output validation layer requires domain-specific evaluation logic that can run programmatically and fast enough not to introduce unacceptable latency.
What is striking about the companies on Huang's slide is that the best of them have invested deeply in every layer of this stack rather than treating the model as the only variable. The ones that have not made this investment are already struggling with the economics and reliability problems that accompany naive model wrapping.
Real-World Considerations: Scale, Cost, and the Economics of Inference
Huang described the current moment as the "inflection point of inference," noting that AI systems are now doing real work at scale and that the market is shifting from training models to running them in production. This shift has profound implications for the architecture of AI-native companies.
Training costs are large but bounded. Inference costs are potentially infinite and are the actual operational cost structure of a deployed AI-native product. The economics only work if inference costs per query are low enough to support a viable pricing model. This is why the companies on Huang's list that are building inference serving infrastructure, Together AI, Fireworks AI, and the hardware layer underneath them, are not peripheral to the AI-native ecosystem but structurally central to it.
The companies that are building their own fine-tuned models rather than purely calling frontier model APIs have an additional economic advantage: a well-fine-tuned smaller model on a specific domain frequently outperforms a much larger general-purpose model on that domain's tasks, at a fraction of the inference cost. Harvey's legal AI does not need to perform well at molecular biology synthesis. It needs to perform extremely well at legal reasoning and document analysis. A model fine-tuned on legal corpora with RLHF from legal professionals will outperform GPT-4 at Harvey's specific tasks while costing significantly less to serve at scale.
This is the architectural signal that engineers should take away from the 103-company list: the companies that will sustain their positions in their respective verticals are the ones investing in the full stack from data curation and domain-specific fine-tuning through to optimized inference serving, rather than the ones that are purely API wrappers differentiated only by their go-to-market motion.
Key Insights: What Most Engineers Misunderstand About This Landscape
The most common misreading of the AI-native company landscape is treating it as primarily a story about foundation model capability. Capabilities matter, but the engineering problems that actually determine which companies succeed are largely infrastructure and product problems: reliability, latency, cost, and the quality of the context assembly and retrieval pipelines that feed the model.
A second misunderstanding is treating "AI-native" as a moat in itself. Building on AI does not confer competitive differentiation unless the AI is doing something that is genuinely hard to replicate. Companies whose primary differentiation is "we use LLMs to do X" face erosion as models improve and the cost of building comparable functionality decreases. The durable moats are data advantages (proprietary training sets or feedback loops), deep domain expertise embedded in fine-tuned models or evaluation systems, and infrastructure that is cheaper or faster than commodity alternatives.
The third insight, and perhaps the most strategically significant, is what the 103-company list reveals about NVIDIA's own strategic position. Huang highlighted the rise of AI natives, citing $150 billion of investment into venture startups, and said computing demand for NVIDIA GPUs is "off the charts" as a result of this boom. Every company on that slide is a GPU customer, either directly or through cloud providers. The slide is simultaneously a celebration of the application ecosystem and a demonstration of the demand signal NVIDIA can point to when justifying the projection of $1 trillion in revenue through 2027. The 103 companies are not just AI-native businesses; they are NVIDIA's most important argument that the infrastructure build-out is demand-driven rather than speculative.
Future Outlook: What Comes Next for the AI-Native Architecture
Several trajectories are worth tracking for engineers building in this space.
The first is the commoditization of the base model layer accelerating further. The Nemotron Coalition Huang announced at GTC 2026, pulling together Mistral, Perplexity, Black Forest Labs, Cursor, and others around an open frontier model effort, signals that the open-model ecosystem is maturing to the point where frontier-class capability will be available without proprietary API dependency. Nvidia unveiled the Nemotron Coalition with Black Forest Labs, Cursor, LangChain, Mistral, Perplexity, Reflection AI, Sarvam, and Thinking Machines Lab, with the first project set to underpin the coming Nemotron 4 model family. For engineers building AI-native products, this is the signal to invest more in the layers above and below the model rather than in model selection itself.
The second trajectory is the rise of agentic infrastructure as a distinct engineering discipline. The companies on Huang's list that are building truly autonomous AI systems, ones that take multi-step actions in the real world rather than generating single-turn responses, are discovering that the infrastructure requirements for reliable agent execution look much more like distributed systems engineering than like ML engineering. State persistence, fault tolerance, observability, and human escalation pathways are the hard problems. The engineering community has barely begun developing the tooling and best practices for this class of system.
The third trajectory is the vertical integration of AI-native products downward into infrastructure. Companies that start as application-layer AI products and grow large enough will face strong incentives to own more of their inference stack. As inference costs become a meaningful operational expense, the economics of building custom inference infrastructure improve. The trajectory from "calling the OpenAI API" to "running fine-tuned models on owned or reserved compute" is one that many of the companies on Huang's list will follow over the next two to three years.
The 103-company slide was designed to look like a victory lap for Jensen Huang's decade-long bet on AI infrastructure. It is also, if you read it as an engineer rather than as an investor, a map of the most active engineering frontier in the industry today. Each company name represents a team working on the unsolved problems of reliable, economical, domain-specific AI delivery at production scale. The engineers who understand those problems structurally, rather than at the surface level of model capabilities and prompt design, are the ones who will build the next layer of this stack.
The platform shift has arrived. The application layer is being built now, at machine speed, by 103 companies and counting.
Sponsored Ad
Tech moves fast, but you're still playing catch-up?
That's exactly why 200K+ engineers working at Google, Meta, and Apple read The Code twice a week.
Here's what you get:
Curated tech news that shapes your career - Filtered from thousands of sources so you know what's coming 6 months early.
Practical resources you can use immediately - Real tutorials and tools that solve actual engineering problems.
Research papers and insights decoded - We break down complex tech so you understand what matters.
All delivered twice a week in just 2 short emails.


